ShipAppFast vs starting from scratch in Cursor: same agent, worse first month

Cursor is not the thing that makes the first month slow. The empty project is. ShipAppFast is that project already built, so the same agent spends the window on the feature you actually meant to make.

The short answer

Building a Flutter app from scratch in Cursor or Claude Code works. It is also how a founder spends four weeks on auth, Gradle, and a paywall before anyone can open the idea. ShipAppFast is a production Flutter repo with that layer done, plus a written guide the agent reads first. Same models. Different starting point.

Buy the kit if you are shipping a product. Skip it if you are learning Flutter, or if the app has no accounts, no payments, and no push. The hour-by-hour version of the from-scratch cost is in Flutter boilerplate vs building from scratch. This post is about what the agent does with each starting point.

The empty repo is the expensive part

An agent is good at a local change with a clear pattern nearby. It is bad at being the first person in a project. On a blank flutter create, the first sessions look the same.

Week one, it scaffolds a structure it will not remember tomorrow. Week two, it is still wiring auth, payments, and push, and each of those has an edge case the model has half-seen. Week three, a toolchain error has no stack trace that points at the fix — Kotlin against the Android Gradle Plugin, CocoaPods against Swift Package Manager — so it guesses, and guesses cost tokens. Week four, there is still nothing you can hand someone.

That is not a model problem. The next model will do it too, because the project never told it how this app is built.

ShipAppFast inverts the month. Day one, the agent opens a tree it can reason about. Auth, payments, and push are already wired. The toolchain is pinned. The app runs on mock data with no backend and no keys, so the agent can launch it, see the screen, and find its own mistake. You brand the shell. You describe the feature. The plumbing is not the prompt.

What “already built” means, specifically

The kit is not a folder of disconnected samples. The screens are connected, which is the property generated projects usually lack.

Accounts: email, Google, and Apple sign-in, one-time codes, phone verification, password reset, profiles, and account deletion. Navigation with guards, so signed-out users do not wander into signed-in pages. Onboarding you reword instead of design. Push. Themes, dark mode, and two languages including right-to-left. RevenueCat and Superwall for subscriptions and entitlements. PostHog, Google Analytics, Sentry, and Crashlytics. Firebase, Supabase, or a custom API behind the same repository idea. Riverpod as the state approach, so the next feature has one right shape.

The homepage maths for that pile is about 29 days before the idea starts: auth, routing, networking, signing and keys, push, theming, payments, toolchain, and the agent re-reading it all. Call the human version three to five weeks if you have done it before. Longer if you have not. The from-scratch post has the line items.

Complete, at $149 in the founding run, adds the part a raw repo never has. CLAUDE.md and AGENTS.md with the rules. Eight recipes that name the files. A /new-feature command. A canonical feature to copy. Starter, at $119, is the codebase without that agent layer. After the first 50 licences those prices go to $219 and $249, still once, and buying in the founding run holds your price against that increase. Lifetime updates come with Complete.

Side by side

	Cursor or Claude Code, empty repo	ShipAppFast, then the same agent
First hour	Scaffold, pick packages, argue with yourself about structure	Clone, run, read the guide
Auth and Apple sign-in	A multi-day prompt thread	Already in the app
Payments	StoreKit, Play Billing, restores, a paywall	RevenueCat and Superwall wired
Runs with no keys	No	Yes, mock data
Toolchain	The agent meets it live	Pinned, with the known failures already documented
How the agent learns the project	By re-reading it	From the files it is supposed to read first
Review of agent diffs	“Is this sane?”	“Does this match the pattern?”
Cost	Cursor subscription, plus the month	Cursor subscription, plus $119 or $149 once
When it is the right call	Learning, or a strange architecture	Shipping

The four agent failures a boilerplate is aimed at

The context tax. Every minute the model spends mapping the tree is a minute it does not spend on the feature. Conventions written down in the entry files are cheaper than a 40-file tour.

The loop. Toolchain failures are the worst input an agent can get, because nothing in the log names the fix. A pinned, already-built project does not ask the model to invent a Gradle resolution at 1 a.m.

The window. Password reset, OTP, session restore, and token refresh can each eat a full context window. They are solved problems. Spending the one good window on a login screen is how side projects die.

Review fatigue. If there is one way to add a feature and it is written down, you can check a diff at a glance. If every screen is a fresh opinion, you are the senior engineer for a junior that does not sleep.

None of these go away because the model got better. A better model on an empty repo is a faster way to produce an unreviewed auth stack.

Where starting from scratch is the better choice

Start empty if you are learning Flutter. A boilerplate hides the lessons you opened the editor to learn. That is a feature if you are shipping, and a bug if you are studying.

Start empty if the app does not need accounts, money, or notifications. A single-screen utility does not need this repo. The kit pays for itself when those three show up.

Start empty if the architecture is the product — a custom renderer, a strange sync model, something Riverpod-plus-a-repository would fight. Do not buy a convention you are about to delete.

And do not buy it to avoid thinking. The agent will still invent a bad feature if you describe a bad feature. The guide stops it inventing a second auth system. It does not stop you shipping a clone Apple will reject under Guideline 4.2.

How to actually use it with Cursor

Drop the project in. Let the agent read the guide before you ask for anything. Describe the feature you care about — a habit tracker, a basket, a deal feed — and point it at the recipe rather than at “build me an app.” Check the diff against the canonical feature, not against your memory of a tutorial.

Wire the real backend the day you need one. Until then, mock data is the point: you can hand someone a build without spending the config afternoon first. When you do wire it, the Firebase vs Supabase trade-off is the decision, and API keys in the client is the mistake the agent will make if you let it.

Subscriptions stay on RevenueCat and Superwall. The reason not to let the model write StoreKit by hand is in RevenueCat vs Superwall.

FAQ

Is a boilerplate still worth it if Cursor can generate auth?

It can generate a screen that looks like auth. The rejects live in the edges: Apple’s sign-in rule, account deletion, token revoke, restore purchases, sandbox versus production, APNs. Generated auth fails in review more often than it fails on your phone. A fixed shell that has already been aimed at those rules is the safer base for everything the model writes next.

Do I still need a Cursor subscription?

Yes, if Cursor is your editor. ShipAppFast does not replace the agent. It gives the agent a project worth opening. Claude Code, Copilot, OpenCode, and Codex are the same idea.

Starter or Complete, if the agent is the point?

Complete. The agent layer is the difference between a good repo and a repo the model can extend without a tour. Starter is the right buy only if you will write the features yourself and you do not want the guide.

Will the agent stop hitting build errors?

It will stop hitting the ones that come from an unpinned first-week toolchain. It will still hit errors in the feature you asked for. Those have a stack trace. Those are fine.

The agent was never the scarce thing. The month before the idea starts is. ShipAppFast is that month, already spent.