The product
Zera's pitch is "Buy, Sell, Work and Connect." Instead of separate apps for selling a bike, hiring a cleaner, finding a job, and buying a concert ticket, people do all of it in one place, alongside a community of the same users.
The problem
Each module is effectively its own product, with its own data, forms, filters, and user flows. Goods need listings and search. Services need providers and bookings. Jobs need applications. Events need tickets that can be scanned at the door. The challenge was holding all of that in one app without it feeling complicated to users or becoming unmaintainable for developers.
My role
Feature development, API integration, state management, QR workflows, map-based features, server-state caching, UI implementation, and production releases.
I worked in a team of 2–3 people, with a separate backend developer.
What I built
Marketplace modules for goods, services, jobs, events, and community posts, each with its own flows and filters
Demand heat maps on Google Maps that show where marketplace activity is concentrated
QR ticket scanning for event entry
Stripe payments for purchases in the marketplace
Featured posts sold as one-time purchases through RevenueCat, running for 3, 7, 14, or 30 days
Local pickup and shipping with USPS shipping label status shown in the app
In-app web views for external flows and dynamic actions
Cached server state with TanStack Query, so data-heavy screens load fast and don't refetch unnecessarily
Architecture
Flutter app, iOS and Android
Technical challenges
Five products, one consistent app. Every module returned different API responses and needed different forms, filters, and UI states. I kept API logic, shared components, and feature-specific flows separate, so a change to jobs couldn't break events, and new modules could be added without restructuring existing ones.
Data-heavy screens. Marketplace feeds, search, and listings make a lot of requests. Without caching, users see spinners everywhere and the backend takes unnecessary load.
Heat maps without lag. Rendering high-density activity on a map can easily freeze the UI. The heat map had to show patterns clearly without overloading the map.
Important engineering decisions
- 1TanStack Query for server state.Caching, background refetching, and predictable UI updates in one place, instead of hand-rolled loading logic in every screen. It cut redundant API calls and made data-heavy screens more stable.
- 2Modular QR and web view handling.Built once, reused across tickets, external flows, and dynamic actions.
- 3Feature-first structure.Each vertical owns its screens and logic, with shared building blocks underneath.
Technology stack
Flutter, Dart, REST APIs, TanStack Query, Google Maps with heat map layers, Stripe, RevenueCat, QR scanning, in-app web views
Outcome
Zera is built as a feature-rich marketplace with several user journeys in one Flutter app, supporting API-driven interactions, location-based discovery, QR ticketing, and room for new verticals, and is launching soon on the App Store and Google Play.
What I learned
In a multi-module app, structure is the product. Users never see the folder layout, but they feel it in how fast new features arrive and how rarely old ones break.
I also wrote up the heat map approach as a public playbook: How to add a heat map to Google Maps in Flutter.