You are considering having custom software built. Not because it is trendy, but because the off-the-shelf packages do not quite fit, or because your growth is hitting the wall of your current spreadsheets. The question that follows is usually the same: what does it really cost, how long does it take, and how do I know I am not locked in to a single vendor for four years? This guide answers those three questions with numbers from real projects, an honest cost table, and the pitfalls we see SMB owners lose literal months to. No jargon. Just a roadmap, and see also our no-code vs custom guide for the broader trade-off you can use to take the first step this afternoon.
What is custom software, exactly?
Custom software is an application built specifically for your business, based on your processes and your data, with code that is your property. That contrasts with SaaS packages where you rent a licence on software that works the same way for thousands of companies, and with no-code platforms where you click around in a visual editor on top of an underlying platform engine that is not yours.
The most important difference is not in the technology, but in the ownership relationship. With SaaS, you rent access. If the vendor stops or raises prices, you are stuck. With no-code, you are building on someone else’s platform; your flows are often not exportable. With custom software, you get the source code, the database, the hosting instructions. You can switch suppliers tomorrow without anything breaking.
When is custom the right choice?
Honest answer: in 60 to 70 percent of the SMB cases we assess, custom software is not the first step. Custom only becomes the right choice when one of five scenarios applies.
- Bespoke business logic that does not exist anywhere else. Think: a point-tally for social housing, or your own pricing model with dozens of variables.
- Integrations with legacy systems that have no modern API. An ERP from 2009, a SOAP connector, a database only accessible via SQL views.
- Volume that makes SaaS unaffordable. Above 100,000 transactions per month, many SaaS packages get exponentially more expensive.
- Competitive advantage from your own software. When your software is the difference between winning or losing a customer.
- Compliance or data requirements that force self-hosting. Medical records, legal case files, financial transactions.
Walk through those five before you request a quote. None of them apply? Start with SaaS or with no-code automation, and upgrade to custom only when you hit a real limit.
What does building custom software cost?
Honest answer: the spread is wide, and agencies quoting a single number do not understand your scope. We deliberately price at the lower end of these ranges and typically deliver in about half the timeline you see elsewhere in the market. Below is a table with indications based on projects we built for Dutch SMBs.
| Project type | One-time investment | Duration | Monthly maintenance |
|---|---|---|---|
| MVP (first working version, 1-2 modules) | €8,000 – €18,000 | 2-3 weeks | €150 – €400 |
| Standard platform (3-6 modules, login, integrations) | €20,000 – €50,000 | 4-8 weeks | €400 – €1,200 |
| Extensive platform (multi-user, AI, dashboards) | €50,000+ | 2-4 months | €1,200 – €2,500 |
| Enterprise-grade (compliance, scale, multi-tenant) | €100,000+ | 3-6 months | €2,500 – €6,000 |
Hourly rates in the Dutch market sit between €85 and €165. With us, we work with a fixed price per phase. Monthly hosting is surprisingly low: a Hetzner VPS costs €10 to €40 per month. Total Cost of Ownership for an SMB platform after the first year often lands at €1,500 to €5,000 per year all-in. For the detailed breakdown see our upcoming article on custom software costs.
Which phases do you go through in a custom project?
- Discovery (1-2 weeks). Deep research into your processes, users, data and pain points. Output: a functional document with user stories, a data model, a wireframe set, and a fixed price for the build phase. Never skip this.
- Design (1-2 weeks). Based on discovery, we make interactive prototypes in Figma. Goal: before a line of code is written, you and your team can click through the system.
- Build (1-20 weeks depending on scope). The actual development, split into two-week sprints with demos. Demand a working version every two weeks.
- Test (in parallel + 1 week of final sprint). Automated tests, manual acceptance tests with real users, and a security scan.
- Launch + maintain (ongoing). Go-live with monitoring, a handover document, training for your team, and an SLA for the first 6 to 12 months.
A common mistake: jumping straight into build without discovery. In 9 out of 10 cases, what comes out does not fit the actual workflow. At minimum, plan a paid discovery of two weeks. For details see our upcoming article on having an MVP built. For inspiration, the Mastone case study is a concrete example.
Which tech stack do we pick in 80% of cases?
| Layer | Our choice | Why | Alternative |
|---|---|---|---|
| Backend | Node.js (TypeScript) or Python | Largest talent pool in NL, mature ecosystem | Go, .NET Core, Java Spring |
| Frontend | React (Next.js) or Astro | Stable, broadly applicable, good performance | Vue, Svelte, Angular |
| Database | PostgreSQL (via Supabase or self-hosted) | Open source, reliable, well documented | MySQL, MongoDB |
| Hosting | Hetzner VPS or Vercel | EU residency, predictable costs, easy to migrate | AWS, Cloudflare, DigitalOcean |
| Auth | Supabase Auth or Clerk | Fast, secure, GDPR-friendly | Own JWT implementation, Auth0 |
| Monitoring | Sentry + UptimeRobot | Sufficient for 95% of SMB projects | Datadog, New Relic |
| CI/CD | GitHub Actions | Free at SMB volumes, simple to set up | GitLab CI, CircleCI |
Why no exotic choices? Because a stack that is hip in 2026 will no longer be maintained in 2031 by anyone you can hire. PostgreSQL, Node.js and React have been around for 10 to 25 years. According to GitHub Octoverse 2024, JavaScript, TypeScript and Python have held the top 3 most-used languages for years. For specific use cases we deviate with a reasoned argument. For the broader trade-off between platforms, see our upcoming article on web app vs SaaS vs custom platform.
What is code ownership and why does it matter?
Code ownership means all source code, configurations, deployment scripts and documentation of your platform are your property. Not licensed. Not “shareable”. Owned, contractually documented, in a Git repository under your account, with deploy instructions another party can follow.
At TopDevs we deliver four things as standard: a Git repository under your account, a README and deploy document, all credentials under your control, and a two-hour handover session. That is in our terms and conditions as a standard deliverable. For the deeper material, see our upcoming article on code ownership.
How long does a custom project really take?
| Project type | Discovery + Design | Build + Test | Total | Sprints |
|---|---|---|---|---|
| MVP (1-2 modules) | 1-2 weeks | 1 week | 2-3 weeks | 1-2 sprints |
| Standard platform | 1-2 weeks | 3-6 weeks | 4-8 weeks | 2-4 sprints |
| Extensive platform | 2-3 weeks | 6-13 weeks | 2-4 months | 4-8 sprints |
| Enterprise-grade | 3-4 weeks | 9-22 weeks | 3-6 months | 6-12 sprints |
For Mastone we built the WWS platform with a two-week discovery, a two-week design, and an eight-week build phase across four sprints. Total: three months from first conversation to production. The project did not slip because the scope was well defined upfront and because on the client side there was one decision-maker who answered questions within 24 hours. No magic, just discipline.
What risks are there and how do you avoid them?
- Scope creep without a mechanism. Avoid: route all scope changes through a formal change request with an impact estimate.
- Vendor lock-in without an exit plan. Avoid: before kick-off, ask for an exit clause and deploy instructions. See our article on code ownership.
- Bad or missing documentation. Avoid: documentation is not an option, it is a deliverable.
- No proper handover. Avoid: demand a handover session of at least two hours, recorded, with a written architecture explanation.
- No tests or weak tests. Avoid: ask specifically about test coverage. 60 to 80 percent coverage is normal for a good SMB codebase.
According to McKinsey research on software projects, 45 percent of large IT projects run over budget. Shorter timelines, a fixed price and a strict discovery are the three biggest levers on success.
What is a good SLA and what should it contain?
- Uptime guarantee. For SMB platforms, 99.5 to 99.9 percent is realistic and achievable.
- Response times by priority. With us: critical within 1 hour, high within 4 working hours, normal within 2 working days.
- Fix times by priority. A fix time of 4 hours for critical issues is normal.
- Availability window. For SMB platforms, business hours with an on-call rotation is often enough.
- Backups and restore guarantee. A daily backup with a restore promise within 4 hours is a reasonable floor.
- Maintenance hours per month. Typically 4 to 12 hours per month, depending on complexity.
What exactly happens in a discovery engagement?
Discovery is not a free meet-and-greet. It is a paid phase of one to two weeks where we run three to five working sessions of two hours, alongside mapping your existing spreadsheets, emails and manual steps. At the end you have a document any developer in the world could build your platform from, and a fixed price for the build phase on the table.
- Session 1 (process mapping): we literally film an employee performing a daily task in the current tools. Steps, clicks, copy-paste, error moments.
- Session 2 (data model): every entity on the table. Which fields, which relations, which validations, which audit requirements.
- Session 3 (roles and permissions): who sees what, who can do what. End user, manager, admin, customer. Separate table per role.
- Session 4 (integrations): which external systems, which APIs, which export formats. Per integration a deep check on documentation and stability.
- Session 5 (edge cases): what happens when the input is missing, duplicate, or fails the rules. This is where we find 30 percent of the scope that would otherwise surface mid-build.
A concrete example from practice. At an accountancy client, session 5 was where we found out their biggest customer (40 percent of revenue) uses an in-house invoice format that deviates from standard UBL-XML. Had that check happened during the build phase, it would have cost €4,500 in rework. Instead, it was in scope from day one. Discovery costs €1,500 to €3,500 and saves 5 to 15 percent of the build budget on an average project. For broader context see no-code vs custom automation.
When do you pick Node vs Python, Next.js vs Astro?
The stack table above is our default, but the choice between alternatives within that stack is not random. Per layer two to three factors set the call. Below is the trade-off the way we make it in every discovery.
| Choice | Pick this if | Pick the alternative if |
|---|---|---|
| Node.js (TypeScript) | Heavy async I/O, real-time features, shared types between front and back, team with React experience | Python: heavy data work, AI/ML pipelines, scripting, integrations with data-science libraries |
| Python (FastAPI) | Data processing, AI integrations, complex calculation models, ML inference | Node: full-stack JavaScript, real-time apps, same language for front and back |
| Next.js | Lots of interactive screens, dashboards, authenticated areas, per-user dynamic data | Astro: marketing site, content-heavy, SEO priority, little interactivity |
| Astro | Static-first, content management, blog, SEO, low time-to-first-byte required | Next.js: complex app state, lots of client-side rendering, real-time updates |
| Supabase (managed Postgres) | MVP, no DBA in-house, fast iteration, RLS policies fit the role model | Self-hosted Postgres: dataset >100GB, your own DBA, specific extensions, cost tuning at scale |
| Vercel hosting | Frontend-heavy, edge rendering needed, short deploys, small SaaS | Hetzner VPS: backend-heavy, websockets, long-running processes, predictable high cost |
Concretely: for Mastone we picked Next.js with Postgres because the dashboard is used 80 percent of the time by one internal role with many forms. For a marketing site with blog and case studies (like this page), we picked Astro because SEO and first paint matter more than client state. For an AI research assistant with embeddings and search queries, we picked a Python (FastAPI) backend with a Next.js front, because the Python side was needed for the ML libraries. Same agency, three choices, three reasons. For the broader trade-off see the upcoming article on web app vs SaaS vs custom platform.
Hosting compared: Hetzner VPS, Vercel or Supabase?
Hosting is the line item most often under-budgeted in quotes. Not because it is expensive (often the opposite), but because the choice between three to five options affects both cost and migration freedom. Below are the three setups we pick for 90 percent of SMB projects, with concrete monthly costs.
| Setup | When it fits | Typical monthly cost | Upside | Downside |
|---|---|---|---|---|
| Hetzner VPS + self-hosted Postgres | Backend-heavy, long-running processes, websockets, predictable volume | €15 – €55 | Full control, low cost at scale, EU residency in Nuremberg or Helsinki | Self-managed, security updates on you, no autoscaling out of the box |
| Vercel + Supabase (Pro) | Frontend-heavy, MVP, fast deploys, edge rendering, 0-30k users | €45 – €120 | Zero-ops, automatic deploys, Edge functions, free SSL, instant rollback | Pricing scales with bandwidth, lock-in on build system, cold start at low traffic |
| Cloudflare Pages + Workers + R2 | Static-first, global audience, cost-minimal at growth | €0 – €25 | Cheapest option, global edge, generous free tier, built-in DDoS protection | Limited runtime, no long-running processes, quirky debug experience |
| AWS (ECS + RDS) | Enterprise compliance, multi-region, complex DevOps, >100k users | €250 – €1,500+ | Mature ecosystem, certifications, fine-grained control | High complexity, long learning curve, costs climb fast without discipline |
Our default: Hetzner VPS for backend-heavy platforms (Mastone, Planit Consulting), Vercel plus Supabase for frontend-heavy MVPs and marketing apps, Cloudflare Pages for static sites and marketing bundles. We use AWS only when the client already has it or there is a specific compliance requirement. Migration between these setups typically takes 1 to 3 weeks on standard stacks, because the application code is decoupled from the infrastructure.
Who do you need on the client side?
A custom project rarely fails on technology. It fails on a slow decision line at the client, a product owner who has no time for it, or an end user who only sees what was built at delivery. For a successful project you need three roles on your side, and they do not have to be three different people.
- Decision maker (ultimately accountable): typically the founder, CEO or MD. Availability: 1 to 2 hours per week. Job: scope calls, prioritisation in conflicts, sign-off on change requests. Key trait: can give a yes or no within 24 hours.
- Product owner (daily point of contact): often the operations manager or senior employee who knows the process inside out. Availability: 4 to 12 hours per week. Job: answer questions, review demos, sharpen user stories, run acceptance tests.
- Power users (2 to 4 end users): the people who will use the system daily. Availability: 2 to 4 hours per sprint (every two weeks). Job: watch demos, give feedback on flow and usability, run acceptance tests before go-live.
| Role | Time per week | Decision authority | Risk if missing |
|---|---|---|---|
| Decision maker | 1 – 2 hours | Full on scope and budget | Project stalls at scope conflicts and change-request debates |
| Product owner | 4 – 12 hours | Functional on user stories | Wrong assumptions in build, late rework, scope creep |
| Power users | 2 – 4 hours per sprint | Feedback on usability | Low adoption after go-live, rework on UI/UX |
In practice this most often goes wrong in two patterns. Pattern one: the founder wants to be product owner but has only 1 hour per week available. Result: questions sit unanswered for 5 to 10 days, build slows 30 to 50 percent. Pattern two: no power user is involved, only management. Result: at delivery the actual user cannot run three critical workflows and you have three weeks of rework. At Mastone it worked because the founder was the product owner with 8 hours per week available, and two power users sat in the demos from sprint 1.
Concrete example: Mastone WWS platform
For Mastone we built a custom platform with the WWS logic at its core. Previously they did this in spreadsheets with one formula per cell and manual policy updates. A two-week discovery: all WWS rules captured in a formal data model. A two-week design: an interface where an administrator enters every property characteristic across 4 screens. An eight-week build across four sprints with demos. Testing in parallel through an extensive test suite. Launch with a handover document, training, and an SLA for the first year.
The result: properties can now be assessed in minutes instead of hours. When policy changes, we adjust the logic in one place. The audit report is the press of a button instead of a day of work. SaaS does not exist for this kind of calculation. No-code cannot handle it at this scale. Custom was not a luxury here, it was a rational choice. Payback period: 14 months. For other real-estate clients and for recruitment, law firms we see similar patterns.
What other cases are worth a look?
- Recruitment: for Simply we built a platform with bespoke scoring logic for incoming applications.
- Law firms: for BBS Advocaten we built an intake and case-file integration that classifies legal emails.
- Consulting: for Planit Consulting we built an AI research assistant that searches across their own reports.
What is the first step?
- Step 1: write down your problem in two pages. Not the solution, the problem. Which processes cost too much time?
- Step 2: check first whether SaaS or no-code is enough. Read our guide on no-code vs custom.
- Step 3: plan a paid discovery, not a free quote. A paid discovery (€1,500 to €3,500 with us, creditable) gives you a real functional document and a fixed price.
Book a free intake call if you want to look at it together. No sales pressure, just a well-reasoned recommendation. Our working method and guarantees are in our terms and conditions. For the solutions we build, see custom platforms, websites and dashboards and CMS.
