Fixed-price SaaS MVP: how to get your first version live

A SaaS MVP built by an agency typically costs DKK 100,000–600,000 on an hourly basis. At NBS, a custom build starts at DKK 14,995 (≈ €2,200) on a fixed quote for a tightly scoped first version, and ongoing product development runs on the Studio plan at DKK 8,950 a month. All prices are ex. VAT. The gap between those numbers is not magic. It is scope discipline: a fixed-price MVP works when you cut the feature list down to the one workflow that proves the idea, and it fails when “MVP” quietly comes to mean “version one of everything”.

We have built and launched three SaaS products ourselves: KalorieTracker, NBS Booking and NBS Food, all live with real users. So this is not a guide written from the outside. It is how we scope our own products, and how we scope yours.

What a SaaS MVP costs in Denmark

Here is the honest market picture. Most Danish and European agencies quote by the hour, typically DKK 375–900 depending on country and seniority, and a “small” MVP is usually estimated at 300–800 hours. That puts typical quotes in these ranges:

Two clarifications on our own numbers, since they are our own and deserve scrutiny. First, DKK 14,995 is a starting price for a genuinely minimal product: one core workflow, login, a database, an admin view and hosting in the EU. A product with billing, several user roles and integrations lands higher, and you get the final number in writing before work starts. Second, Studio is not a discount trick; it is a different model. Instead of one large invoice, you get a team working on your product every month, and you can stop when you want.

Our fixed prices sit below typical agency quotes for structural reasons, not heroic ones. We are three developers in Aalborg without account managers or office overhead. We reuse a hardened hosting and deployment setup across projects instead of rebuilding it each time. And a fixed scope removes the estimation padding agencies add to protect themselves on open-ended contracts.

Where the money actually goes in an MVP budget

On a typical hourly engagement, a surprising share of the budget is not product code:

• Discovery and specification: 10–20 % of hours, often billed before any code exists.
• Project management and meetings: 10–15 % on agency engagements.
• Environment and deployment setup: 5–10 %, repeated from scratch per project at many shops.
• Rework from scope drift: unbounded, and the main reason hourly projects overrun.

A fixed scope compresses the first three and eliminates the fourth by definition. That is the entire economic argument.

SaaS MVP or mobile app? Not the same budget

People often mix up the two, so let us be clear. A SaaS MVP is a web application: it runs in the browser, on every device, and you deploy a change the minute it is ready. A mobile app runs on iOS and Android, goes through two app stores, and every change waits for approval. That is why an app with user accounts and a server typically costs DKK 100,000–350,000, while a SaaS MVP with the same core can start much lower. We cover the app side in what an app costs.

For almost every SaaS idea, the web version comes first. KalorieTracker is the exception that proves the rule: it needed the camera and the home screen, so it became an app, but it also runs as a web app on the same account and the same data.

Fixed price or hourly billing for a SaaS MVP?

Hourly billing is the right model when requirements are genuinely unknowable and you have the budget to explore. For a first version of a SaaS product, that is rarely the situation. You usually know exactly what you need to prove: that a specific user will use a specific workflow and pay for it.

A fixed price on a fixed scope means:

• You know the total cost before signing. No burn-rate anxiety, no invoice surprises.
• Delivery risk moves to the vendor. If we underestimate, we absorb it. That forces us to scope honestly up front instead of estimating optimistically and billing the difference.
• Scope changes are explicit. New ideas go on a list for version two rather than silently inflating version one. This sounds restrictive; in practice it is the discipline most first-time founders need most.

The model has a real weakness worth naming: a fixed-scope contract with a vendor who scopes badly produces a product that technically matches the spec and practically misses the point. The fix is to judge the vendor on how they scope, not just what they charge. A good fixed-price shop will push back on your feature list before quoting. If they accept twelve features without argument, the price is not the problem.

How to scope a SaaS MVP that ships in weeks

The scoping conversation we run with every MVP client comes down to four questions.

1. What is the one workflow that proves the idea?

Not the product. The workflow. “A salon owner puts her opening hours online and a customer books a slot without calling” is a scopeable MVP. “A booking platform” is not. That single path is what NBS Booking started as. Everything in version one should serve one path from signup to value.

2. What can you fake, buy or skip?

