Having custom SaaS built: costs, timelines and pitfalls

Start with a first version that is small enough

Most SaaS ideas start too big. That makes sense: you can already see the end result. But every feature you add has to be built, tested and maintained, and it pushes back the day you learn from real users whether your idea works.

Eric Ries, who popularized the term minimum viable product (MVP), describes it as the version of a product that lets you learn as much as possible about your customers with the least effort. He stresses himself that it is not about a stripped-down product, but about learning. For a SaaS that means one type of user, one important problem, and solving that problem well.

A first version needs the main workflow, signing in, a simple way to manage data and a solid security foundation. The list below can almost always wait.

• Several types of users, each with their own permissions.
• Extensive dashboards and reports.
• Integrations you can do by hand for the first months, such as an export to your accounting software.
• Several languages, unless your customers really need them.
• Settings for every exception you can think of.

What drives the cost?

A price for custom software depends less on how many screens your app has than on what happens behind those screens. These are the parts that determine the bill the most.

A useful exercise: write down for each part why you need it in the first version. If you cannot explain it in one sentence, it is a candidate for later.

Features

The number of things your app can do, and especially how many rules and exceptions sit behind them.

User roles

Every role, such as admin, employee or customer, means its own permissions that have to be built and tested.

Integrations

Every connection to another system, such as accounting software, a CRM or an external API, costs build time and later maintenance.

Payments

Handling subscriptions, invoices, trials and failed payments properly is more work than it looks.

Admin screens

The screens you use to manage customers, accounts and settings. Often forgotten, but you use them every day.

Security and privacy

If you store personal data, access, storage and logging have to be set up for it.

Fixed price or by the hour?

With a fixed price you know in advance what you will pay. That works when it is clear what will be built. That is why a good project starts by writing down the scope: what is included and, just as important, what is not. If you want to add something along the way, you agree a new price for it, instead of the bill quietly growing.

Paying by the hour is more flexible, but the risk is yours: if something takes longer, you pay more. That suits work where you genuinely cannot know in advance how it will turn out, such as investigating an integration with a system that lacks good documentation.

For new SaaS and web apps I work with a fixed price per project. Projects start at €5,000 excluding VAT. With a bigger idea it is often smart to work in phases: a fixed price for the first version, and only then pricing the next step, based on what you learned from your users.

How a good project runs

Every project is different, but a good project almost always has the same steps. The most important thing is that you regularly see something that works, so you can steer before weeks of work go in the wrong direction.

1. 1Introduction: you explain what you want to solve and for whom.
2. 2Scope on paper: what is in the first version and what is not.
3. 3A fixed quote based on that scope.
4. 4Building in short rounds, with a demo after each round that you can try yourself.
5. 5Testing with a few real users before everyone gets access.
6. 6Launch: going live, with monitoring and backups from day one.
7. 7Maintenance: updates, bug fixes and building on what users ask for.

How long does it take?

Honest answer: it depends on everything above. A simple web app for internal use is often a matter of weeks, a SaaS with payments, several roles and integrations more likely a matter of months. Anyone who promises you a timeline before the scope is on paper is guessing.

Projects rarely run late because of the programming alone. More often the delay is in waiting: for feedback, for copy and content, for access to an external system or for approval from a payment provider. Plan those things early, so your developer is not left waiting.

The biggest source of delay is a scope that grows along the way. PMI’s 2018 Pulse of the Profession survey found that 52 percent of completed projects experienced scope creep or uncontrolled changes to their scope. New ideas are fine, but put them on a list for the next version.

The pitfalls that cost you money

Most problems with custom software only show up after launch, when it is too late to fix them cheaply. These are the five I come across most often.

The second point in particular is often overlooked. In the Netherlands, copyright in software stays with its maker unless it is transferred in a written deed. Paying for the work does not automatically settle what you may do with the code. So put it in writing up front, together with where the source code lives and how you can access it.

• A scope that keeps growing along the way, without anyone adjusting the price or the planning.
• No clear agreements about the code and the accounts. Make written agreements about the ownership and usage rights of the code, and make sure you have access to the source code. Put accounts such as your domain, hosting, database and payment provider in your own company’s name.
• Being locked in to one party, for example through a closed platform or rare technology that only your current developer knows.
• No budget for maintenance. After launch the work only begins: updates, bugs and requests from your first customers.
• Skipping security to go live sooner. The OWASP Top 10 is a good baseline for what needs to be in order before you store real customer data.

Choose proven technology

It is tempting to build a SaaS with the newest framework. Developer Dan McKinley wrote a well-known essay about this, Choose Boring Technology: with technology that has been around for years, you know what it can and cannot do, and its problems have already been solved and written about. With new technology you discover those problems yourself, at your expense.

That is why I build with Java, Spring Boot, PostgreSQL and Vue. It is the technology I also work with at large organizations such as ING and ABN AMRO. It is widely used, supported for a long time and there are many developers who know it. That last part matters: you do not want to depend on one person, not even on me.

What I do not build: mobile apps and desktop apps. A good web app does work fine on your phone, in the browser.

Example: Traecy

Traecy is my own SaaS, which I have been building since 2025. It helps quality managers in the food industry: Traecy filters RASFF notifications, the European warnings about risks in food and feed, per raw material, requests documents from suppliers and records in an audit trail who did what.

It started with one question from practice: how does a quality manager find out in time which RASFF notification concerns their raw materials, without searching for it every morning? Only when that worked did the supplier requests and the audit trail follow. Today 7 food companies use it, such as Willemsen Kip, TM Salades and Habo Vlees.

Traecy runs on the same technology I use for clients: Java and Spring Boot, PostgreSQL and Vue. It shows how I work: start small, learn from real users and only then expand.