An idea for software other people want to use? That can be built.

SaaS stands for software as a service: software delivered as a service instead of a product someone buys and installs. The customer creates an account, signs in through the browser or an app, and pays for as long as they use it. There is no disc, no installation at the office, no version 3.2 that has to be updated on every computer. There is one place where the software runs and everybody goes there.

The difference from a website is bigger than it looks. A website tells a visitor something; a SaaS lets someone work. It holds data that belongs to the customer, it has people in it with different permissions, something happens in it that still has to be correct tomorrow. From the moment a user can save something they expect back next week, different rules apply than for a site that only reads.

The difference from bespoke software for a single client is just as big. Bespoke work only has to support one way of working: the client’s. A SaaS has to work for the tenth customer who does it slightly differently, and for the hundredth who wants something the first ninety-nine never asked for. That is exactly what makes the setup heavier and the odds of a good product better: every customer who joins pays into the same whole.

It does not have to become a global platform. Many of the healthiest products serve a few hundred companies in one field, do exactly one thing well and have never been in the news. SaaS is not a level of ambition but a form of delivery: software people work in on a subscription.

The strongest ideas rarely come out of a brainstorm. They come out of irritation: someone has spent years doing work where part of it is the same every week, tracks it in a spreadsheet nobody else understands, and notices that peers in the same trade do exactly the same thing. That is the pattern a product lives in — a problem that recurs, at several companies, in roughly the same way.

Three conditions together say almost everything. The problem has to occur often enough that people want to pay for a fix. There have to be enough parties who recognise it, because one enthusiastic customer is bespoke work, not a product. And the solution has to be roughly the same for all of them: if every customer has a fundamentally different way of working, you are building ten products under one name.

An idea that leans mainly on “there is nothing like this yet” deserves a second look. Sometimes that is true and the market has only just grown large enough. More often something does exist, just not visible from where you stand: an old package that circulates inside the trade, a module in software customers already own, or a service provider doing it by hand and making a good living. Knowing where it is solved today is worth more than hoping it is solved nowhere.

Conversely, competition is no reason to stop. Existing products prove people pay for the solution. The question is then not whether there is room, but where the existing products disappoint their users: too broad, too costly in daily use, too slow, not built for the way your trade works. A sharp answer to that is a better foundation than an empty field.

Four very different products hide under the SaaS label, with very different consequences. Knowing in advance which shape your idea falls into means recognising its problems before they show up.

The internal tool is the calmest shape. One organisation uses it, the users are known and may well sit down the corridor. Nothing has to be sold, no sign-up screen is needed and mistakes are reported within a day by someone you know. Many products start here and only later grow outward, when it turns out other companies are asking for the same thing.

Vertical SaaS serves one profession: dental technicians, landscapers, driving schools, care brokers. The audience is small but sharp, the jargon is known and one happy customer talks to ten others at the same trade fair. For a first product this is often the kindest shape, precisely because so little has to be explained.

The broad platform wants to be many things to many kinds of customer. That sounds bigger, but it means more edge cases, more explaining and more parties already doing the same. The marketplace is the heaviest shape: it has to attract two sides at once, and without supply there is no demand and without demand no supply. Both can be built, but it is wise to know what you are starting.

Most of what makes or breaks a SaaS idea can be found out without a single line of software. It costs no budget, only conversations and notes — and it saves building features nobody misses.

Talking to people who have the problem is worth more than talking to people who like your idea. Do not ask whether they would use it, ask what they do now: which step, how often, how long, with what tool, and where it goes wrong. Someone who says they spend an hour every Monday on something they hate gives better information than someone who says it sounds “definitely interesting”.

Just as valuable is finding out how it is solved today. There is almost always an existing way: a spreadsheet, a folder of forms, an employee tracking it by hand, a package that half fits. That is the real competitor, and it is immediately the yardstick your product will be measured against.

Finally: write down what the product will not do. At the start that list is the most valuable document there is. Every idea grows during conversations, and without a boundary the first version grows into something that never finishes. A short, sharp description of what is in it makes every later conversation easier — including the conversation with Plaincodelab.

