Technology · SaaS development
Custom SaaS development for when the software is part of what you sell.
A SaaS product is not an application with a login. It is a product that has to repeat cleanly for every customer who joins: their own space, their own users, their own configuration and their own plan, all on the same product everyone else is using. That is what we build.
- B2B SaaS
- Multi-company platforms
- Subscriptions
- MVP and evolution
Built once
The product
- One codebase
- One version
- One deployment
And each customer comes in
Estudio Nord
- 12 people inside
- Team plan
- Their rooms and their rates
Grupo Vallès
- 38 people inside
- Business plan
- Their four sites
Casa Miró
- 3 people inside
- On trial
- Their diary
and whoever joins tomorrow, without touching the product
The software is one. The data, the users and the configuration belong to each of them.Example names.
The difference
One improves how you work. The other is part of what you sell.
Custom software helps you run your business.
It is built to improve how the company operates. Its value is in the work it simplifies, coordinates or stops being done by hand.
SaaS is part of what you sell.
It is built to become a product. Its value depends on different customers being able to take it on, use it and keep getting something out of it.
There are exceptions — an internal tool can end up being sold, and that is often the best way to start — but the question that settles everything else is always the same: does the software help run your business, or is it part of the product you sell?
Where the hard part starts
The hard part starts when the second customer arrives.
Building something that works for one customer is a good demo. Making it work for the second without breaking the first is another project: that is where the decisions a prototype never had to make all turn up at once, and they are the ones that decide whether the product can repeat.
Customer 1
It does exactly what it should do: prove the core really solves someone’s problem.
There is nothing to repeat yet.
Customer 2
This is where it all turns up, and it turns up together.
What has to be settled for the product to repeat
- Keeping the data apart: one can never see the other’s
- Deciding who can do what inside each company
- Letting each customer have their own configuration without keeping two versions of the product
- Signing a customer up without someone setting it up by hand
- Knowing exactly what they have taken on
- Charging according to the agreement and knowing whether they are up to date
- Dealing with one customer’s problem without looking at anyone else’s data
- Changing something for one without breaking it for another
Customer 20
Now you can see which parts still depended on someone from your team being there.
What a person was still doing
- Finishing off each new account by hand
- Checking and fixing whatever gets left half done
- Handling the usual exception: the customer who needs something different
Customer 200
The product works. That is no longer the question.
The limit
Every manual step that is still there is now multiplied by two hundred: that is where a product that works stops being a product you can actually run.
The important jump happens with the second customer: that is when you stop building for one and start building something that can repeat. Scaling after that is finding out which exceptions are still unresolved.
From idea to product
An MVP is not a small product. It is the core without what goes around it.
Starting with an MVP is usually the right call: it is there to prove that someone cares what the product does before you spend the budget on everything else. What does not work is selling it as though it were already a product. Between the two, what it does never changes; what changes is everything needed for anyone to do it without you standing there.
Idea
There is a sentence and nothing else. This is the moment to check that someone would pay for it, not to open the editor.
What it does, in one sentence
A company publishes its slots and its customers book and pay for them.
What goes around it
None of this is needed yet.
MVP
It genuinely works for one customer. Everything else you do by hand, and that is fine as long as it does not last.
A company publishes its slots and its customers book and pay for them.
What goes around it
- Access
- The screen where it happens
- A database
- A deployment
Product
Now someone you have never met can take it on, use it without you explaining anything, and pay for it without anyone reminding them.
A company publishes its slots and its customers book and pay for them.
What goes around it
- A space per customer
- Roles and permissions
- Their own configuration
- Sign-up and onboarding
- Plans and limits
- Subscription and billing
- Admin panel
- Usage metrics
- Support with context
- Changes that break nothing for anyone
The core is written three times and it is the same sentence: it has not been touched. What has been built around it is exactly what turns software that works into a product that sells.
One product, many companies
Every customer works in their own space. None of them sees anyone else’s.
It is the first decision a SaaS makes and the last one you can change. A customer comes in, sees their data, their users and their configuration, and has no way of reaching the ones next door. Underneath, all of them are using exactly the same product.
Each customer’s space
Nothing crosses here
Estudio Nord
- Their rooms and their rates
- Twelve people inside
- Admin · Team · Read only
Grupo Vallès
- Four sites and their diary
- Thirty-eight people inside
- Management · Room · Front desk
Casa Miró
- One space and its diary
- Three people inside
- Admin · Read only
The same product for all of them
- One codebase
- One version
- One deployment
- One improvement that reaches everyone at once
Look at the last line of each space: the roles are not the same. Every company organises its people the way it works, and the product is still one product. That is configuration, not a different version per customer.Example names.
And above all of it, you
You see the accounts, the plans, the usage and the issues across all of them. You do not work inside any of them: you run the product.
This is what gets called multi-company architecture — multi-tenant, in the technical conversation — and it is not a detail you can leave for later: deciding it late means rewriting the part of the product that touches absolutely everything else.
How a customer comes in
Every sign-up that depends on your team is a ceiling.
You will not notice it with five customers. With fifty it decides how many you can have at all, because growing stops depending on how many you sell to and starts depending on how many your team can set up that week.
Today, when a new customer arrives
- Your teamAn email arrives
- Your teamSomeone calls to work out what they need
- Your teamTheir user is created by hand
- Your teamTheir account is configured by hand
- Your teamTheir login details are sent over
- Your teamSomeone explains how it works over the phone
In a product
- The productThey sign up, or someone inside invites them
- The customerThey answer the minimum for their space to be useful from the first minute
- The productThey come in
- The customerThey do something genuinely useful, not a guided tour
And from then on, on every screen
- What plan they are on
- What limits that plan carries
- Whether they are still on trial
- Whether the subscription is up to date
- What they can use today and what they cannot
This does not mean everything has to be automatic. There are products — in B2B especially — where the first meeting is part of the sale and should exist. The difference is that the person is then there because you decided so, not because the product cannot manage on its own.
A product charged by subscription has to answer that on every click, not in a spreadsheet. Once it does, moving up a plan, lifting a limit or recovering an unpaid account stop being someone’s job and become part of the product. The payment gateway — Stripe or whichever fits — is the easy piece of this story; the rest is product.
What we build
A SaaS is organised by who touches each part, not by feature list.
The same four questions organise any SaaS platform: what the person sitting down to work does, what their company configures in its own account, what your team needs to run the product, and what has to happen on its own underneath.
Whoever uses it
What the person sitting down to work does
The part the customer uses and that makes up the value they take on.
- Sign-up and access
- Onboarding
- The screen where the work happens
- Workflows and statuses
- Documents and downloads
- Alerts and notifications
- Use on mobile
The customer company
What each company configures in its own account
What makes the same product work for companies that operate differently.
- Users and teams
- Roles and permissions
- Their configuration and their rules
- Their master data
- Their branding where it makes sense
- Their plan and their invoices
- Their integrations: CRM, ERP, calendar, accounting
Your team
What it takes to run the whole product
Someone has to sign customers up, charge them, look after them and see what is going on inside. That gets built too.
- Admin panel
- Accounts, plans and statuses
- Subscriptions, payments and billing
- Limits and exceptions
- Support with the context in front of you
- Usage, activation and retention analytics
The product
What does not depend on anyone being there
What happens on its own and what holds it up underneath. It is what decides whether you can keep building on it next year.
- Multi-company architecture
- Data model
- Front end, back end and database
- APIs and integrations
- Security and isolation between customers
- Performance and scalability
- Deployment and environments
- Ongoing maintenance
If the conclusion here is that what you need is not part of what you sell but part of how you work inside, then it is a different project: Custom software or Custom web development, and it is organised differently from day one.
How we go about it
First you find the core. Then you get it ready to repeat.
The most expensive way to build a SaaS is to build thirty features before knowing which one someone opens every day. We work the other way round: narrow it down until one thing is left that the product has to do better than anyone, prove it with real customers, and only then build around it what it takes for that to repeat.
Problem
The questionWhat is being sorted out by hand today, and who suffers for it?
- Reports
- Internal chat
- Mobile app
- Multi-language
- Integration with their ERP
- Invoicing
- Customer panel
- Automations
- Document signing
Every idea on the table goes up. All of them fit and none is ruled out yet: ruling things out before looking at them is how the good ones get lost.
User
The questionWho opens this on a Tuesday morning, and what for?
- Customer panel
- Invoicing
- Automations
- Alerts
- Statuses
You pick the specific person who has the problem. Half the ideas belonged to somebody else, and they fall away on their own.
Core
The questionWhat does that person do over and over again?
- Book and charge for a slot
One sentence is left. It is the only thing the product has to do better than the spreadsheet that person uses today, and it is the first thing built.
Repetition
The questionWhat gets shared and what has to stay apart?
- The same core
- The same core
- The same core
- The same core
The same core gets ready to work just as well for every customer: their space, their users, their configuration. Nothing new is added; what is already there is made repeatable.
Product
The questionWho pays, who runs it and how does the next one come in?
- The same core
- The same core
- The same core
- The same core
- The same core
- The same core
- Sign-up
- Plan and limits
- Charging
- Admin
- Support
Around the core, now repeatable, come sign-up, the plan, the charging and the admin panel. From here it can be sold without you standing there.
The first two movements happen once. The last three never finish: every new customer shows you something the product did not know how to do yet, and that is the part of the work that never ends.
The proof
One product. Two hundred companies. Each in their own space.
Konevent is a SaaS for booking and managing venues that we designed and built. We show it here because it proves the thing that is hardest to explain: it is not an application we made for one company, it is a product that different companies come into, each with their own rooms, their own prices, their own team and their own bookings.
Konevent
Booking and venue management SaaSMore than two hundred companies work inside the same product without ever seeing each other.
+200companies
One line, one company
One of those spaces, opened
Real screenshots of the product, with demonstration data.
What had to be solved
Every event venue is run its own way: its slots, its capacities, its rates and its way of taking a deposit. A tool built for one of them is no use to the next, and a generic tool is no use to any of them. What had to be built was not a booking application: it was a product able to absorb those differences as configuration.
What was built
A space per company with its own users and permissions; the rooms, the slots and the rates in each company’s hands; the public widget their customers book through; the panel where their team sees everything; the manual entry for whatever comes in by phone; the payments; and the admin panel the whole product is run from.
All three screenshots come from a single space. The rest have the same screens with their own data, and none of them has any idea the others exist. That is the work you never see in a demo, and it is exactly the work that decides whether a SaaS holds up.
Where it fits
When it makes sense to build a product.
- You already look after your customers in a way that repeats, and you know exactly which part repeats.
- You want to sell the product, not just own it: it matters to you that a customer can come in, use it and pay for it without you standing there.
- You accept starting with the core rather than the catalogue, even if the first version shows less than you would like.
- You are going to be in the room deciding: product decisions are business decisions and they are not handed to whoever writes the code.
We work on
- B2B SaaS
- Multi-company platforms
- Turning a service or an expertise into a product
- Internal tools you want to sell
- An MVP to prove an idea
- An MVP that no longer scales
- Customer portals
If what you need is a tool for your own operation — used by your team and nobody else — you do not need a SaaS: you need custom software. It is a more direct problem and it avoids building the whole product layer you have no use for: multi-company, plans, onboarding, administration and repetition. We will tell you so in the first conversation.
Frequently asked questions
What gets asked before starting.
How much does custom SaaS development cost?
It depends on one thing above all others: how much has to be solved for the product to work just as well for customer number two as it does for number one. That is where a SaaS budget goes, not into the number of screens. Which is why the useful conversation does not start with a feature list but with what a customer has to be able to do from the moment they come in until they get something of value. With that you can scope a genuine first phase and say what goes in now and what is better left for the second.
How long until it is in the hands of the first customer?
Less than people tend to assume if you start with the core, and a great deal longer if you start with the full catalogue. We work in phases with one clear goal for the first: that a real customer can use the product and that you can watch what they do with it. Everything not needed for that — integrations, reports, automations — has its place, and its place is afterwards.
Can we start with an MVP and grow from there?
Yes, and in most cases that is what we recommend. A well-planned MVP is not a cut-down version: it is the core of the product genuinely working for one customer, with everything around it still done by hand. Charging, for instance, can perfectly well wait for the second phase; when it arrives we integrate the gateway and the logic for subscriptions, plans and limits. What is worth settling from the start is how each customer’s data is kept apart, because that is the one thing you cannot add later without touching everything.
We already have a first version that has outgrown itself. Do you carry it on or does it need rebuilding?
First we look at it and tell you which of the two comes out better, with reasons. It is a very common situation: an MVP that proves the idea and then cannot cope with customers coming in, almost always because everyone’s data lives mixed together or because each new customer means touching the code. Sometimes you can rewrite just that part and keep the rest; sometimes it is cheaper and quicker to rebuild the core and bring the data across. What we do not do is decide before we have looked.
Who owns the product? Who keeps the code?
You do. The code, the database, the domains and the accounts for whatever services get used stay in your name, and they are handed over documented in a repository you have access to from day one. It is a reasonable condition on any development and more so on a SaaS: the product is the business’s asset, so it cannot depend on us carrying on working together.
Who maintains it, where is it hosted and what happens if a lot of customers come in at once?
Hosting is decided by what the product needs and stays on infrastructure of yours. Maintaining a SaaS is different from maintaining a website: it is not only keeping it up, it is fixing issues, watching performance and security, updating and carrying on building. We normally set it up as an ongoing relationship with a written scope, not as a bucket of hours. On growth: getting the product ready to scale is an architecture decision taken at the start — how the data is kept apart, how it is queried and what can be spread out — and after that it is a matter of measuring and widening whatever asks for it. What nobody can do is promise it will cope with anything without having seen the product.
What if what we want to do is already solved by a tool that exists?
Then use it. That is the honest answer and we give it often. Building a product only makes sense if what you are going to sell is different from what can already be bought, or if what exists forces your customers to work in a way that is not theirs. If the difference is the price or a couple of details, paying the licence works out far better. We look at that before proposing anything, and if that is the conclusion, we say so.
Let’s talk
If you do it by hand for one customer today, tell us how it should work for a hundred.
What helps us answer you properly: what a customer should be able to do from the moment they come in until they get something useful, and which part of that someone on your team does today. With that we can tell you where we would start, what can wait and whether this is solved by building or with something that already exists.