SaaS development.

An internal tool works for you, SaaS works for other companies

When a tool is used only by your own company, half the work disappears by itself. You know the users by name, training happens in the office, the data belongs to one company, and when something gets stuck, a colleague walks over and shows how. We build tools like that as custom software, and that is a separate job with its own logic and its own page.

A SaaS product overturns every one of those assumptions. The account is opened by a company you have never met, often at ten in the evening, and it decides within the first five minutes whether it stays. Nobody demonstrates anything: self-service signup, entering the first data and inviting colleagues have to work without a single person from your side. The data no longer belongs to one company but to every company that registers, so each must see only its own. And in the end, that company pays a subscription, month after month, which means that every month it decides again whether you are worth the figure.

That is why the same two screens are not written the same way, and do not cost the same, in an internal tool and in a SaaS product. The technical foundation is shared, an application with a login that lives in the browser; this page is about what gets added when a tool has to become a product that sells by subscription.

Multi-tenant, usage metering and the trial period

Three things technically separate SaaS from an ordinary application with a login. The first is multi-tenant architecture: one instance of the application serves many companies, and every record in the database knows which company it belongs to, so an accountant at one company cannot open another company's document even in theory. For larger customers we go a step further, with a separate schema or database per client, which also makes easier the things people think about only at the end: exporting all the data of a company that leaves, and deleting it on request. Within each company there are also roles, the owner who pays, the administrator who adds colleagues, the members who do the work, because the customer account is not one person but a whole company. All of this goes into the foundation: separating data afterwards is the most expensive rework this business knows.

The second is usage metering. Subscription plans differ by numbers: how many users a company may add, how many records or documents it enters per month, which features it sees. So the system counts usage per company from day one, and the benefit is double: billing has something to stand on, and three months in you are not guessing what to build next, you are reading what is actually used and what sits untouched.

The third is the trial period. Buyers want to try before they pay, and what happens when the trial expires has to be designed: the account does not vanish, it switches to read-only, the data is kept for an agreed period, and messages before expiry remind the user while there is still a reason to come back. Alongside that comes the decision whether to ask for a card before the trial or only after it; both approaches work, but they move the number of signups and the percentage who pay in different directions, so they are chosen deliberately, not inherited from a template.

The MVP path: one paid problem, not a platform

The biggest risk in a SaaS product is not in the code. The technical side can be delivered; what cannot be delivered is a customer who pays. So we do not scope the first version by asking which features the platform should have, but by asking which problem someone is already prepared to pay for, every month, today. One problem, one type of customer, solved end to end: that is the version you take to your first subscribers.

Billing goes into the first round, not the second. A product used by thirty free users for three months has proven nothing, because the distance from "this is useful" to "here is my card" is the longest distance in this whole business. It is perfectly fine to onboard the first few customers by hand: a conversation, setting up the account together, an invoice instead of a card if needed. You automate what already repeats by the third customer, not what might theoretically be needed.

Everything else waits for revenue and waits for usage: integrations with other systems, a public API, a mobile app, reports in five formats, a second language. Each of those is built more easily and more intelligently once there are twenty companies paying and telling you what bothers them. With SaaS that cut is sharper than with any other application: it is measured in subscriptions, not in features.

Subscription billing is half the product

The part of a SaaS project you cannot see in screen mockups is the billing layer, and in scope it is often equal to everything else. First the model is chosen: price per user, price per company regardless of the number of users, or price per usage. Then the plan structure and what each plan unlocks, then the trial period and what comes after it.

Then execution. You do not charge cards yourself but through a payment processor, and for selling internationally there is also the model where the intermediary is the formal seller (merchant of record): it calculates and remits taxes in the markets where your buyers sit, and forwards the payout to you. For a small team selling in twenty countries, that is often the difference between building the product and running tax administration as a second job. We build in the technical side and know what each service requires; the tax and accounting model for your company is something to confirm with your accountant, because that is not us.

Finally the edge cases, which decide how the product behaves in a real month, not in a demo recording:

• failed payments: an expired or declined card, then retries and a message to the user before anything gets switched off
• plan changes mid-period: prorated charges, in both directions
• cancellation: access until the end of the paid period, data export and a clear deletion deadline
• invoices: a document the customer's accounting accepts without a back-and-forth

None of these items is hard on its own; together they are the reason a SaaS product with the same number of screens costs more than an internal tool, and why the estimate is made only once this layer is unfolded.

What we have built from the same fabric

To be open about it: we have not yet launched a public SaaS product of our own, and we will not present ourselves as if we had. What we have built, and what stands in our portfolio with the client's name on it, are applications made of the same fabric: multi-tenant systems with roles, where different people on the same system see different things and do different jobs.

Kore is an application for tracking goods issued to drivers and delivery rounds, built for a filo pastry producer: drivers record from their phones what they take on and what they deliver per store, even without signal, while management watches live whether the numbers add up and where a shortage appeared. Two roles, two completely different views of the same data, exactly the way a company member and an administrator see different things in a SaaS product.

Certiwa Portal is a client portal we built for Swedish ISO consultants: the client follows document statuses and progress towards a scheduled audit, the consultant manages requirements by clauses of the standard, and nobody emails anybody to ask how far things have got. The portal is publicly available as a demo with fictional data, so you can walk through it before you ever contact us. And that we can think like a product, not only like a contractor, shows in Termin, our salon booking application, built as a product for many salons on one system, not as a single client's commission.

What SaaS development costs

For SaaS we deliberately do not put a figure next to the title. The range is too wide for one number to be honest: the same name covers a narrow tool with a single subscription plan and a platform with multi-currency billing, integrations and a public API. The price is therefore assembled from three scopes: the core that solves the paid problem, the subscription and billing layer, and self-service signup with user onboarding.

What pushes the scope upwards, so you know before we talk:

• the number of roles and views: company member, company administrator, your internal oversight
• the billing layer: number of plans, trial period, multiple currencies and tax regimes
• integrations with other systems and a public API
• languages and markets targeted from day one

There is still a reference point: web applications as the smallest scope start from €2,000, and SaaS adds the billing and self-service signup layer on top of that scope, so a realistic MVP comes out above that line. We keep complete price ranges by project type public on the pricing page.

A concrete figure comes free of charge and after a conversation, not before it: who the customer is, which problem they pay for and what goes into the first round. Describe the product through the contact form and a proposal with a price and a fixed deadline arrives within 24 hours. If the description shows you do not need SaaS but an internal tool or an ordinary website, we will say that too, with a smaller figure and a clear conscience.