On a website a visitor is a visitor. In a SaaS almost nobody is alone: a user belongs to a company, that company has several employees, and those employees may not all do the same things. That layer — who belongs to whom and who may do what — shapes more of the setup than any single feature, and is the most expensive thing to change afterwards.

The first question is whether the product works per person or per organisation. A journal app is personal; a scheduling system for an installation company belongs to the company, where the owner sees everything, a planner manages the calendar and an engineer only fills in their own work orders. As soon as several people from the same customer are in the product, a level above the user needs to exist.

Roles are best kept few at the start. Three roles everybody understands work better than twelve nobody can explain. What does need to be there early is the idea that permissions are checked where the data is fetched, not merely by hiding a button. A hidden button is not security; it is a curtain.

Think about the edges too: someone leaving the company, a customer inviting an employee who has no account yet, an owner handing the business over, a trial account that later becomes a real customer. These are not exotic cases but daily practice, and they decide how calm the administration will be later.

A subscription is not a button but a state. An account is in trial, active, overdue, cancelled or expired, and the product should behave predictably in each of those states. That sounds simple until the first payment fails on a Saturday morning and nobody knows whether the customer may still get in.

Most products use a payment provider that handles collection, cards and recurrence; the product itself only remembers which state belongs to which account. That saves an enormous amount of work and risk, because payment details then never have to live in your own system. What does belong in your product is the translation of that state into what a user can do: access, limits, warnings.

Decide early what the price hangs on, even while the amount is still open. Per user, per organisation, per processed document, per volume used or flat access: that choice determines what the product has to count. Something that is not counted cannot be invoiced later, and adding counters afterwards almost always means the first months stay unmeasurable.

Beyond that, the dull cases deserve attention, because they occur more often than the pretty ones. A customer switching plans mid-period, an invoice that has to go to a different address than the account, an accountant asking for an overview, a cancellation halfway through a period, VAT for business customers in other countries. Having those written down before building keeps things calm later.

In a SaaS the data of several customers lives in the same system. That is the core of the model and at the same time the place where the biggest mistake can be made: one customer accidentally seeing another customer’s data. That separation is not a feature added later but a starting point that runs through the whole product — every query knows which organisation the asker belongs to.

Just as important is whose data it actually is. The answer is almost always: the customer’s, not the product’s. That has practical consequences. A customer should be able to export their own data in a usable file without having to ask. A customer who cancels should know how long their data is kept and when it disappears. That trust wins customers who have been locked in somewhere before.

Backups are not a luxury but a condition. A product customers do their work in has to be able to go back to yesterday when something goes wrong — through an outage, through a fault in a new version, or because someone deleted something by accident. Keeping a copy in the same place as the original does not count as a backup. This is needed for any product in serious use; who manages it is a separate choice that works out differently per situation.

Finally: decide in advance what does not need to be in the product at all. Every piece of data you do not store cannot leak, does not have to be secured and raises no questions from a customer asking for accountability. Especially with sensitive data — health, finances, children — the cheapest protection is still not recording it.

As soon as a SaaS processes data belonging to other companies, the legal role changes. The customer is then the controller and the product is the processor: it does something with data on that customer’s behalf. A processing agreement goes with that, and business customers will ask for one sooner or later — sometimes in the first conversation, certainly in healthcare, education and finance.

A few things come back in every assessment. Where does the data physically sit, and does it stay inside the European Union? Which other parties get to see it — a payment provider, an email service, an error reporter? How long is it kept? Who inside your organisation can reach it? And what happens when something goes wrong: how do you notice, who is warned and within what period.

Data subject rights are not a paperwork matter but functionality. Someone may view their data, have it corrected and have it deleted. A product where that is only possible by hand costs time every month; a product where it is arranged sells itself to the customer who asks. The same goes for a processing register and a short, readable explanation of what is stored.

Then there is legislation that differs per sector: retention periods in healthcare, invoicing requirements, rules around children, sector agreements about access. That belongs on the table before the setup is fixed, because it touches the data you keep and the way you separate it. Plaincodelab builds with those requirements as a starting point; anyone who collects them afterwards builds twice.

