Bijak.
Two apps built 0→1 for the people who actually move the commodity.
- My contribution
- I built the Agent and Broker apps and shipped 15+ production features across trading, payments, invoices and market discovery.
- The constraint
- Give agents and brokers real-time market context and a dependable way to trade in bulk.
- The decision
- Build two apps from 0→1, connecting area analytics, comparable sales and automated brokerage calculations.
COMMERCE, CLOSER TO THE FIELDOne connected marketplace.
DELIVERY & ENGINEERING OUTCOMES
What I took ownership of.
Bijak Mandi connects buyers, suppliers, brokers and farmers on a platform with 500K+ Android downloads, 100K+ verified traders and a 4.1+ rating. Its marketplace workflows span 200+ commodities and 2,000+ mandis. Buyers and suppliers had apps; the agents and brokers who source and intermediate the trades did not. I engineered the Agent and Broker applications from 0→1 — area analytics, demographics, comparable sales, and bulk commodity trading with automated brokerage-fee calculation — and shipped 15+ features across the three marketplace apps, including the state-management refactor that made the flagship tractable.
The people brokering the trades had no software.
An agent standing in a mandi needs to know what a commodity is going for nearby, who is trading it, and what comparable lots have sold for — and a broker needs to move bulk volume and get their fee right without doing arithmetic on a phone. None of that existed as a product. Meanwhile the flagship app's BLoC setup was heavy enough that every new feature carried a boilerplate tax, and trade flows were generating avoidable support tickets from user error.
- Agents and brokers working the marketplace with no dedicated app
- Brokerage fees calculated by hand on bulk commodity trades
- Flagship state management heavy on boilerplate, slowing every feature
- Trade flows lacking the validation to prevent user-error support tickets
- Agents and brokers working from mandis and field visits with structurally unreliable connectivity — present, then absent, then present again, not simply slow
Build for the missing personas, then unblock the codebase.
The Agent and Broker apps were the product gap, so they came first — built 0→1 against the same backend the buyer and supplier apps use, with role-based APIs designed alongside the backend team. The refactor came second, once it was clear the boilerplate tax was compounding across three apps rather than being a flagship quirk.
Agent app built around decisions, not records
An agent's question is 'what should I pay here, today' — so the app leads with real-time area analytics, demographic insight, and comparable sales filtering rather than a list of listings.
Read all 6 decisions together
Agent app built around decisions, not records
An agent's question is 'what should I pay here, today' — so the app leads with real-time area analytics, demographic insight, and comparable sales filtering rather than a list of listings.
Automated brokerage-fee calculation in the bulk trade flow
Bulk commodity trades are where a manual fee mistake is most expensive. Folding the calculation into the trade itself removed the error class instead of validating around it.
BLoC → GetX on the flagship
The app's state is mostly reactive marketplace data — prices, listings, location. The event/state ceremony wasn't buying anything against that shape. The refactor cut boilerplate ~35%, improved screen rendering performance, and made subsequent features faster to build.
AWS S3, SNS, and AppSync for the platform layer
S3 for secure media storage, SNS for push, AppSync for real-time data sync across roles — so agents, brokers, buyers, and suppliers see the same trade state without polling.
Validation as ticket deflection
Reworking the trade workflows and their validations cut user-error support tickets ~25%. Cheaper to make the wrong input impossible than to staff the aftermath.
Offline-first as a design constraint, not a feature
Field connectivity in the mandis where agents and brokers work is intermittent, not just slow — present, then absent, then present again — which made offline-first a design constraint for the Agent and Broker apps, not a feature to add later.
Four roles, three apps, one trade state.
The Agent and Broker apps shipped into the same real-time marketplace the buyer and supplier apps already used, with role-based APIs keeping each persona's view of a trade consistent with everyone else's.
- Agent and Broker apps engineered 0→1 and shipped to production
- Real-time area analytics, demographic insights, and comparable sales filtering
- Bulk commodity trading with automated brokerage-fee calculation
- 15+ production features across trader discovery, trading, orders, payments, invoices, bookkeeping and market prices
- Marketplace workflows covering 200+ commodities and 2,000+ mandis
- AWS S3 + SNS + AppSync for media, push, and real-time sync across roles
The work, measured.
Apps built 0→1
The Agent and Broker applications, taking two marketplace personas from no software to production.
Features shipped
Trader discovery, trading, orders, payments, invoices, bookkeeping and market-price workflows across 200+ commodities and 2,000+ mandis.
User-error support tickets
Achieved by reworking the trade workflows and their validations rather than by adding support capacity.
Boilerplate code
The BLoC → GetX refactor on the flagship, which also improved screen rendering performance and accelerated feature development.
| Metric | Before | After |
|---|---|---|
| Apps for agents and brokers | 0 — neither persona had a dedicated application | 2 apps engineered 0→1, with analytics and bulk commodity trading in production |
| Brokerage fee on bulk trades | Calculated manually outside the trade flow | Automated inside the trade itself |
| Flagship state management | BLoC — boilerplate tax on every new feature | GetX — ~35% less boilerplate, faster screen rendering |
Built with purpose.
Mobile
- Flutter
- Dart
- GetX
- BLoC
Native
- Kotlin
- Java
Cloud
- AWS S3
- AWS SNS
- AWS AppSync
Backend
- Role-Based REST APIs
- Firebase Analytics
“Yashraj adapts seamlessly to different processes and demonstrates strong problem-solving skills, especially in rapid bug fixing.”
Android, Kotlin & Flutter · Bengaluru & remote teams.
Send the role and a little about your team. I’ll take it from there.