One portal, four commerce mechanics
Snapbid.in, delivered in 2012 for the Indian market, combined four ways of selling in one product:
- Lowest-unique-bid auctions — the reverse-bidding mechanic where the lowest bid nobody else placed wins;
- Price-reveal (Dutch-style) auctions — where a hidden or falling price rewards well-timed commitment;
- Group-buy deals — single-product offers unlocked by collective demand, the model then being popularised worldwide;
- Conventional online shopping — a straightforward buy-now store.
The commercial logic was portfolio thinking: different mechanics attract different buyers and suit different stock, and one catalogue serving all four lets an operator move merchandise between them. The engineering consequence was that nothing could be bolted on — products, inventory, orders and users had to be modelled once and shared by every mechanic.
The modules that made it work
Beyond the bidding engines themselves, the 2012 build shipped with a module set that was genuinely unusual for its time: SMS notifications for auction events in a market where the phone, not the inbox, was the reliable channel; Facebook login and friend-referral, riding the first wave of social acquisition; multiple payment-gateway integrations; and — the unglamorous heart of the thing — product, stock and inventory management with clear reporting, so the operator could actually run four sales channels without four back-offices.
Engineering notes
The platform was built on PHP and MySQL, with Ajax, jQuery and JavaScript carrying the interactive surfaces. The project team spanned project management, programming, design, slicing and QA — five roles where Khazaana a few months earlier had needed three, a fair measure of how much more platform this was.
In hindsight: a 2026 perspective
The following is present-day editorial perspective, not part of the 2012 record.
Snapbid was our first real lesson in what we now treat as a design principle: commerce mechanics are interchangeable front-ends over a shared transactional core. Model the catalogue, inventory, orders and ledger correctly, and adding a new selling mechanic is feature work; model them per-mechanic, and every addition is a rebuild. That principle — learned here on PHP and MySQL — is exactly how we structure multi-format marketplace platforms today.