How I ship a production app in a week, solo
The studio pipeline that turns an idea into a live iOS and Android app: a shared product engine, a rebrand starter, and native billing wired once and reused everywhere.
Most of the cost of a new app is not the idea. It is the plumbing. Auth, billing, analytics, a paywall, a design system, a landing page, store setup. Build that from scratch every time and a small app takes months. So I stopped building it every time.
The studio runs on a product engine: a set of shared packages every app imports, plus starters I clone and rebrand. The idea is simple. Solve each hard problem once, then reuse the solution across every product.
The engine, not the app
The shared layer lives in one place and path links into every app. Analytics with one unified event schema. A billing client that wraps StoreKit 2 and Play Billing. Config driven paywall screens. Auth. Remote config. Each is a package, not a copy pasted folder, so a fix in one place reaches every app at once.
On top of that sit two starters: a Flutter app scaffold and a web landing scaffold. A new product is a clone plus a rebrand, not a green field.
The week
- Day 1: clone the Flutter starter, edit four config files (theme, brand, copy, the questions the app asks), point it at a fresh Firebase project.
- Day 2 to 4: the actual product. The unique part. Everything generic already works, so the whole week goes into what makes this app worth shipping.
- Day 5: the landing page from the web starter, one config file for the brand.
- Day 6 to 7: store listings, screenshots, a release build straight to App Store Connect and Play Console.
The number that matters is not seven days. It is that six of them go into the product and one into everything else. Reuse buys back the boring week.
Why solo can move this fast
A team spends real time coordinating. Solo with an agentic pipeline, the coordination cost is near zero and the reuse cost is near zero. The engine makes the marginal app cheap. That is the whole thesis: small team quality and speed, one operator.
Six products shipped so far, four of them live. Each one made the next one faster, because each hard problem it hit got solved in the shared layer and never came back.
If you want the same speed, do not optimize the app. Optimize the second app, and the tenth. Build the engine first.
One operator, idea to live product. Web and mobile, designed and shipped end to end.
Work with meFrequently asked
- Can you really ship a full app in a week?
- The generic plumbing is already built and reused, so a week goes almost entirely into the product itself. The timeline holds because the starting point is not zero.
- What is the product engine?
- Shared Flutter packages (analytics, billing client, paywall, auth, remote config) plus app and web starters, path linked into every product so a fix in one place reaches all of them.
- Does this work for client projects too?
- Yes. The same engine and starters power both my own apps and client builds, which is what keeps client work fast and consistent.
Related
One landing template for every app
Instead of hand building a marketing site per product, the studio runs one config driven Next.js landing template. Two presets, one brand file, and a new site is a clone.
ReadWhy I dropped RevenueCat for native billing
The studio verifies purchases with StoreKit 2 and Play Billing directly, through one shared Cloud Function, with no third party billing middleman. Here is the tradeoff and why it wins at this scale.
ReadAn AI-native product studio, one operator
The thesis behind Principle Socials: an agentic pipeline that ships at small team quality and speed, run by a single operator, selling outcomes rather than hours.
Read