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 in the EU in 2026 involves. We rely on current EU directives and regulations, 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.

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 the EU: Stripe and Mollie

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

Stripe Billing

Stripe lets companies across the EU open an account. Subscriptions are handled by its Billing module, which its documentation describes this way: "Subscriptions let customers make recurring payments to access a product or service. When you create a subscription, Stripe automatically generates invoices, attempts payment collection, and manages the subscription status throughout its lifecycle." Stripe also takes over retrying failed payments (Stripe, Billing overview).

Fees on the Ireland pricing page (read 2026-10-02):

• standard EEA cards: 1.5% + €0.25;
• UK cards: 2.5% + €0.25; international cards: 3.15% + €0.25 (plus 2% for currency conversion); Bancontact: 1.4% + €0.25;
• SEPA Direct Debit: €0.35;
• Billing (pay as you go): 0.7% of Billing volume — on top of the fee for the payment itself (Stripe Billing pricing, Ireland).

For subscriptions paid without a card, Stripe's SEPA Direct Debit docs list the method's "Recurring Payments" property as "Yes".

Mollie

Mollie documents recurring payments as a two-step mechanism: "In order to get started with recurring payments you need to require the customer's consent through a first payment" (Mollie, Recurring payments). Cards (including Apple Pay and Google Pay) and PayPal stay recurring on their own method; iDEAL, Bancontact, EPS, Belfius, and KBC convert the first payment into a SEPA Direct Debit mandate for every charge after that — so the method the customer sees on their first payment isn't necessarily the one charged later. Mollie's EEA pricing: consumer cards 1.80% + €0.25, SEPA Direct Debit €0.35. One technical limit worth knowing: "you can not use recurring payments in our Web app. It's only possible to use our API."

Invoices and e-invoicing for a subscription business

A payment provider collects the money, but you still need to raise a VAT invoice for a business customer that meets EU rules. The content of a VAT invoice is set at EU level by the VAT Directive's Art. 226 — but electronic invoicing is not harmonised on one date: ViDA (Directive (EU) 2025/516) entered into force on 14 April 2025 and sets EN 16931 as the common e-invoice standard, with cross-border digital reporting from 1 July 2030 and domestic systems expected to align by 1 January 2035. In between, individual member states run their own mandates on their own schedules. Before choosing a billing tool, check that it can produce the invoice format your customers' member states actually require.

One line on VAT for consumer digital services: a seller established in a single member state may charge its home-country VAT on cross-border sales to EU consumers only while those sales stay under €10,000 a year, counted over the current and the preceding year (VAT Directive Art. 59c). Above that, VAT is due in each customer's member state, and the One Stop Shop (OSS) lets you declare it through one return instead of registering in each.

Legal minimum: terms, GDPR, and the digital-service rules for consumers

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

A SaaS application is an information-society service, and the E-Commerce Directive sets minimum disclosure rules for it. Art. 5(1) requires the provider to make certain information "easily, directly and permanently accessible" — its name, geographic address, e-mail address, and trade-register number. Art. 10(3) adds a rule that applies to business customers too, with no waiver: "Contract terms and general conditions provided to the recipient must be made available in a way that allows him to store and reproduce them." What happens if you don't — for example, whether the customer is bound by terms never made available — depends on the member state; the directive itself sets no single EU-wide sanction.

GDPR in both directions: controller and processor

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

Towards your own users — the people who create an account — you're the controller, and under Art. 13 you must give them, at the point of collection, your identity and contact details, the purposes and legal basis for processing, the recipients of the data, and (among other things) how long you keep it and what rights they have.

Towards the data your customers upload — their own customers, employees, or contacts — you're normally the processor. Art. 28(3) then requires a data-processing agreement setting out the subject matter and duration of processing, its nature and purpose, and the type of data involved. In practice you prepare one standard DPA that the customer accepts alongside your terms. Your own suppliers — hosting, e-mail delivery, the payment provider — are then your own sub-processors, who the customer also has to accept. We cover what this chain looks like from the customer's side in our article on cloud data security.

Consumer customers: digital service and the right of withdrawal

If you also sell to individuals, two consumer directives apply. A SaaS application fits the definition of a digital service under Directive (EU) 2019/770, Art. 2(2): a service that lets the consumer "create, process, store or access data in digital form," or share or interact with data uploaded by users of that service. Three provisions matter most for the product itself:

• you supply the service "without undue delay after the conclusion of the contract" unless agreed otherwise (Art. 5(1));
• a change to the product that isn't needed to keep it conforming to the contract is allowed only "if the contract allows, and provides a valid reason for, such a modification," and must come at no additional cost to the consumer (Art. 19(1));
• if a change "negatively impacts the consumer's access to or use of" the service beyond a minor degree, the consumer can terminate the contract free of charge within 30 days (Art. 19(2)).

Before an indefinite or auto-renewing contract, the Consumer Rights Directive (Art. 6(1)(o)) also requires you to disclose the conditions for terminating it.

The question that comes up most is the right of withdrawal. A consumer who concludes a distance contract can withdraw within 14 days without giving a reason (Art. 9). The exception in Art. 16(a) covers service contracts "after the service has been fully performed... with the consumer's prior express consent." A monthly or annual subscription isn't fully performed within the first 14 days. In our reading, a consumer who starts using the application right away most often keeps the right of withdrawal — but if they explicitly asked for the service to start before the withdrawal period ended (Art. 8(8)), they pay a proportionate amount for what they used up to that point (Art. 14(3)). This is our interpretation, not legal advice, and EU member states don't all transpose it the same way: have a lawyer check the withdrawal clauses in your terms. Separately, a "withdrawal button" requirement (Directive (EU) 2023/2673, new Art. 11a) has applied from 19 June 2026 — national transposition of the exact mechanics may still differ.

What it costs to build a SaaS application

Pricing an application like this depends heavily on scope, and we found no EU-wide 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, tax rules per customer country) 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 an EU invoicing integration" 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 other countries.

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.