At a Glance
- Three weeks from spec to App Store and Play Store, including a Next.js web app at finlyofficial.com
- Seven interactive finance games, 22 Parse classes, around 40 cloud functions, 63 Vitest tests
- Our first paid agency engagement, built on the same stack we use for our own consumer apps
- The “secret” is that there isn’t one. We didn’t start from scratch.
Who Finly is
Finly is a financial-literacy platform for teens and students. The team came to us with a clear product vision: seven interactive games that teach money concepts (budgeting, credit, saving, investing) wrapped in a points-and-leaderboard loop that keeps users coming back. They wanted iOS, Android, and web. They wanted it in three weeks.
We said yes for one reason. The shape of the brief mapped almost perfectly to patterns we’d already built and shipped eight times in our own app ecosystem. If they’d asked for a CAD tool, or a video editor, or anything that didn’t intersect with our existing surface area, we would have passed. Agency work compounds only when the foundation under it is real.
What we didn’t build from scratch
This is where the three-week timeline becomes possible to take seriously.
Our consumer apps (Zistil, Zots, Zyve, Zupply, Zarden, Zynq, ComingUp, Zuzzle) all share a foundation we’ve been maturing for years: 33 production-tested Flutter packages, a Parse-based backend on Back4App, a unified email/OTP authentication system, a deploy pipeline with Fastlane lanes for both stores, and a CLAUDE.md rulebook that encodes every hard-won pattern we’ve earned.
For Finly we lifted:
- The Flutter app skeleton, with its module-per-feature layout, design tokens, navigation router, and Parse service wrapper. The first day of any new app is mostly already done.
- Email/OTP authentication, adapted in hours instead of weeks. Send OTP, verify, mint session, the reviewer bypass for App Store and Play Store submissions, all of it from the same playbook.
- A database-driven content model. Every game’s content (budget items, credit scenarios, dilemmas, savings goals, stocks, market news) lives in Parse classes the client can edit from the Back4App dashboard. No code changes for content updates. We’ve shipped this pattern enough times to know it pays back tenfold over the life of any app.
- The cloud function module pattern, the schema-validation pre-deploy gate that catches typos and missing fields before they reach production, and the deployment scripts.
Conservative estimate: this saved four to six weeks of from-scratch work. That’s the gap between “yes, we can do this in three weeks” and “let us get back to you in two months.”
If you’ve ever wondered what an agency means when they say they have “a mature stack,” this is what it looks like in practice. It isn’t reusable code in the abstract sense. It’s a body of opinionated decisions, written down, that we don’t have to re-make for every client.
What we did build from scratch
The Finly-specific work was substantial.
Seven games, each with its own mechanic:
- Finance Quest, a Q&A combat game where players battle monsters with finance knowledge
- Flashcard Frenzy, timed term-definition matching against a glossary
- Budgeting Blitz, a monthly budget simulation
- Credit Climb, a credit-score decision simulator
- Financial Dilemmas, a “Would You Rather?” scenarios game built around financial principles
- Budget Challenge, a savings-goal game with weekly events
- Investment Voyage, a stock-market portfolio simulator with simulated news
Each game has its own Parse class for its content (BudgetItem, CreditScenario, DilemmaScenario, SavingsGoal, WeeklyEvent, SimStock, MarketNews), so the Finly team can author and tune every game from the dashboard without touching code.
Beyond the games:
- 22 Parse classes total, covering users, content, quizzes, progress, trophies, leaderboards, notifications, the team page, glossary, career spotlights, and economics concepts
- About 40 cloud functions, grouped into eight modules (auth, content, progress, trophies, leaderboard, notifications, account, public)
- Scheduled jobs for periodic leaderboard snapshots (weekly and monthly) and pending-account-deletion processing
- A Next.js web app at
finlyofficial.com, served from Cloudflare Pages. We chose Next over Flutter web because the audience (teens and students) opens links from school Chromebooks more often than from native devices, and a real React app loads faster, ranks better in search, and feels right on the surface that matters most to them. - 63 Vitest tests covering all seven games’ logic: grading, scoring, pass thresholds, edge cases
Everything was wired into the same operational rhythm we use for our own apps. Schema validation runs before every cloud deploy. Tests run before every commit. Fastlane handles the store submissions. The discipline is the product.
The honest sidebars
A case study without friction is fiction. Three things didn’t go smoothly. None of them broke the project, but they shaped how we’ll structure every future client engagement. The solutions look different for every client, so we’ll keep this short on remedies and long on the pattern.
SendGrid trial expiry broke OTP login. Twice. Email-based OTP only works as long as the email actually sends, and trial tiers have cliffs that hit without warning. Lesson: insist on paid email infrastructure in the first week of any client engagement, before the project depends on it.
Apple Developer enrolled as Individual. Apple’s Individual tier doesn’t support team members. For a client engagement where the developer and the account owner are different entities, that’s a structural mismatch with a planned transfer path. Lesson: corporate-tier accounts (Apple Organization, paid email, dedicated Cloudflare team) belong in the kickoff checklist, not the wrap-up checklist.
Post-launch feedback iterations. Shipping to the store is not the end of the project. Two weeks after submission, the client surfaced real issues that needed real work. Plan for it. Build the relationship around iteration, not handoff.
Any agency that tells you client engagements run on rails is selling you something. We’d rather be honest about the friction and show how we work through it.
Week by week
Week one. Scope, scaffold, schema. Take the Finly brief, map it to our existing patterns, and stand up the skeleton. Flutter app with module folders, Next.js project with route shells, Parse schema (22 classes), cloud function modules (auth, content, progress). Authentication working end to end by day five. No game logic yet, just the floor.
Week two. Build the games. One mechanic per day, occasionally two. Vitest tests for each as we go, because a game with a grading bug in production is the worst kind of bug. A kid loses points for getting the right answer. Content model wired so the Finly team can start authoring real questions, scenarios, stocks. Leaderboard, trophies, notification skeleton.
Week three. Polish, store submission, and the parts that look small but consume real days. App Store screenshots for two screen sizes. Reviewer bypass account documented and tested. App-store rating questionnaire (Everyone, IARC). Privacy policy. Fastlane lanes for both stores. Web deploy to Cloudflare Pages. Manual smoke pass on a real device for every game. Submit.
Approval came faster than expected. Live in stores by end of week three.
What the Finly team said
“This is huge. The biggest step in Finly’s journey so far. We wouldn’t have gotten here without Zovia’s dedication, guidance, and support.”
Arjun Poddar, CEO, Finly
What we’d do differently next time
The patterns above are codified now into the playbook we use for every new client engagement.
- Corporate accounts on day one. Apple Organization enrollment, paid email, dedicated Cloudflare team. We bring a kickoff checklist and we don’t let the project move past it.
- Two-options pitch up front. Either the client owns every account and we get added as collaborators, or we host on our infrastructure under a monthly maintenance arrangement. We don’t proceed without one or the other agreed in writing.
- Iteration is in the contract. Two weeks of post-launch support is the default, not a courtesy. The relationship that matters is the one after submission, not before.
- Content ownership is named. Who owns the game data, the copy, the brand assets, the cloud function source. Written down before week one.
None of these would have changed the Finly outcome. The project shipped, the client is happy, the product is in users’ hands. All of them will make the next engagement smoother.
If you’re thinking about hiring us
This is the kind of work we want to do more of: small client teams with a real product vision who need a fast, opinionated, production-grade build on top of a mature foundation. Three weeks isn’t the right scope for every project, but for the right project it’s exactly enough.
If that sounds like you, see how we work →.