Is your SaaS ready? The demo runs, the team wants to press the button. Before you do, take an hour to read through this list.
At KERN-IT, SaaS development has taken a growing share of our work these past months: we have put several SaaS products online, our own and our clients'. Every time, the same lesson: when launching a SaaS, the product is only half the job. The other half is everything around the code: hosting, backups, the till, the invoices, the contract, and the way clients will find you.
Launching a SaaS means opening a shop that never closes. The shop window matters. So do the till, the insurance and the emergency exit.
What follows is the checklist we go through before every launch, and what we learned by going through it.
What SaaS development changes compared with classic software
Custom software gets delivered. A SaaS gets run, every single day.
That difference explains most of the lines in this checklist. Software installed at a client's premises lives in their infrastructure, with their backups, their IT person, their pace. A SaaS lives with you. You host the data of dozens or hundreds of companies on the same platform, you update them all at once, you charge every month, and you answer when it goes down.
- SaaS development therefore adds three layers that classic development ignores. Multi-tenancy: one codebase, one infrastructure, and a watertight wall between each client.
- The account lifecycle: sign-up, trial, subscription, upgrade, cancellation, export, each with its own rules and its own emails.
- Operations: monitoring, backups, updates without downtime, support. None of these three layers shows in a demo. Yet they are what separates a product you can sell from a prototype you can show.
At KERN-IT, we lay down these three layers in the first week of a SaaS development project. Adding multi-tenancy to an application that was not designed for it means rewriting half the code. Adding invoicing after launch means invoicing by hand for six months.
One last distinction before the list. The SaaS you launch may be your product, sold to other companies, or your own business platform, reserved for your own use. We have explained why the second option deserves to be considered before the first. In both cases, the checklist is the same: an online service that carries third-party data launches with the same precautions.
1. Where to host your SaaS: a choice that commits you
Before comparing prices, a legal question: a SaaS that processes data of European clients must know where its servers are and under which law its host lives. A data centre in Frankfurt operated by an American player remains subject to the CLOUD Act. A European host (Scaleway, OVHcloud, Hetzner, Exoscale) is not exposed to it. For most Belgian B2B SaaS, that is a sales argument as much as a protection.
The second reflex is to start small. A well-sized virtual server, a managed PostgreSQL database, object storage for files: that is enough for the first thousand clients. Kubernetes will come if success demands it. We have seen too many projects burn their first six months building an infrastructure designed for traffic that never came. Scalability is prepared in the architecture. The first day's cloud bill can stay small.
Finally, everything about hosting must be written down somewhere: the account, the credentials, the domain name, the DNS, the certificate renewal. The day the person who set it all up is no longer there, that document is the first thing anyone will look for.
2. The minimum infrastructure of a serious SaaS
There is a floor below which you do not go live. The first incident usually arrives in launch week, so you might as well have planned for it. This floor is part of SaaS development itself: it gets built at the same time as the screens.
- HTTPS everywhere, including on the API and the subdomains
- No secrets in the code: keys and passwords live in a secrets manager or in environment variables
- Two environments at minimum, one for testing and one for production, with automated deployment between them
- Monitoring that alerts a human: application errors, availability, disk space
- Rate limiting on sensitive endpoints, login first
- Solid authentication, with two-factor offered from day one
- Strict isolation between clients if your SaaS is multi-tenant: one client must never be able to see a single row of another
That last point is the one we check the longest. In a SaaS, an isolation error between clients is hard to forgive: it is one client's data showing up in another's account. It gets tested before launch, with two accounts, by trying to see what you should not be able to see.
3. Backups: the box everyone ticks without testing it
Everyone has backups. Far fewer people have ever restored a production database from one of them.
The rule is still 3-2-1: three copies, on two media, one of them off-site. And in 2026, a fourth precaution: an immutable copy that no one can erase, not even an administrator with a stolen password. Recent ransomware also encrypts the backups reachable from the server, and we see it regularly.
Two numbers to write down before choosing a schedule. How much data can you afford to lose: an hour, a day? How fast do you need to be back online? These two answers dictate everything else: backup frequency, retention, procedure.
Then, the step almost nobody takes: restore a backup on a blank server, once a month, and time it. At KERN-IT, the restore test is part of the go-live checklist, before the first client. Until a backup has been restored at least once, you do not know whether it works.
One last point, often forgotten: the backup must not sleep at the same provider as production. If the account is suspended, if the data centre burns, both disappear together.
4. Payments: collecting money without becoming an accounting department
On paper, collecting a subscription is simple. In practice, it is the area that generates the most support tickets in the first year.
The first decision is who sells. With a classic payment provider (Stripe, Mollie), you remain the seller: you collect, you invoice, you declare the VAT. With a merchant of record (Paddle, Lemon Squeezy), they sell on your behalf: they collect the VAT of each country, remit it, handle disputes, and pay you the balance. You pay for that, with a noticeably higher commission. For a Belgian SaaS selling mostly in Belgium and B2B, the classic provider is enough: the reverse charge settles most intra-European VAT. For a SaaS selling to consumers in twenty countries, the merchant of record is worth its price.
In Belgium, do not forget Bancontact. A good share of clients will not pay by credit card, and both Mollie and Stripe offer it.
Then come the cases that only happen in production: the card that expires, the declined payment, the free trial that ends, the client who switches plans mid-month. Each case must have a written answer before launch, and an email ready. Automatic retry of failed payments alone recovers a significant share of the revenue you thought was lost.
Two model choices are also made before launch. Free trial rather than freemium for a B2B SaaS. A time-limited trial converts between 18 and 25% of sign-ups. A permanent free tier converts between 3 and 5%, and you have to support it indefinitely. And an annual plan from day one, with two months free: clients who take it leave far less often, and the cash collected up front funds the first months.
A principle we apply: your database is what knows who is entitled to what; the payment provider merely collects. The day you change provider, you do not start from scratch.
5. Invoicing: Peppol since 1 January 2026
A SaaS issues invoices in series, often hundreds a month. In Belgium, since 1 January 2026, every invoice between two VAT-registered businesses established in Belgium must be electronic and structured, in the Peppol BIS format, transmitted over the Peppol network. The PDF sent by email no longer counts. Outside the issuing obligation: invoices to consumers, invoices to clients established abroad, and a few special regimes (exempt transactions, the flat-rate scheme until 2028). Small businesses under the VAT exemption scheme are covered like everyone else. We have detailed the consequences for Belgian companies.
For a SaaS, this means the invoice generated at each charge must go out over Peppol to every Belgian business client. So you need a Peppol access point, and a clean mapping between your subscription data and the expected format. We had to solve this step for our own subscriptions. You need an outbox that takes each generated invoice, converts it to the structured format and delivers it to the network. The mapping rules depend on your data model. Plan it in the development: it does not get fixed in an afternoon after launch.
Beyond Peppol, the fundamentals remain: continuous numbering without gaps, mandatory mentions, correct VAT according to the client's country and status, retention for ten years from the 1st of January that follows, and a clean export for your accountant. All of this can be automated. One manual invoice per subscription does not hold beyond the tenth client.
6. The legal obligations of a SaaS in Belgium and in Europe
This is the part founders postpone. It takes a few days when handled before launch, a few months when handled after.
GDPR, first. A SaaS is almost always a processor for its clients: it processes their users' data on their behalf. That requires a data processing agreement (the DPA), a record of processing activities, a readable privacy policy, and concrete mechanisms to answer an access or erasure request. Hosting in Europe, covered above, simplifies everything else.
The terms and conditions, next. A SaaS sells a service over time. The terms must state what is included, what is not, the promised service level, what happens in case of outage, and how one terminates.
The Data Act, in force since 12 September 2025, changes that last point. A client must be able to leave your SaaS with a notice period of two months at most, retrieve their data in a usable format, and from January 2027 exit fees disappear. You must also publish the exit procedure and the export formats. This rule applies to all contracts, including those signed before.
Accessibility, if your SaaS serves consumers: since 28 June 2025, the European Accessibility Act imposes WCAG 2.1 AA on consumer-facing digital services. Microenterprises (fewer than ten people) are exempt for their services. A purely B2B SaaS is not directly targeted, but its clients sometimes are, and they will ask.
The AI Act, if your product embeds AI. The transparency obligations apply since 2 August 2026: telling users they are talking to an AI, marking generated content. High-risk uses (recruitment, credit, health) were postponed to December 2027 by the digital omnibus, and they require far more than a line in the terms.
And for the sectors concerned (health, energy, finance, certain digital providers), NIS2 has been transposed in Belgium since October 2024, with security and incident notification requirements.
One last document, which is not a law but arrives just as surely: the security questionnaire from your first client of a certain size. It will ask who has access to what, how data is encrypted, where the logs are, how you respond to an incident, and sometimes for a certification. In Europe, ISO 27001 is what you will be asked about, more than SOC 2. You do not need the certificate at launch. You need written answers, and points 2 and 3 of this list already cover most of them.
We are not lawyers, and this paragraph does not replace legal advice. It is there so you know what to ask, and ask it before the first paying client.
7. Distribution in the AI era: getting onto the shortlist
Most launch checklists stop before this point. It is the one that decides whether the product finds clients.
Three years ago, a B2B buyer typed "management software for" followed by their trade into Google, opened ten tabs, and compared. In 2026, they ask ChatGPT, Perplexity or Claude, describe their case, and receive a shortlist of three to five tools with a justification. They request a demo from those three. If you are not on that list, you are not consulted.
You do not get onto that list by deciding to. You have to give the models something to cite, and that is what is called GEO, generative engine optimisation. Models cite what they can read and understand: clear public documentation, pages that answer a precise question, honest comparisons, visible FAQs, structured data. A five-page brochure site full of promises gives them nothing to cite.
This material goes on the checklist alongside the server and the backup. It gets written before launch, not after.
8. Marketing: one or two channels, measured before launch day
The launch is not decided in a day. What counts is what you repeat every week afterwards.
Before the channels, the target. A SaaS "for every team" speaks to no one. A SaaS for engineering firms with fewer than twenty people in Belgium knows whom to write to, where to find them and what to say. Post-mortems of abandoned SaaS products cite an overly broad target ahead of every other cause.
Next, do not wait for launch to have clients. A waiting list open during development, with one qualifying question at sign-up, provides the first testers and the first payers. A beta in small batches, and the first accounts opened by hand by the founder, with a twenty-minute welcome call. And the first clients pay, from day one, even at a founding-customer rate: a free "yes" proves nothing, a bank transfer proves everything.
For the channels, the first piece of advice is do not do everything. One or two, chosen for the target, and held over time. For a Belgian B2B SaaS, two channels come up again and again. Content that answers the trade's real questions: it costs little and it compounds. And the founder speaking up on LinkedIn: a personal profile reaches far more people than a company page. Direct outreach fills in the gaps, as long as the product has not found its product-market fit.
The second piece of advice is measure before you launch. Where the visitor came from, whether they signed up, whether they performed the action that proves they understood the product, whether they paid. Four numbers, wired up before launch day. Without them, launch week teaches you nothing.
The third is onboarding. A new sign-up must get something useful within the first five minutes, a real result rather than a guided tour. Everything that delays that moment loses sign-ups.
Pricing also gets tested before launch. Ten people who answer "yes, I would pay that" teach you more than a market study, and ten who actually pay teach you even more.
9. Life after launch
Once launch day is over, the SaaS goes on. A clear support channel: an email is enough at the start, provided you answer, and the response times are written down somewhere (a few hours for a blocker, one business day for the rest). A status page for outages. A changelog that shows the product is alive. Security monitoring of dependencies. And a monthly appointment with the churn numbers.
Two things founders discover on the first night. Who gets woken up when it goes down: an alert that rings on a phone, a named person, a relief after a few weeks, otherwise the first outage lands on a Sunday evening and the second one burns out the team. And the known failures, written down: saturated database, expired certificate, stuck email queue, each with the procedure to get out of it. You write the procedure after the first incident, never during.
One number to size the effort: 60 to 70% of a SaaS's churn happens in the client's first 90 days. A sign-up who has done nothing after three days is almost always lost. Following up on new accounts in their first week is worth more than any campaign.
All of this has a monthly cost, to be budgeted from day one.
Having your SaaS built: what this list changes in the brief
If you entrust SaaS development to a partner, this checklist becomes the part of the specification nobody writes. The usual brief describes screens and features. It almost always forgets what surrounds them.
Six points to have written into the proposal:
- Multi-tenancy from the design stage, with the isolation test included in acceptance
- Payments and invoicing within scope, Peppol included for Belgian clients
- Backup and tested restore as a deliverable, not as a hosting option
- The hosting choice in writing, with its country, its law and its monthly cost
- The handover: the code, the credentials, the operations documentation, the domain name in your name
- A recurring budget after go-live, because a SaaS does not stop existing on delivery day
The sixth point is the one that surprises people most. A web application or SaaS development does not end at go-live. You have to count hosting, monitoring, security updates, product evolution. A partner who prices a SaaS like a brochure site, delivered then forgotten, has not understood what they are selling.
What we tell our own clients: the launch costs less than the first year. If the proposal only shows the first number, ask for the second.
Launching a SaaS: the checklist on one page
- European host, out of reach of extraterritorial laws
- Simple infrastructure at the start, architecture ready to grow
- Credentials, domains, DNS and certificates documented
- HTTPS everywhere, secrets out of the code, two environments, automated deployment
- Monitoring that alerts a human
- Strong authentication and tested isolation between clients
- 3-2-1 backups, one immutable copy, one copy outside the provider
- Recovery objectives written down, restore tested and timed
- Direct seller or merchant of record decided, Bancontact included
- Time-limited free trial and annual plan available from launch
- Payment cases (failure, expiry, plan change) scripted
- Subscription logic in your database, not at the provider
- Structured invoices and Peppol delivery for Belgian B2B clients
- Numbering, mandatory mentions, VAT, retention, accounting export
- DPA, record of processing activities, privacy policy
- Terms for an ongoing service, with service level and termination
- Data Act exit: two-month notice, data export, published procedure
- Accessibility if consumer audience, AI Act if AI features
- Written answers to the security questionnaire (access, encryption, logs, incidents)
- Public documentation, FAQ, comparisons: something for AI engines to cite
- Precise target, waiting list open during development, first paying clients before launch day
- One or two marketing channels, measurement wired before launch
- Onboarding that delivers a result in five minutes
- Pricing validated by real commitments
- Support with written response times, status page, changelog, churn tracking
- One person on call, an alert that rings, known failures documented
- Close follow-up of every new account during its first 90 days
- If development is entrusted to a partner: the six points of the brief written into the proposal
The questions that keep coming up
Do you have to tick everything before launching a SaaS? No. You have to have read everything, and know what you are leaving open knowingly. The tested backup, isolation between clients, the contract and GDPR are not negotiable. The rest can be picked up in the weeks that follow.
Can a vibe-coded prototype serve as the basis for launching a SaaS? It can serve as the basis for the product. As it stands, it is rarely ready for a launch. Most of the points on this list (secrets, isolation, backups, invoicing) are exactly the ones a prototype ignores.
Does Peppol apply to SaaS subscriptions? Yes, as soon as the client is a VAT-registered Belgian business. Every subscription invoice must be structured and transmitted via Peppol since 1 January 2026.
Is Stripe enough to sell a SaaS across Europe? Technically, yes. Fiscally, you remain responsible for the VAT of every country where you sell to consumers, through the OSS one-stop shop. In B2B, the reverse charge simplifies things. If that burden worries you, a merchant of record takes it on, for a higher commission.
Is an American host with a data centre in Europe enough for GDPR? For data location, yes. For exposure to the CLOUD Act, no: the operator remains American. Many B2B clients, especially public and regulated ones, now make the distinction.
Do you need a SaaS development agency to go through this checklist? Not necessarily, if your team has already run a service in production. Often, yes, for the points that do not show in the demo: multi-tenant isolation, payments, Peppol invoicing, tested backups. Taken into account from the design stage, the list fits in two to four weeks, alongside the SaaS development itself. Discovered after launch, it takes months.
The launch is a beginning
Launching a SaaS means opening a service you run every day, for clients who have put their data with you. This checklist is not there to delay going live. It is there so the first week goes without nasty surprises, and the following ones too.
If you are preparing yours, our SaaS development team has been through this list several times, for our products and for our clients. You know where to find us.
