Case study // 01
Zonova
A four-vertical marketplace that won two national awards in its first year.
- Role
- Software Engineer
- Year
- 2026
- Category
- Commerce
- Status
- Live
- React 19
- TypeScript
- Firebase
- Google Gemini
- Capacitor
- Vite
// CONTEXT
The problem
Four separate retail businesses, covering flowers, cakes, clothing and gifts, each wanted an online storefront. Running four codebases would have meant four carts, four checkouts and four sets of vendor tooling to maintain. The brief was one platform that presents four distinct shopfronts while sharing a single cart, checkout, search and wishlist underneath.
// CONSTRAINTS
What made it hard
- A seven-person team working across an 86,000-line TypeScript codebase.
- Three languages at launch, English, Sinhala and Tamil, including the vendor dashboards and not just the storefront.
- One codebase had to serve web, PWA and a native Android app.
- Shop staff needed access to their own orders without being able to see other vendors' data, or platform-level settings.
// DECISIONS
What I chose, and what I didn't
- 01
Put Google Gemini behind a server-side proxy with multi-key failover pooling and request logging.
WhyExposing API keys client-side was unacceptable, and a single key's rate limit would have capped concurrent image generation during peak hours, precisely when the AI design studio is most used.
Instead ofCalling Gemini directly from the client with a public key, which is the fastest path to a demo and the fastest path to a leaked key and an unbounded bill.
- 02
Implement passkeys (WebAuthn) and native biometrics rather than relying on passwords alone.
WhyThe buyer base is overwhelmingly mobile, where typing a strong password is friction and reusing a weak one is the norm. Biometric unlock removed both problems and cut abandoned logins.
Instead ofPassword plus SMS OTP, which adds per-message cost, depends on carrier deliverability, and is phishable in a way passkeys are not.
- 03
Enforce the three-tier permission model in Firestore security rules, and test those rules against the emulator in CI.
WhyAuthorisation enforced only in the UI is decoration. Putting it in the rules layer means a vendor cannot read another vendor's orders even with a hand-crafted request, and the emulator tests stop a future refactor from quietly widening access.
Instead ofClient-side route guards plus trusted server code paths, which works until someone calls the database directly.
- 04
Ship Android from the same codebase via Capacitor instead of writing a separate native app.
WhyOne team, one release cadence, one set of business logic. Capacitor still gave access to push notifications, camera and native share, which was the whole reason for wanting an app.
Instead ofA React Native or fully native rebuild, which would have doubled the surface area for a seven-person team and split the feature roadmap in two.
// OUTCOME
What came of it
- Best Micro Enterprises Website at BestWeb.lk 2026, Gold Winner.
- Most Popular Micro Enterprises Website at BestWeb.lk 2026, Winner by public vote.
- Zero authorisation defects found in review. The three-tier permission model is enforced in Firestore rules and covered by emulator tests.
- Live across web, PWA and Android from a single codebase, in three languages.
// RECOGNITION
What it won
This is the build that took two national awards at BestWeb.lk 2026, Sri Lanka's only national website competition, run by the LK Domain Registry — in its first year of entry. The LK Domain Registry also presented me a Certificate of Appreciation as one of the developers behind the winning websites.

Gold Winner · Judged category, 2026
Best Micro Enterprises Website
“Awarded to Zonova Pvt Ltd for their website www.zonova.lk”
I built the winning site end to end — storefront, vendor dashboard, and the services behind both.
Verify on BestWeb.lk
Winner · Decided by public vote, 2026
Most Popular Micro Enterprises Website
“Awarded to Zonova Pvt Ltd for their website www.zonova.lk”
The same site, voted for by the public — the build people chose to keep using.
Verify on BestWeb.lk
// REFLECTION
What I'd do differently
The testing baseline should have come first, not once the codebase was already large. Retrofitting Firestore rules tests across existing collections took far longer than writing them alongside the rules would have. On the next platform I would stand up the emulator and the rules suite in week one.
