What drives the cost of a SaaS MVP: what to build and what to buy

A SaaS MVP is the first working version of a subscription software product: enough to find out whether your idea holds, before everything is built. What it costs depends on what that first version has to do, and on what you build yourself and what you buy. This guide covers what drives the cost, what to build and what to buy, and what is different in Switzerland.

What drives the cost of a SaaS MVP?

What the first version has to do, and how it is built. Every task a user can carry out needs its screens, its data, its rules and its tests. So the number of tasks, the kinds of users and the connections to other software set the size of the work. How much is designed from scratch, and what you buy instead of building, decide the rest.

• The assumption you test. A first version needs only what it takes to test your riskiest assumption. If your idea is that tradespeople will send their quotes from your tool, the first version needs the quote, the sending and a way to see whether customers accept, not the yearly report. Our guide on what an MVP should include shows how to choose.
• Kinds of users. A product where each customer company sees only its own data, with administrators and ordinary users, takes more work than one with a single kind of user.
• Subscriptions and payments. Monthly plans, invoices, failed card payments and cancellations each need their own screens, rules and tests. If your assumption is not about whether people pay, payments can wait.
• Connections. Each link to other software, such as an accounting tool or a calendar, has to be built and tested, and it has to keep working when the other side changes.
• Design. Screens built from proven components take less work than a design made from scratch.
• Languages. Every extra language adds its texts to every screen and every email. Starting with one, and building so that more can be added, keeps the first version smaller.
• Testing. Tests that use the software from start to finish, the way a person does, are part of the work. A small first version still has to work reliably, so this is not the place to save.

These drivers are the same for any custom software. Our guide on what drives the cost of custom software explains them in more detail, together with how to compare two offers.

With us, a first version gets a fixed price in a written offer, set once what it has to do is written down. Nothing is built until you agree to it, and any change beyond the agreed scope is priced before it is built. MVP development shows how we build a first version.

Which stack: what to build and what to buy?

Build what makes your product different, and buy the rest. Signing in, taking payments, sending email and running a database are problems that proven services already solve. The time you save goes into the part your customers come for.

React, Supabase and Stripe are among the tools we build with, so here they serve as examples:

• The screens: React. Its makers describe it as "the library for web and native user interfaces". It is free to use under the MIT licence.
• The database and the sign-in: Supabase. It provides "a full Postgres database for every project", sign-in with a password, without one or through another account, and storage for files.
• Payments: Stripe. It takes card payments in Swiss francs, among other currencies.
• Email and analytics. Use a service, rather than your own mail server or your own tracking code.

What you build is the rest: the process, the rules and the screens that make your product different. Bought parts still need testing, so test the whole product from start to finish, sign-in and payment included.

What do you pay for once it is live?

Once it is live, a SaaS product pays for the services it is built on, such as a database service billed by plan and by use, and a fee on every card payment. Keeping the software up to date and checked costs extra, and our article on software maintenance after launch explains what drives that cost.

What is different in Switzerland?

Three things belong in the plan from the start: data protection, the languages of your users, and VAT once your turnover grows. For data protection, the law asks for exactly that. For languages and VAT, it means building the product so that they can be added when you need them.

Data protection

The revised Federal Act on Data Protection has applied since 1 September 2023. It asks whoever processes personal data to build data protection in "from the planning stage" (Art. 7). People must be told when their personal data is collected (Art. 19). Personal data may go abroad only to countries the Federal Council has found to protect it adequately, or with other safeguards, such as approved contract clauses (Art. 16). The Federal Data Protection and Information Commissioner counts storage on systems abroad, a cloud included, as such a disclosure. So where your data is stored is a decision for the first version.

Languages

Switzerland has four national languages: German, French, Italian and Romansh (Federal Constitution, Art. 4). Which of them your product needs depends on where your first users are. A first version can start with one, as long as it is built so that more can be added.

VAT

A Swiss business becomes liable for VAT once its turnover from taxable supplies reaches CHF 100,000 a year, counted in Switzerland and abroad (VAT Act, Art. 10). The standard rate is 8.1% (Art. 25). Prices and invoices should be ready to show VAT by the time you reach it.