Bijak
Two apps built 0→1 for the people who actually move the commodity.
The brief, in a paragraph.
Bijak runs an agriculture marketplace connecting buyers, suppliers, brokers, and farmers. 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.
Every project has a story before it has a solution. Here's the part nobody writes on the case-study cover.
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.
- 01Agents and brokers working the marketplace with no dedicated app
- 02Brokerage fees calculated by hand on bulk commodity trades
- 03Flagship state management heavy on boilerplate, slowing every feature
- 04Trade flows lacking the validation to prevent user-error support tickets
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.
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.
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.
- 01Agent and Broker apps engineered 0→1 and shipped to production
- 02Real-time area analytics, demographic insights, and comparable sales filtering
- 03Bulk commodity trading with automated brokerage-fee calculation
- 0415+ features across three marketplace apps serving buyers, suppliers, brokers, and farmers
- 05AWS S3 + SNS + AppSync for media, push, and real-time sync across roles
The numbers, after the dust settled.
The Agent and Broker applications, taking two marketplace personas from no software to production.
Across three agriculture marketplace apps serving buyers, suppliers, brokers, and farmers — all live in production.
Achieved by reworking the trade workflows and their validations rather than by adding support capacity.
The BLoC → GetX refactor on the flagship, which also improved screen rendering performance and accelerated feature development.
What changed, measured.
| 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 |
What it's built with.
- Flutter
- Dart
- GetX
- BLoC
- Kotlin
- Java
- AWS S3
- AWS SNS
- AWS AppSync
- Role-Based REST APIs
- Firebase Analytics
From the blog.
Building E-Commerce Apps with Flutter: Features, Architecture & Best Practices
A complete technical guide to building e-commerce and marketplace apps with Flutter: essential features, payment integration, architecture patterns, and lessons from the Bijak agricultural marketplace.
How I Ship Flutter MVPs in 6 Weeks (Real Timeline from 20+ Projects)
A week-by-week breakdown of a Flutter MVP build — scope lock, architecture, integrations, and store submission in 6 weeks. Real deliverables and trade-offs.
“Yashraj adapts seamlessly to different processes and demonstrates strong problem-solving skills, especially in rapid bug fixing.
This is the kind of Flutter and full-stack work I do day to day. The résumé has the rest.
Building a team that needs this?
I'm open to full-time engineering roles. Start with the résumé, then reach out — I reply within a day.