Scope evidence before a build quotation
What does it cost to develop an online platform in the Netherlands?
An online platform might be a small internal tool, customer portal, marketplace or SaaS product. Those are materially different systems. Define the users, critical flow, roles, data, integrations and operating owner before treating any price range as useful.
By Sina Esfahani · Technical and editorial review · Market indications, not OmniTechs rates · Updated .
Platform development costs at a glance
Current Dutch supplier guides publish ranges from a few thousand euros for a narrow validation build, about €9,000–€18,000 for a simple SaaS MVP, roughly €20,000–€50,000 for a multi-user SME platform, and from about €50,000 for more extensive multi-tenant work.
These are overlapping signals from two suppliers, not an independent market rate, OmniTechs quotation or promised budget. Hosting, third-party services, maintenance, support, migration and internal product ownership may sit outside the quoted build.
Investigate a custom platform when
- a defined group repeatedly needs to complete a valuable core task
- roles, data, rules and exceptions are understood well enough to test
- maintained standard software does not responsibly support the critical workflow
- the organisation can own product decisions, security and operations
Do not build yet when
- a website, form, spreadsheet or existing product already covers the need
- the audience or critical task has not been validated
- every possible feature is being treated as version one
- no one can own the system after launch
Public Dutch examples reviewed 30 August 2026
How published ranges change with the example scope
Suppliers use the same labels for different deliverables. Use these ranges to interrogate a quotation, not to replace a project-specific scope. This comparison does not normalise VAT or contract treatment; verify what each source and quotation includes.
| Example scope | Published signal | Verify first |
|---|---|---|
| Landing page, waitlist and one integration | €3,500–€8,000 | Which hypothesis is actually being tested? |
| Simple SaaS MVP with authentication, two flows and payments | €9,000–€18,000 | Roles, core flow, payment and failure paths |
| Multi-user SME platform or marketplace | Approximately €20,000–€50,000 | Data model, permissions, integrations and ownership |
| Extensive multi-tenant or similarly demanding custom work | From approximately €50,000 | Scale, security, operations and total ownership cost |
Classify before estimating
Website, web app, portal, platform or SaaS?
These forms may share technology but carry different product ownership, controls and operating boundaries. MVP describes an evidence stage, not a separate product type.
| Form | Practical boundary | Dominant scope drivers |
|---|---|---|
| Marketing website | Publishes information and leads to an action without persistent user state | Content, discovery, forms, accessibility and editorial ownership |
| Web application | Lets a user complete an interactive task with data | Core flow, state, validation, permissions and failure behaviour |
| Customer or partner portal | Gives a known audience controlled access to its information or tasks | Identity, roles, privacy, documents and support |
| Marketplace | Connects multiple sides around supply, demand or transactions | Trust, moderation, payments, disputes and network effects |
| SaaS product | Delivers a repeatable service to multiple customers or tenants | Onboarding, tenant isolation, billing, support and product operations |
| Internal tool | Supports employees or partners in a bounded workflow | Adoption, integrations, permissions, continuity and process ownership |
| MVP | Smallest release that tests one risky assumption with real use | Evidence question, deliberate exclusions, measurement and learning decision |
| Mature platform | Proven multi-role system with continuing operational responsibility | Scale, reliability, security, migrations and compatibility |
Describe the work, not just the label
A web application is interactive browser software. A portal gives a defined audience controlled access. A platform often connects multiple roles, organisations or transactions. SaaS adds a repeatable product and operating model. The labels overlap; user actions and operating responsibility determine the real scope.
A marketing website with a form is not automatically a platform. A small internal dashboard can still demand serious controls when it handles sensitive data, permissions or important decisions.
The scope factors that move the price
The number of critical user flows, roles and permissions, data complexity, integrations, payments, notifications, reporting, accessibility, security and required pre-launch evidence usually create the largest differences.
Decision capacity matters too. A product owner must prioritise, validate rules and content, supply test cases and resolve exceptions. Without that ownership, the target keeps moving regardless of supplier or technology.
- Users and organisations: who can view, change, approve and administer?
- Core flow: which task must work from trigger to final state?
- Data: source, retention, ownership, migration and export
- Integrations: documentation, limits, outages, retries and source of truth
- Operations: hosting, monitoring, support, incidents and future development
Treat privacy and compliance as scope
For each data flow, record its purpose, minimum necessary data, access, retention, deletion and export. Identify the controller, participating suppliers or other processors, and the agreements they require; a generic security line does not replace those decisions.
Assign ownership for access reviews, data-subject requests, incidents and applicable contractual or legal requirements. This is not legal advice: the customer and qualified advisers must confirm the obligations that apply before launch.
An MVP should test one risky assumption
An MVP is not a reduced final product with every menu item represented. Select the smallest release that lets real users complete the critical task and tests the most important product or process assumption.
A prototype, clickable model or technical spike can be the responsible step before an MVP when demand, usability or integration feasibility remains the main uncertainty.
Compare total ownership, not only the build
Ask which costs recur: hosting and databases, messaging, payment providers, API usage, monitoring, security updates, support, incident recovery and continuing development. Confirm who controls accounts, can export data and can hand the system to another supplier.
A low build price can become expensive when testing, documentation, operations or ownership are missing. A higher quotation is not automatically better; compare the same scope, evidence boundary and responsibilities.
Check standard software before commissioning custom work
Prefer a maintained product when configuration, an existing automation feature or a focused integration solves the core problem. Custom software becomes responsible only when the non-standard part is valuable enough to justify development and continuing ownership.
Ask a supplier to show the no-build route as well. The right outcome may be configuration, integration, a smaller internal tool or no project.
Make suppliers quote the same decision boundary
Request a numbered scope covering the core flow, roles, integrations, acceptance criteria, exclusions and change procedure. Identify assumptions that remain open and the evidence needed to close them.
Before work starts, record source-code and licence terms, data export, accounts, hosting, defects, changes, response expectations and exit. OmniTechs prices implementation only after that boundary is sufficiently clear.
Working example: a bounded service flow
The Servana showroom demonstrates a working guest and service flow with input, state and a clear user route. It is useful evidence of interface and workflow thinking, but it is not presented as a public client case, price evidence or proof that every platform capability already exists.
Use it to discuss the critical action in your own scope: who starts, which state changes, who must respond and what the user sees when something fails.
Make the critical platform flow testable first.
Describe the users, the one task that must work, the data and systems involved, and what version one intentionally excludes.