Building Purbasha: From a Manual Emporium to a Storefront Ministers Signed Off On

This project started because a client of mine went shopping and paid attention.

After I built GSP — the Gram Samriddhi Portal — for them, they had the appetite for more government digitization work and started scouting for it. One of those scouting trips took them to the Purbasha emporium, the government's handicrafts showroom in Tripura. And what they noticed was not the crafts. It was that everything was being run by hand. No online store, no digital catalogue, no way to buy anything unless you were physically standing in the shop.

So they came back with an idea and a small ask: build a demo e-commerce UI, something we can show people. I built the demo. They took it and pitched it — to the Forest and Tourism departments, all the way up to the minister's desk. And the people in that room liked it enough to say the words that turn a demo into a project: make this real.

Building ahead of the tender

Here is the part that made this one unusual.

Government work runs on tenders, and the tender for this had not floated yet. It still hasn't. Normally that means you wait. But there was a timing problem — I am within a year of finishing college and could well be tied up in a job by the time the paperwork catches up. Rather than risk losing the person who built the demo, the client paid an advance to get the full build started now, with the balance tied to the tender being awarded and the project clearing a security audit.

I find that quietly flattering, and also a real responsibility. Someone put money down on unfinished government process because they wanted the work done while I was still the one doing it. So I built the whole thing — the website and the mobile app — and it now sits ready, waiting for the tender to float.

One backend for two clients (and a second life for old code)

I did not build Purbasha's backend from a blank page. I gave one a second life.

The Shagnest e-commerce backend I had built earlier never got the traffic it deserved — a story I have written about separately. But the logic in it was solid: catalog, orders, coupons, admin dashboard, all of it. So I reused that foundation here, adapting the same battle-tested backend into Purbasha's single Next.js API — and then pointed both a Next.js web store and a Flutter mobile app at it.

One brain, two front doors. Same endpoints, same rules, one source of truth. Neither the app nor the website touches the database directly; everything routes through the API, so the rules about who can read and write what live in one guarded place instead of drifting apart across two clients. It was oddly satisfying to watch code that had gone quiet on one project become the engine of another.

The part that fought me: phone-first login and MSG91

The trickiest thing I built was the login, and it fought me the whole way.

E-commerce customers in this context rarely have — or want to use — email. Everyone has a phone number and everyone can read an SMS, so the auth had to be phone-first and passwordless: type an Indian number, receive an OTP, and you are in. No passwords, no email gauntlet losing real buyers at the door. Google OAuth exists, but it is locked to the admin dashboard for internal accounts only.

Sounds clean. The reality was MSG91, whose OTP integration docs are, to put it kindly, dense. Wiring up send-OTP, verify-OTP, resend timers, expiry windows, and then mapping a verified phone number cleanly onto an Appwrite user — creating one if new, finding one if returning, and only then asking for a name — took real patience to get right. It is the least visible feature in the app and it ate more of my time than the entire product catalog.

The unglamorous machinery

A store is only real if a box shows up at someone's door, so the rest of the plumbing matters:

• Razorpay for payments — native checkout on both web and Flutter, sharing keys.
• Shiprocket for logistics, with live tracking the app can open directly.
• Resend and Nodemailer for transactional email, and server-generated PDF receipts wired into both clients.
• The Flutter app's session secret lives in the phone's Keystore/Keychain via secure storage, not a plain-text preference file.

And because the products are traditional crafts, the interface leans into warmer, more traditional typography instead of flattening everything into another generic store — the crafts are the hero, not the chrome.

Where it stands

The demo is live and fully clickable, running with test-mode Razorpay so you can walk the entire flow end to end. What it does not have yet is a home on government servers or a single row of real customer data — that comes after the tender is awarded and the security audit is passed.

So the honest status is: built, working, and waiting. But I would rather be the person who already has the finished, demonstrable product sitting ready when the process finally catches up — than the one promising he could build it if he won.

What this one was really about

Most e-commerce projects are about conversion rates. Purbasha was about something more basic: a government showroom that only existed if you walked into it now has a door to the rest of the world — a store and an app, built off a foundation I had already proven, waiting for the paperwork to make it official.

That whole chain — a satisfied client, a shopping trip that noticed something, a demo, a ministerial thumbs-up — started because an earlier project went well. That is the compounding I keep betting on.