Boshna
Technologies & Architecture Stack
Overview
Boshna (بوشنا — "the market in your hands") is a livestock marketplace for Saudi Arabia. Buying livestock in the Kingdom has traditionally meant a physical souq and a chain of brokers standing between the breeder and the buyer. Boshna moves that trade into an app and removes the middle layer.
Breeders list their stock. Buyers browse, bid or post a request describing what they need. Payment goes into an escrow wallet that holds the money until the buyer confirms receipt. The buyer then either takes delivery of the animal or orders it slaughtered, cut to specification, packed and delivered to the door.
It is Arabic-first and genuinely right-to-left — including Arabic-Indic numerals and date formatting — with a full English alternative, rather than an English app with Arabic bolted on afterwards. Live auctions run in real time over WebSockets, and payments run on Saudi rails: Al Rajhi Bank acquiring with mada and 3-D Secure. The app shipped to the App Store in April 2025 and is now on version 2.0.x.
My role: Team Lead at Bixosoft. The build was delivered by my team under my supervision.
The Challenge
A marketplace is easy to sketch and hard to make correct. This one has live animals, real money held in escrow, and five different ways to transact — each of which can fail differently.
- Five trading modes, five state machines. Fixed-price sale, live auction, silent auction, buyer requests and butchering orders are not variations on one flow. Each has its own lifecycle, its own valid transitions and its own failure states.
- Live auctions must never go stale. Every bidder has to see the same auction state at the same moment. A stale bid feed does not produce a bad user experience — it produces a disputed sale and a refund.
- Money is held, not transferred. Funds sit in escrow until the buyer confirms receipt. That means wallet state and order state have to move together; if they drift apart, money is either trapped or released to the wrong party.
- One animal, several buyers. Stock can be split by share or by cut across multiple buyers, which complicates inventory, pricing and settlement simultaneously.
- Fulfilment is physical. After purchase comes slaughtering method, cut specification, packing and delivery. All of it has to be captured accurately and tracked, because getting it wrong means a spoiled order that cannot be re-run.
- Arabic-first, properly. Right-to-left throughout, with Arabic-Indic numerals and correct date formatting, plus a working English alternative — not a mirrored English layout.
- Saudi payment rails. Al Rajhi acquiring with mada and 3-D Secure, where every authentication and settlement failure mode has to be handled explicitly rather than optimistically.
Solution & Architecture
Five trading modes in one app
- Direct sale for buyers who want a fixed price with no bidding.
- Live auction with real-time bidding and managed bid handling.
- Silent auction where offers are submitted privately within a window and the best offer wins at close.
- Buyer requests, where a buyer posts what they need and sellers compete to fulfil it.
- Butchering and processing, ordered directly after purchase.
Split purchasing
- A single animal can be sold by share or by cut across several buyers.
- Inventory, pricing and settlement all handled per share rather than per animal.
Order lifecycle
- A multi-step lifecycle carrying an order from listing through payment, fulfilment and confirmed receipt.
- Each trading mode maps onto that lifecycle with its own valid transitions.
Real-time auctions
- Live bid feeds pushed to every participant over WebSockets so auction state is identical for all bidders.
- Bid handling managed centrally so the server, not the client, decides what the current bid is.
Escrow wallet
- Available, pending and held balances tracked separately within the buyer's wallet.
- Funds held from payment until the buyer confirms receipt, then released to the seller.
- Wallet state and order state advance together so money is never released against an unfulfilled order.
Saudi payment rails
- Card acquiring through Al Rajhi Bank with mada and 3-D Secure authentication.
- Authentication and settlement failure modes handled explicitly at each step of the payment flow.
Butchering and processing
- Slaughtering method and cut specification captured as part of the order rather than negotiated offline.
- Sold by weight or by cut — half, quarter or whole.
- Packing preferences and quantity per cut recorded against the order.
Delivery
- Delivery tracked through to the buyer's door, closing the loop that releases the escrowed funds.
- Nationwide coverage across the regions of the Kingdom.
Arabic-first RTL
- Genuine right-to-left layout throughout, with Arabic-Indic numerals and correct date formatting.
- A full English alternative rather than a partial translation.
- Saudi-dialect copy rather than formal MSA, because that is how the market actually speaks.
In-app messaging
- Direct buyer-to-seller chat added in the 2.0 line, with push notifications for new messages.
- Keeps negotiation and clarification inside the platform instead of moving it to WhatsApp.
Results & Outcomes
Key Takeaway
- Held money is harder than moved money. Escrow means wallet state and order state must advance as one. Treating them as independent would have produced either trapped funds or premature payouts — both of which destroy a marketplace's credibility permanently.
- The server decides what the bid is. Making bid state server-authoritative and pushing it to every client is the only way a contested auction result is defensible afterwards.
- Five trading modes means five state machines. The temptation is to treat them as variations on one flow. They are not, and modelling each lifecycle explicitly is what kept the order system correct as modes were added.
- Arabic-first is an architectural decision, not a translation task. RTL layout, Arabic-Indic numerals and dialect copy had to be designed in from the start. Mirroring an English app would have produced something that reads as foreign to the market it serves.
- Physical fulfilment belongs in the order. Capturing slaughtering method, cut specification and packing as structured order data — rather than leaving it to a phone call — is what let the platform actually remove the broker.
Have a similar system to build or scale?
Let's discuss your engineering goals, architecture, and timeline.
Explore More Case Studies
Expenses Meet
An offline-first personal finance app built with Flutter and Firebase. Expenses Meet lets users track expenses without internet, auto-links transactions to their account on login, and adds group expense splitting and peer-to-peer loan tracking — all optimized for PKR.
E-CommerceSalveowell
Five product surfaces on one Laravel commerce and compensation platform, serving four regional markets since 2021: the public storefront, a retail shopping app with 100K+ installs, a distributor app, a training app, and an executive admin app. My role grew across the engagement from frontend developer, to sole developer of the retail app, to team lead over the rest.