• Fake: admin dashboards (a database client works for the first ten customers), email sequences, analytics dashboards.
• Buy: login, payments (Stripe, MobilePay), transactional email, file storage. Building any of these yourself in an MVP is a budget fire.
• Skip: native mobile apps, multiple languages, SSO, granular permissions, a public API. All are version two or later for almost every SaaS.

NBS Food is a good example of the “buy” line. A restaurant ordering system needs payment on day one, and we did not write a payment system; we connected one. What we built was the part nobody sells off the shelf: the ordering flow itself, without a commission to a third party.

3. What does the data model need to survive?

The one place we deliberately over-invest in an MVP is the database schema and data ownership. The interface can be rewritten cheaply; migrating a bad data model with live customers cannot. This is also where Danish requirements enter early: if your customers are Danish businesses, they will ask where their data lives. Building on Danish or European hosting from day one is cheaper than migrating later, and it is a genuine sales asset in B2B deals. We cover the background in Danish hosting or US cloud, and it applies doubly to SaaS, where you are a data processor for every customer you sign.

4. What happens after launch?

An MVP without a plan for week two is a demo. Budget for maintenance and iteration before launch, not after. Our Growth plan (DKK 975 a month) covers hosting, monitoring, security updates and small changes; Studio (DKK 8,950 a month) covers ongoing feature development. Whatever vendor you use, get the post-launch cost in writing before you sign the build contract, because this is where “cheap” builds get expensive.

GDPR: the part most MVP guides skip

If you sell SaaS to Danish companies, GDPR is not a version-two feature. Your MVP will process personal data from day one, which means from day one you need:

• A lawful basis and a privacy policy that reflect what the product actually does.
• A data processing agreement you can hand to business customers. B2B buyers increasingly ask for one during procurement, even from tiny vendors.
• Known data residency. “It’s on some US cloud, probably Frankfurt” does not survive a customer’s vendor questionnaire. A named Danish or European host does.
• Deletion and export paths. They can be manual at MVP stage, but they must exist.
• Retention rules. If the product touches invoices or orders, the Danish Bookkeeping Act requires five years of storage, so “delete everything on request” needs an exception built in.

None of this is expensive if it is built in from the start. All of it is painful to retrofit. It is why we host every MVP in the EU by default, and why our analytics setups are cookieless, so your marketing site is not accruing consent debt while you validate the product.

Red flags when choosing an MVP agency

• No published pricing anywhere. If every price requires a sales call, expect the quote to be calibrated to your perceived budget. This cuts both ways: our prices are public at /priser precisely so you can hold us to them.
• A quote without a written scope. A fixed price attached to a vague scope is just hourly billing with worse incentives.
• “We’ll use our proprietary platform.” That is lock-in dressed as efficiency. You should own the code and the hosting accounts.
• No answer on data residency. For a Danish SaaS, “where does customer data live?” should get a one-sentence answer.
• An MVP estimate above DKK 750,000. At that price you are not buying an MVP; you are buying someone’s guess at version three.

Where to go from here

If you are still deciding whether you need a full application or a website with some smart forms, start with the difference between the two. Many “SaaS ideas” validate fine with far less software than founders assume. If the workflow genuinely needs a product, scope it down to one path, insist on a written scope and a fixed price, and make sure it ships on hosting you own in a jurisdiction your customers accept.

That is exactly how we run MVP projects, and how we built our own. See what a Build engagement includes on web apps, check the numbers on pricing, or, if you are weighing a simple product against a website project first, read what a website costs for the other side of the ledger. Either way: fixed scope, fixed price, hosted in the EU, and version two planned before version one ships.

Frequently asked questions

How long does a SaaS MVP take? Three to six weeks for a genuinely minimal first version. Add billing, several user roles and integrations, and it becomes two to three months.

Can I start on Studio instead of a one-time build? Yes. Some clients prefer a monthly plan from day one so the product is built and improved continuously rather than delivered once. The right choice depends on whether you have a clear version one or an evolving idea.

Do I own the code? On a one-time build, fully: code, data and hosting accounts. On Studio we host and maintain it, and you can ask for a complete handover at any time.

What if I want to change something halfway? Then we price the change in writing before it is built, exactly like the original scope. The alternative, changes billed silently by the hour, is how budgets double.