SaaS application — how to build your own product from MVP to recurring payments

A SaaS application is software you sell as a subscription rather than hand over to a client once the project is done. That one difference changes almost everything: how you count the cost, what has to be in the first version, how you collect money, and which legal documents you need before the first customer clicks "Pay".

This article is for people with an idea for their own product who want to know what building one for the Swiss market in 2026 involves. We rely on Swiss law in its current wording, payment-provider documentation, and our own experience: we run a SaaS product — DVN Links — and this site itself uses its public API. You won't find invented customer stories or revenue promises here.

How a SaaS application differs from custom software

Custom software is built for one client. It has one set of requirements, one budget, and a handover point after which it moves into maintenance. SaaS applications work differently in three respects.

One codebase, many customers. Every company that signs up uses the same application on the same servers. Customer data has to stay separated, and a change made for one customer reaches everyone. How that separation is actually done — one database with a customer identifier on every record, or separate databases per customer — is the subject of our multi-tenant architecture article.

A subscription instead of a one-off payment. The customer pays monthly or yearly and can cancel at any time. That means revenue depends on how many customers stay, not just how many arrive — and that recurring payments, invoicing, and handling failed charges are part of the product, not an add-on.

Development with no end date. SaaS products have no "handover". After the first version come fixes, new features, pricing changes, and security updates. The cost of building it is only the start; you keep paying the cost of running and improving it for as long as the product exists.

If you're still deciding whether your problem needs its own product or a ready-made tool is enough, start with our guide to SaaS and the comparison with custom software.

The five building blocks every SaaS product needs

Whether you're building invoicing, booking, or a link shortener, underneath they share the same five blocks. The customer doesn't buy them — they buy the one feature that solves their problem — but without these, that feature can't be sold.

1. Accounts and organizations

A user signs up, logs in, resets a password. B2B products add a level above that: the organization, which several people belong to and which owns the data and the subscription. Decide early whether an account belongs to a person or to a company — changing your mind later means rebuilding the data model.

2. Billing

Plans, prices, trial periods, mid-cycle plan changes, failed payments and retries, invoices. Most of this isn't built from scratch — you use a payment provider — but integrating it is still real work. Our own web-app cost calculator puts it this way: "Payment integration requires webhook handling, idempotency logic, and compliance testing — not just embedding a checkout widget."

3. Permissions

Who in an organization can invite people, who sees invoices, who can delete data. Two roles — owner and team member — are usually enough to start. A fuller permission system is worth building once customers start asking for it.

4. An admin panel

Your own screen where you see customers, their plans and payments, can extend a trial, suspend an account, or check why a customer is reporting a bug. Without it, every support case ends in a manual database query.

5. Transactional e-mail

Sign-up confirmation, password reset, team invitation, payment confirmation, a failed-charge notice. This isn't marketing — these are messages the customer needs to know what's happening with their account.

What can wait

Three things that often land in the first-version plan and are rarely needed on day one:

• a mobile app — a well-built web app works fine in a phone browser; a dedicated app is worth building once you know customers actually need it in the field;
• a public API — it makes sense once customers want to connect your product to their own systems; before that it's extra surface to build and secure;
• a second language — translating the interface, e-mails, terms, and support is several separate tasks; if your first customers share one language, ship one.

SaaS MVP — what belongs in the first version

An MVP, a minimum viable product, has to answer one question: will anyone pay to have this problem solved. We cover how to plan one more broadly in our MVP article. For SaaS the rule is simple: the five blocks above, plus the one feature the customer actually comes for. Everything else waits until paying customers say what's missing.

The most common MVP mistake is building every feature from the idea before anyone has used any of them. The second is skipping billing "because we'll give it away free for now." If the product is meant to earn on a subscription, payment is the most important MVP test there is.

A free plan and limits as a sales mechanism

In many SaaS products, pricing isn't a list of features — it's a list of limits. Our own product, DVN Links, a European link management platform with analytics and QR codes, shows this well. Its plan ladder (read 2026-10-02) runs Free → Starter → Pro → Business → Enterprise, with 50 / 500 / 2,000 / 10,000 links a month, 1,000 / 10,000 / 50,000 / 250,000 clicks a month, stats history of 7 / 30 / 90 / 365 days, API access from the Starter plan up, rate limits of 10,000 and 50,000 requests an hour on the higher tiers, a 7-day trial on the Pro plan, a 20% discount on annual billing, and a contractual SLA on Enterprise. The interface itself is available only in English and Polish.

