Case study 03
Product leadership · creator commerce
A production content-and-commerce platform connecting creator publishing, customer access, payments, entitlements, and revenue operations.
The original request sounded like an ‘Amazon for astrologers’: a two-month Android build where creators could publish and sell digital content. The scope quickly expanded across articles, books, courses, videos, bundles, administration, payments, and access control.
As CTO / Lead Architect, I own the product architecture, releases, commerce workflows, and production recovery. The platform moved beyond its initial low-code implementation as its operational requirements grew.
The finished architecture makes more sense when the discoveries, reversals, and responsibility shifts are visible.
FlutterFlow offered rapid delivery, but source export was the deciding condition. It gave me a path out when custom viewers, performance, and payment behavior exceeded the builder’s comfortable limits.
I own the technical direction across the Flutter clients, Firebase backend, commerce workflow, releases, and production recovery.
Duration-based prices, promotional discounts, free library saves, paid entitlements, and creator revenue attribution had to become one coherent system rather than unrelated screen states.
A real purchase incident forced me to trace payment, entitlement, and customer access as one recovery workflow rather than three disconnected features.
Each choice connects a business constraint to an implementation boundary and retained evidence.
Articles, books, courses, videos, and bundles remain distinct feature modules, while publishing and administration share one operational surface.
Evidence · The product contains five creator administration workflows and shared desktop/web CMS views.A product can expose several access durations and scheduled discounts, but Razorpay should receive one server-validated amount. Pricing selection therefore becomes a product rule before order creation, not a client-side convenience.
Evidence · The retained decision history connects multi-tier duration pricing, scheduled campaign expiry, order creation, and server-side confirmation.Payment initiation, confirmation, purchase records, and content access are treated as a state transition that can be reconciled after partial failure—not as a successful button press.
Evidence · Cloud Functions and the Razorpay path create orders, confirm purchases, and support entitlement recovery.Free content can be saved to a personal library without pretending it was purchased; paid access requires an entitlement with its own lifecycle and recovery path.
Evidence · Library state and paid purchase records remain distinct while feeding the same customer-facing catalogue.Publishing, catalog visibility, customer purchase, creator attribution, revenue share, and reconciliation must connect without trusting any single client screen.
Evidence · Creator transaction views, content administration, purchase records, and revenue-share summaries form one operational chain.Security rules, indexes, schema drift, dependencies, dead code, and production configuration are reviewed as part of carrying the product—not as a one-time launch checklist.
Evidence · The repository retains rules, index definitions, readiness audits, and remediation records.Open any diagram at its original resolution to inspect the complete workflow.
Open full resolution ↗
Open full resolution ↗Selected mobile and administration screens show the connected creator-to-customer workflow without stretching portrait captures beyond their native resolution.
Architecture is only part of the story. These constraints changed how I implemented, tested, and recovered the product.
Exportability let me replace restrictive low-code paths with maintained Flutter source while continuing to ship features instead of restarting the product.
The incident exposed the gap between payment success and usable access. Reconciliation and entitlement recovery became first-class operational concerns.
I continue to own architecture, maintenance, release decisions, and recovery when commerce or access workflows fail in production.
The product supports user accounts, five content formats, creator and administration workflows, purchases, controlled access, notifications, and multi-platform builds.
The commerce path connects duration pricing and discounts to server-created orders, durable entitlements, customer recovery, creator attribution, and revenue-share visibility.
As CTO / Lead Architect, I continue to own the product’s architecture, releases, commerce controls, and production recovery.
Evidence boundary. The portfolio demonstrates shipped workflows and production responsibility but does not publish private customer, revenue, or creator-volume figures.
Evidence basis
AI disclosure. AI tools generated or revised portions of Flutter, Firebase, testing, and documentation work within directed implementation and review workflows. I owned product direction, architecture, release decisions, production incident response, source review, and the continuing commercial and customer consequences of the system.