How Much Should a Startup Spend on Its First Software?
By CodexierPublished 6 min read
Founders usually arrive at a software budget by listing features and pricing them. That produces a number the company cannot afford and a product that answers no question. The better order is reversed: start from how long the money must last, decide what the first version must prove, and size the build to that. This guide walks through that arithmetic for a Swedish startup and lists the signs that the budget has drifted.
Budget from runway, not wishes
Runway is months of survival at current spend. The build must leave enough of it to launch, find users, learn and change the product. A workable rule: if the build and the first months of running and iterating together would use more than a third of the runway, the scope is too large for the money, however good the features look. Reduce the scope, not the runway. Founders who raise a little and spend most of it on the first build arrive at launch with a product and no capacity to sell it or fix it. Our note on funding an MVP in Sweden covers where the runway itself can come from.
What the first version must prove
A first version exists to answer a question, and the question decides the size. Write it in one sentence, then test every feature against it.
| Question version one answers | What must be built | What can wait |
|---|---|---|
| Will people pay for this? | The core job, a way to pay, a way to talk to users | Admin panels, integrations, multiple roles |
| Can we deliver this cheaper than the manual way? | The workflow for one customer type, measured | Self-service onboarding, reporting |
| Will users come back without being asked? | The core loop and basic notifications | Everything else |
| Can this work for a large customer? | Security basics, one integration they need, a pilot | Scale, polish, marketing site |
If your sentence has the word 'and' in it, you have two versions. Build the first.
Build, run and iterate costs
The build is the visible cost and the one every quote covers. The two that follow are smaller per month and larger over the year, and they are the ones a first budget usually omits.
Build
Planning and architecture, then development and deployment of the version-one scope. A fixed-price plan such as our MVP planning blueprint followed by MVP development makes this line predictable; the amounts are on the pricing page.
Run
Hosting, database, email delivery, error tracking, domain, any paid APIs, plus the tools the team uses. Small at first, but monthly and forever, and it grows with users.
Iterate
Changes after launch: fixes, the feature users actually needed, removing the one they did not. Budget a monthly amount of developer time from launch, not from when problems appear.
Everything around it
A landing page, legal texts, payment provider setup, bookkeeping for subscriptions and the time founders spend selling. Not software, but part of the same budget.
Keeping money for version two
Version one will be wrong in a way you cannot predict, because the point of building it is to find that out. The budget therefore needs an explicit reserve for version two, roughly the same size as the iterate line for the first months, kept untouched until launch has produced evidence. Founders who spend that reserve on extra features before launch have bought certainty about the wrong things.
- Write the version-two reserve into the budget as a line with a date it may be spent from.
- Decide in advance what evidence unlocks it: paying customers, retention, a pilot signed.
- If the evidence does not come, the reserve funds a pivot or an orderly stop, both of which are better than a bigger version of the wrong product.
- Choose a build approach that makes version two cheap: a tenancy model and a data structure that survive growth, which is what our multi-tenant architecture guide is about.
Signs you are overspending
The budget has drifted when the feature list grows after the question was set; when the build is scheduled to take longer than the time you can wait before selling; when the quote includes an admin system, a mobile app and a marketing site for a product that has not yet been used by a stranger; when the running costs were never estimated; or when the founders cannot say what evidence would make them stop. Each is fixable by going back to the one-sentence question and cutting until the scope fits a third of the runway.
When you do not need a custom build at all: if the question can be answered with a spreadsheet, a no-code tool, a landing page and a manual process behind it, do that first and spend nothing on software until the manual version is straining. We say this to founders on calls and mean it; the SaaS and MVP overview describes when a real build becomes the right step. If you have the one-sentence question and a runway figure, book a free 15-minute call and we will size version one against it with you.
Frequently asked questions
Is there a typical first-build budget for a Swedish startup?
Not a useful one; it depends entirely on the question the product must answer and the runway available. A fixed-price MVP plan and build give you a known number to test against your runway, which is more useful than an industry average.
Should we hire a developer instead of buying a build?
A hire makes sense when the product is the company and there is more than a year of work ahead. For a first version that must prove something within months, a fixed-price build with a clear scope is usually cheaper and faster, and leaves the hiring decision for after the evidence.
How do we estimate running costs before launch?
List every service the product depends on and its pricing tier at launch volume: hosting, database, email, error tracking, paid APIs, domains and team tools. Add a margin for growth. It is usually a modest monthly figure at first, but it is permanent.
What if investors expect a bigger product?
Investors fund evidence, not feature counts. A small version that shows paying customers or retention raises more easily than a large one that shows nothing. Explain the question version one answers and how the reserve funds version two.
Have a runway number and a product idea?
Bring both, plus the one sentence version one must prove. In fifteen minutes we size the first build against your runway and tell you what to cut.
Book a free 15-minute call