Every plan is the same application — only the numbers differ. The free plan lets someone try the product with no card, and the limits (link count, how long stats are kept, API access) mark the point where upgrading starts to pay off. For an MVP that means one thing: design the limit mechanism from day one, even if you launch with only one paid plan. We cover when a free plan helps and when it just costs money in our article on the freemium model.

Recurring payments in Switzerland: Stripe, TWINT and PostFinance

Recurring payments are automatic charges taken from a customer every month or year, once they've consented. On the Swiss market you have several providers to choose from, and they differ not just on price but on which payment methods actually support recurring charges.

Stripe and TWINT

Stripe's Swiss pricing page lists 2.9% + CHF 0.30 for cards issued in Switzerland and 3.25% + CHF 0.30 for international cards. TWINT, the Swiss payment app, runs on Stripe at 1.9% + CHF 0.30, and Stripe's TWINT documentation lists its "Recurring payments" property as "Yes," with CHF as the presentment currency and Switzerland as the customer location. Stripe's Billing module adds its usual 0.7% pay-as-you-go fee on top, per the Swiss Billing pricing page.

PostFinance Checkout

PostFinance Checkout is a Swiss acquirer alternative. Its All-in-One plan runs CHF 199 one-off set-up plus CHF 14.90 a month, with a 2.5% fee (minimum CHF 0.20) for turnover up to CHF 200,000; the E-Com Bundle is CHF 19.90 a month with TWINT/PostFinance Pay at 1.3%, cards at 1.55%, plus a CHF 0.18 PSP fee per transaction. We could not confirm whether PostFinance Checkout supports recurring subscription billing the same way Stripe does — check this directly with PostFinance before relying on it for a subscription product.

Invoices and VAT for a subscription business

A payment provider collects the money, but you still need a Swiss-compliant invoice for a business customer. Under the VAT Act (LTVA) Art. 26, a VAT-registered supplier must issue an invoice on request, with the elements that article lists (including your VAT number); receipts of up to CHF 400 need not name the recipient (OTVA Art. 57). The payment part of a Swiss invoice is the QR-bill: in circulation since June 2020, it definitively replaced the old payment slips on 1 October 2022, new QR-bill requirements apply since 22 November 2025, and from November 2026 only structured addresses (type S) are accepted. Whether Switzerland has a mandatory B2B e-invoicing scheme is not something we can confirm — if your billing tool makes that claim, verify it directly before relying on it.

If you sell your SaaS application to Swiss consumers from abroad, you are no longer exempt from Swiss VAT once your worldwide turnover reaches CHF 100,000 (LTVA Art. 10(2)(a) and (b)(2)); the standard rate is 8.1%. Don't assume an EU-style one-stop-shop exists for this — register and declare under the Swiss rules.

Legal minimum: terms, data protection, and consumer rules

What follows is a map of obligations, not legal advice. Have a lawyer check your terms of service and data-protection documents before you take a first payment.

Terms of service for an online service

Switzerland has no statutory e-commerce terms act equivalent to the EU's E-Commerce Directive. Instead, the Unfair Competition Act (UWG) sets the baseline: Art. 3(1)(s) requires an online seller to give clear information on its identity (including an e-mail address), the technical steps to conclude the contract, how to correct input errors, and an immediate electronic order confirmation; Art. 8 bars terms and conditions that create a significant and unjustified imbalance to the consumer's detriment. There's no Swiss counterpart to the EU rule that terms must be made available in a form the customer can store and reproduce — but offering a downloadable copy costs nothing and avoids disputes later.

Data protection in both directions: controller and processor

In a B2B SaaS application you hold two roles at once.

Towards your own users, Switzerland's revised Federal Act on Data Protection (nFADP) Art. 19 imposes a duty to inform at the point of collection, covering at minimum your identity and contact details and the purpose of processing, plus — where applicable — the recipients or categories of recipients of the data.

Towards the data your customers upload, you're normally the processor. nFADP Art. 9 covers this relationship but — unlike GDPR Art. 28(3) — sets no mandatory list of clauses a data-processing agreement must contain. In practice you still prepare one standard agreement that the customer accepts alongside your terms, covering the same ground GDPR would require even though Swiss law doesn't mandate the specific clauses. If your product itself offers its service to people in the EU, GDPR can apply to that part of the business as well (Art. 3(2)), even though your company is Swiss.

Consumer customers: no statutory right of withdrawal