In a SaaS, security is not an extra but part of the product being sold. Customers hand over their work, and the first question from any slightly larger customer is how that work is protected. The good news: most of it consists of a solid foundation, not exotic measures.

That foundation is well known. Passwords are stored hashed and never in a readable form. Sessions expire and can be revoked. Two-step verification is available to those who want it and can be enforced for administrators. Every query checks again whether this user may see this data. Uploads are checked for type and size. Forms and sign-in attempts have limits, so guessing does not pay.

Beyond that there should be visibility of what happens. A log of important actions — who signed in, who changed permissions, who deleted something — helps with customer questions and with untangling incidents. Alerts on unusual patterns are more useful than a long list of rules nobody reads.

Finally, there should be a plan for the moment something goes wrong. Not because it is likely, but because the answer has to be ready: how is a breach reported, who informs customers, how is an earlier state restored and what is changed afterwards. Customers forgive an outage; they rarely forgive silence.

Customers use your product alongside everything they already have. An accounting package, a calendar, a till, a stock system, an email service, a payroll package. The question is not whether there will be integrations, but which comes first — and the audience answers that better than an assumption does.

Integrations are often the difference between a nice product and an indispensable one. Once data no longer has to be retyped, switching to another product becomes expensive for the customer and your place in their day becomes obvious. It is therefore rarely wise to promise ten at once: one integration that works flawlessly is worth more than five that half work.

Conversely, your own programming interface is the tool others use to connect to you. For most products that is not a first concern, but it is a reason to keep the data tidy: a product with a clear structure from the start can open that interface later without rebuilding everything. For customers with their own IT department, asking about it is a sign of serious interest.

Finally, watch dependency. Every integration is a party that can change, get more expensive or stop. That is no reason to avoid them, but it is a reason to know what happens if one falls away: does the product stay usable, or does everything stop? That answer should be known before the customer asks.

A product with three customers and a product with three hundred are two different things, even when the software is the same. What changes is less the technology than the contact: a customer you know personally emails about a problem; a customer you do not know cancels without saying anything. Growth means having to see things you used to simply hear.

On the technical side the first brake is usually not the number of visitors but heavy operations: a report that recalculates everything, an export of a full year, file processing that grows per customer. That kind of work belongs in the background, so one heavy customer does not slow everybody else’s screen. It is wise to separate this early, even when three customers cannot notice it yet.

On the organisational side, questions arrive that have nothing to do with building. Who answers the emails, how are new customers shown the ropes, what happens when two large customers want opposite things, and which requests do and do not get built. A product without a clear line becomes the average of every request — and therefore nobody’s favourite any more.

Finally, the way improvements are rolled out changes. With three customers you can adjust something and mention it. With three hundred, somebody is always in the middle of their work. Announcing, testing on a separate environment and being able to fall back to the previous state become part of the normal rhythm.

A SaaS is not a job that finishes but a service that runs. That is the most honest thing to say about it. Customers work in it, have questions, run into faults and expect somebody to be there. That asks attention from the owner, even when the building is done by someone else.

In practice that means a few things. There is a place where customers can go with questions, and someone who answers. There is clarity about what happens during an outage. There is someone who decides which requests go in and which do not. And there is an environment where the product runs, with the bills and responsibilities attached — that belongs to the product regardless of who ends up managing it.

There should also be room for maintenance nobody sees. Components get new versions, integrations change, security problems in the libraries used get published and have to be fixed. That work produces no new feature, but it is the reason a product still works years later.

All of that can be organised, and Plaincodelab thinks along: which tasks are yours, which belong to a technical party and which to the services around it. Exactly where that lands differs per situation, and is agreed before building starts — not as an afterthought.

On a website, measuring is about visits. In a SaaS, measuring is about use, and that is a different conversation. The question is not how many people stopped by, but whether they got in far enough for the product to do its job — and whether they came back afterwards.

The most important moment is activation: the first time a new user sees the result they came for. In an invoicing product that is the first invoice sent, in a scheduling system the first week planned. Whoever sees how many people do not reach that point knows exactly where the product loses them — often in a screen the builder found perfectly logical.

