Flutter boilerplate vs building from scratch: the actual maths
A starter template costs around a hundred and fifty dollars. Building the same layer yourself costs about a month. Here is the honest version of that trade, including the cases where you should not buy one.
The argument against buying a Flutter starter is usually some version of "I could build that myself".
You could. That is not in dispute, and anyone selling you a template who pretends otherwise is insulting you. The question is not capability. It is what the month costs, and what you would otherwise have done with it.
The short version
Build from scratch if you are learning, if your app genuinely does not need accounts or payments, or if you have unusual architectural requirements that a template would fight.
Buy a template if you are trying to get a specific product in front of specific users and the setup layer is not the product.
The break-even is roughly one day of your time. Almost nobody builds this layer in one day.
What "from scratch" actually contains
flutter create gives you a counter app. Between that and something you can charge money for, this is the list. Not a hypothetical list — the one that exists in every consumer app on both stores.
Accounts. Email sign-up, Google, Apple — Apple sign-in is mandatory if you offer any other third-party login. Password reset. Email verification. Phone verification with one-time codes. Session handling that survives a token refresh and an app restart. Route guards so signed-out users cannot reach signed-in screens.
Account management. Profile editing with a photo upload. And account deletion — Apple has required an in-app delete path for any app with sign-up since 2022, and it is a common rejection.
Money. StoreKit and Play Billing, receipt validation, entitlement state that is correct across reinstalls, refunds, billing retries, grace periods and upgrades. A paywall that handles cancelled, failed and pending purchases without a dead end. Restore purchases, which Apple also requires. Sandbox testing, which behaves differently enough from production to eat a day on its own. Most of this is why you use RevenueCat rather than writing it — but wiring RevenueCat correctly is still a week.
Push notifications. FCM, APNs certificates, the permission request at a moment that does not get denied, foreground versus background handling, deep links from a notification into the right screen, token storage and cleanup.
The unglamorous rest. Onboarding. Force-update. Offline states. Error handling that is consistent rather than per-screen. Analytics with real events. Crash reporting. Localisation setup. Light and dark themes that hold together.
Submission. The App Store list, which is its own few days the first time.
Every item is known work. None of it is your idea. All of it has to exist before you can take a payment.
The maths, honestly
Call it three to five weeks for a competent developer who has done it before. Longer the first time, because half these items have a gotcha you only learn by hitting it — Apple's sign-in requirements, the APNs key, the entitlement edge cases, sandbox behaving differently.
Against that, a template is $119 to $149 one-off.
If you contract at any rate at all, the comparison is not close. If you are a solo founder with no billable rate, the real cost is five weeks of calendar time before you learn anything about whether your idea works, which is the more expensive number of the two.
The counter-argument that deserves respect: building it yourself means you understand it. That is genuinely true and genuinely valuable — the first time. It is much less valuable the third time, and by then you are rebuilding the same auth flow again for reasons that are mostly sentimental.
"Can't I just generate it?"
This is the live version of the question now, and it deserves a straight answer rather than a dismissal.
Prompting a project into existence works, and the demo is impressive. What it does not do reliably is produce the boring layer correctly, because the boring layer's correctness is invisible at generation time. Generated code that works and generated code that is safe look identical on your screen.
The failure modes are consistent: API keys written into the client bundle, because the model put the key where the call is. Database rules left permissive, because tightening them is a console task the model cannot see. No rate limiting, because no prompt asked for it. Entitlement checks that pass locally and can be bypassed. An auth flow missing the account-deletion path, which review will catch for you.
And regeneration does not compound. Each fresh generation is a new codebase with new conventions, so the fixes you made last week are not in this week's version.
A template is the opposite trade. It is boring, it is fixed, it has been through App Store review, and every future feature — generated or hand-written — lands on top of something already correct.
When you should not buy one
Being straight about this is the only way the rest is worth reading.
You are learning Flutter. Then the month is the point. Build it. Skipping the work skips the learning, and you will not understand the codebase you bought.
Your app has no accounts, no payments and no push. A calculator, a local-only utility, a toy. The list above is mostly empty and a template is overhead.
You have strong architectural opinions that differ. If you have a house pattern you will apply regardless, you will spend the first week undoing someone else's, which is worse than starting clean.
It is your third app and you have a personal starter already. You solved this. Use yours.
What a good one is actually worth
A bad template is a pile of files with a feature list. You can tell because every landing page has the same list, and the list is not the hard part.
What matters is whether the pieces are connected — whether auth state actually drives the route guards, whether the entitlement is readable from the screens that need it, whether the paywall handles a failed purchase, whether it has been through review — and whether there is one pattern per job rather than four. That last one used to be a style preference. It is now the main thing, because an AI agent working in your project copies what it finds, and a codebase with four patterns produces a fifth every time you ask for a feature.
ShipAppFast is built for exactly that. It is a production Flutter template — Riverpod, auto_route, Dio, Firebase or Supabase or your own API behind a repository layer, RevenueCat and Superwall for subscriptions, PostHog and Sentry and Crashlytics wired — where the whole list above is already built, already connected and already shipped. The conventions live in the files your agent reads first, so what it copies is the correct pattern. Starter is $119, Complete is $149, both with lifetime updates and no subscription.
You are not buying files. You are buying the month, and the certainty that the boring layer is right.