If you also sell to individuals, the Swiss position differs sharply from the EU's. Switzerland's Code of Obligations Art. 40b covers a right of withdrawal only for doorstep and telephone-sales situations — and the Swiss government's SECO business portal states it plainly: "In e-commerce, Swiss law does not provide for any withdrawal period or other right of return once the order has been placed." There is no Swiss equivalent to the EU's rule letting a consumer walk away free of charge within 30 days of an unfavourable product change.

In practice this means your cancellation and refund terms are a contractual choice, not a statutory entitlement you're implementing. State them clearly, as UWG Art. 3(1)(s) requires, and keep them fair under UWG Art. 8 — a generous cancellation policy is a competitive choice here, not a legal obligation. If the application also serves consumers in the EU, the EU's withdrawal and digital-content rules (and GDPR, per Art. 3(2)) apply to that part of your business even while none of this applies to the Swiss side.

What it costs to build a SaaS application

Pricing an application like this depends heavily on scope, and we found no Swiss benchmark with a published sample for SaaS or web-app builds. What drives the cost is the mechanism, not a single number: the five building blocks above, how deep the permission model needs to be, how many payment methods and currencies you support, and how much of the billing edge cases (failed charges, proration, Swiss VAT handling) you handle yourself versus hand to the provider. Every project we quote is priced individually for exactly that reason — a "simple SaaS" and "the same SaaS with recurring payments, roles, and Swiss invoicing" are very different projects.

You can get a rough estimate for your own scope with our web-app cost calculator. For general background on what drives the price of an application, see how much does it cost to build an app; we've also published a report on web-application costs, though that study covers the Polish market specifically and its figures don't carry over to Switzerland.

Running costs after launch

A SaaS product pays bills every month: hosting and the database, an e-mail delivery service, payment-provider fees (with Stripe, a per-transaction fee plus 0.7% for Billing), monitoring, and backups. On top of that comes developer time for fixes, dependency updates, and new features. We cover how to organize this after launch in our articles on technical maintenance and self-hosting on Coolify — the latter can cut your infrastructure bill while the product is still small.

Example: DVN Links and its public API

DVN Links is our own SaaS product — on its own site it's described as "a European link management platform with analytics and QR codes." We described its pricing above: a product where the free plan and its limits are the main sales mechanism.

A public API in practice

DVN Links exposes a REST API to customers, documented to the OpenAPI 3.1 standard. Every request needs an API key sent as a Bearer token in the Authorization header. Rate limits depend on the plan, and the API reports them in the X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset response headers, so a client program always knows how many requests it has left and when the counter resets. API access is included from the Starter plan up.

It's a good example of something that can wait: the API wasn't needed to find out whether anyone would pay for short links. It became necessary once the product had customers who wanted to create links automatically from their own systems — and at that point it also became another limit distinguishing the plans.

What our own site does with that API

The best test of an API is using it yourself. This site — the one you're reading — talks to DVN Links through the same public REST API that paying customers get:

• creates a short link when an article or page is published, and stores it on the document;
• checks on every later publish that the link still exists;
• recreates the link if someone deleted it in the DVN Links panel;
• updates the destination URL when a page's address changes — the old short link keeps working and now points at the new address;
• adopts links created before the site started saving their IDs: it looks up a link by its destination URL and attaches it to the document instead of creating a duplicate.

A failed call to the API never blocks saving the article — it's only logged. That's a rule worth adopting for any integration with a third-party service: your application should keep working even when the other side is briefly unavailable. We explain what an API is, how a webhook works, and how to secure an integration in our article on APIs.

Build it yourself, with a software house, or with us

There's no single right answer — just a few criteria worth going through honestly.

Build it yourself if you're a developer, or have one on the founding team, and time is cheaper than cash. The risk: the five building blocks take longer than the core feature, and payments and legal documents get pushed to "later."

Start with no-code or low-code tools if you want to test demand in a few weeks and accept that you'll probably rebuild the first version. We cover when that makes sense, and when it blocks growth, in our article on low-code.

Choose a software house if you have a well-defined scope, a budget for a full build, and someone on the business side to own the product afterwards.

Talk to us if you want to start from the smallest version that can take payments and grow it in stages. We run our own SaaS product, so recurring payments, plan limits, the API, and the legal obligations are things we know as an owner, not only as a contractor. See our MVP for startups and web-app development pages for how we work, or take our SaaS-vs-custom quiz if you're still deciding whether you need your own product at all.