Besides that, there are a few things every owner wants to see without asking: how many accounts are active, which parts are genuinely used, where people get stuck, how many customers cancel and what reason they give. That last one is not a statistic but gold: cancellations tell you more honestly where the product falls short than surveys among happy customers do.

Measuring does not have to mean tracking users. For most questions it is enough to count what happens inside the product, without building profiles or sending data to third parties. That matches the privacy expectations of business customers and saves explaining in every security conversation.

Most customers who drop out drop out before they have done anything. They sign up, land in an empty screen, do not know where to start and close the tab. Everything that comes after — the thoughtful reporting, the clever integration — they never saw. That makes the first fifteen minutes the most important part of a SaaS.

An empty screen is the biggest culprit. A new account should not be empty but inviting: an example showing what it looks like when filled, a first step that can be completed in one action, or the option to import existing data so someone immediately recognises their own situation. Anyone who sees their own name inside the product keeps looking longer.

Invitations follow straight after. In most products value only becomes visible once colleagues are in it: a schedule without a team is a calendar, a file without a second reader is a text document. An invitation sent in two clicks that drops the recipient in the right place does more for usage than any feature.

Finally: think about what happens when somebody returns after a week. Does the product remember where they left off? Is there a short hint about the next step? Is a single message sent that helps rather than annoys? Details like these decide whether a trial account becomes a customer, and they are cheaper to think through in advance than afterwards.

Building a SaaS and selling a SaaS are two different things, and the second starts earlier than most owners expect. Software nobody knows about gets tried by nobody. That does not mean a marketing department is needed, but it does mean thinking about how somebody with this problem ends up at this product.

For a vertical SaaS the first customers usually arrive through people: a trade association, a fair, a group chat with peers in it, a supplier serving the same audience. That is slower than an advert but more durable, because the people recommending it know what they are talking about. For many products the first ten customers are literally friends of friends.

Beyond that, people search for their problem, not for your product name. Somebody types what they want solved: a way to keep track of something, a system for a particular task, an alternative to a package that is too expensive or too heavy. A product site that answers those questions literally — in plain words, explaining what it does and does not do — gets found and gets mentioned, including by assistants summarising on a user’s behalf.

What helps is being clear about what the product is. Who it is for, which problem it solves, what is and is not in it, and how somebody can look around without immediately committing. Products that stay vague get compared on price; products that are sharp get compared on fit.

Most SaaS products do not founder on technology. They founder on choices that looked sensible at the start and could not be undone later, or on a first version that grew so large no customer ever got into it.

The best known is wanting too much. Every conversation produces a good idea, every idea seems small, and together they become a product that is still not presentable months later. The opposite is just as damaging: a version so bare that nobody can do their work in it and there is nothing to learn from.

Next comes building for one customer. A first customer who pays is worth gold, but building in all their wishes delivers bespoke software with a subscription attached. The distinction between “everybody needs this” and “this one customer wants this” is the most important choice an owner makes over and over.

The rest of the list below shows up in almost every first product. All of them can be avoided by recognising them in advance — which is exactly why they are here.

An idea is ready when it can be explained in one sentence to someone from the audience, and that person immediately understands why it exists. Not because the sentence is elegant, but because it proves the problem is sharp. Everything after that — screens, integrations, subscriptions — fills in a choice already made.

It also helps to have answers to four questions. Who is the user, and who decides on purchase? Which step in their week becomes easier? What do they do today instead? And what is explicitly not in the first version? Anyone with those four on paper has done more groundwork than most starting products.

What is not needed to begin: a fully finished design, a name everybody likes, a thirty-page business plan or certainty about everything that comes later. Those grow along the way. What is needed is a first version small enough to actually reach people, and large enough for them to do their work in.

Plaincodelab builds SaaS products with the techniques that suit the product — not with one fixed choice laid over everything. What is needed depends on what the product has to do, what it talks to and who will use it. That reasoning is explained before building starts, in plain language, so you can follow why something is set up the way it is.