How long does it take to build an app, alone?
The build is rarely the long part. Auth, billing, email and the hundred small states are, and none of them is on anyone's plan.
The short version
- Four to eight weeks part-time to something chargeable, if scoped brutally.
- The feature is a third of it. Auth, billing, email and error states are the rest.
- Long builds fail on information, not effort. You find out too late to act.
- Ship at embarrassing. The first version exists to be corrected, not admired.
- Then it never ends. Support, bugs and small changes are the actual job.
The honest range
Four to eight weeks part-time gets you something a first customer can pay for, if the scope is genuinely one job for one kind of person. Something you would happily demo is several months. The range is wide because the variable is not your speed. It is how ruthlessly the first version was cut, and almost everyone cuts too little.
Where the time actually goes
This is the part that wrecks estimates. People estimate the feature; the feature is about a third.
| Part | Share of the build | Interesting? |
|---|---|---|
| The thing it does | ~35% | Yes |
| Auth, accounts, password reset | ~15% | No |
| Billing, plans, failed payments | ~15% | No |
| Transactional email | ~5% | No |
| Empty states, errors, loading | ~15% | No |
| Deploy, domains, backups | ~10% | No |
| Legal pages, cookie notice | ~5% | No |
The bottom six rows are identical in every product ever built and are what nobody plans. They are also why a starter kit or boilerplate for auth and billing is worth paying for: those weeks are not where your product becomes different from anyone else's. The SaaS tech stack for solo founders covers choosing them, and taking money is the billing half.
Why long builds fail
Not effort. Information.
A six-month build means six months before anyone tells you whether the thing is right, and by then you are too invested to hear it. The failure is not that it took long; it is that you spent the whole time unable to learn anything.
A four-week build that is wrong costs four weeks. The shortness is the risk control, which is the actual argument for a small first version (not speed, and not discipline). How to scope a SaaS MVP you can actually finish is that cut, and validating the idea is the cheaper step before it.
Making it shorter
- One job, one user. If the description needs "and", it is two products.
- Buy auth and billing. Nobody pays you for a password reset.
- No admin panel. Query the database yourself for the first six months.
- No settings. Every option is a decision you failed to make, plus a branch to maintain.
- Manual behind the curtain. If a step is hard to automate, do it by hand until the volume hurts. Users cannot tell.
- One platform. Web. Not mobile too: shipping to the app stores is its own project.
- Defer every integration until someone asks twice.
Point five is the strongest and the least used. A product that is half a person doing things manually still validates the demand, and it ships in a fraction of the time.
No-code compresses the same path further and hits real limits at scale and at anything unusual: how to build a SaaS without code is where those limits are, and by the time you find them you know whether rebuilding is justified.
AI genuinely helps with the boring 65% (scaffolding, forms, error handling) and helps least with the part that makes the product worth buying: how to build a SaaS with AI.
Ship at embarrassing
The first version should feel slightly too early. Not broken. Too small.
Everyone who waited until it felt ready describes the same thing afterwards: the features they agonised over were not the ones anyone mentioned, and the first real user found something in ten minutes that months of solo work had not surfaced.
Get to your first customers sooner and let their confusion set the priorities. The waitlist is worth exactly what it converts and no more.
Then it does not end
Worth knowing before starting: the build is the short part of owning a product.
After launch it is support, bugs, small changes, payment failures, an API that changed under you, and the slow work of onboarding and churn. That is not a phase before the real thing. It is the real thing, and the build was the prologue.
Which reframes the original question. "How long to build a SaaS" matters less than how long you can keep running one, and the second is decided by how small you kept the first.
A realistic schedule
For one job, one user, part-time alongside other work:
| Week | What |
|---|---|
| 1 | Scope brutally, choose the stack, set up auth and billing from a kit |
| 2–4 | The thing it does, badly but end to end |
| 5 | Payments actually working, including the failure cases |
| 6 | Empty states, errors, transactional email |
| 7 | Landing page, legal pages, deploy |
| 8 | First ten users, by hand |
Slipping to twelve is normal. Slipping to twenty-six means the scope was never cut, and the fix is cutting, not working harder.
Frequently asked questions
How long does it take to build a SaaS as a solo founder?
Four to eight weeks of part-time work to something a first customer can pay for, if the scope is one job for one kind of user. Anything you would demo proudly is months, and most of that time goes to the parts nobody plans for.
Why does it take longer than I planned?
Because the feature you are excited about is roughly a third of the work. Authentication, billing, transactional email, permissions, error states and the empty screens take the rest, and none of them is interesting enough to estimate.
Should I use a boilerplate or a starter kit?
Yes, for auth and billing especially. It removes the least differentiated and most fiddly weeks of the build, and nobody buys your product because you wrote your own password reset.
Can I build a SaaS with no code?
For a first version that proves people will pay, often yes. The limits arrive with scale and with anything unusual, and by then you know whether rebuilding is worth it.
How small should the first version be?
One job, for one kind of person, end to end. If you cannot describe it in a sentence without the word 'and', it is too big for a first version.
The system behind this, written down
Everything above is the map. The Income Loop is the work inside it: modules 0–6 from the problem you solve to the offer that pays for it, plus ten traffic paths: the deeper post banks, the content sales systems and the full software build sequence, in one place.
Get The Income LoopNot ready to pay for anything? The Basic Income Loop is free and includes a complete seven-day starter for Threads, Instagram or software, enough to find out which one suits you before spending anything.