Have a web application built that genuinely speeds up your work

A website exists to be read; a CMS like WordPress fits that well. A web application exists to work in: logging in, entering data, updating statuses, permissions per role. A native app belongs with use on the move involving camera, location, push notifications or offline work, and means app stores and review processes. A practical test: if your users mainly edit data behind a login, it is a web application. If they have to do that outdoors without a stable connection, an app comes into play; see /app-laten-ontwikkelen. In many cases a web application that works well on mobile is enough, and it keeps a second codebase and store fees out of your budget.

A well-scoped internal web application that replaces an existing process starts around 15,000 to 30,000 euros. A platform with multiple roles, a customer portal and integrations with existing systems sits between 40,000 and 90,000 euros. Within that range three things set the price: the number of screens, how many exceptions your logic contains and how many systems have to join the conversation. Those exceptions are usually the biggest cost driver, because every deviation from the main rule is an extra path that has to be built and tested. We only name a figure after a short discovery; for a first indication the calculator at /calculator is faster.

A first working version of a well-scoped application is usually delivered in 6 to 10 weeks. A broader platform with multiple modules and integrations runs to 3 to 6 months. We work in two-week sprints; after each sprint you log in to a test environment and work with what has been built. Those moments are not a formality: most changes come from someone who does the actual work and sees that a step runs differently in practice than on paper.

Four forms. Internal business tools where orders, inventory, scheduling or time tracking come together with permissions per role. Customer portals where your clients see their own orders, documents and invoices instead of emailing for them. Dashboards that put figures from multiple systems side by side. And workflow or approval systems that lift requests out of the inbox and turn them into an auditable trail. In all four cases the gain rarely sits in a prettier interface, but in double entry and searching disappearing.

We build web applications responsively, so they work in the browser on desktop, tablet and phone without anyone installing anything. For field use we can turn it into a progressive web app: its own icon on the home screen, fast startup and limited operation on a poor connection. A PWA is not enough once you genuinely need to work offline with later synchronisation, need heavy camera features or background location, or depend on reliable push notifications on iOS. In those cases we recommend an app alongside the web application, with the same backend behind it.

Almost always, and it is often exactly why a project pays off. If a system has an API we connect to it; if it does not, we work with imports, exports or an intermediate layer. More important than the technology is the question of which system is the source of truth and what should happen when two systems contradict each other. We make that choice during discovery. How we build, test and monitor integrations is covered in detail at /software-koppelingen.

If your process is not unique, you are better off buying it. For accounting, payroll, email marketing and an informational website there are packages that are better and cheaper than anything we build from scratch; a WordPress site with a good structure is often exactly enough for content. Custom pays off when your way of working is the distinction customers come to you for, when you have to modify a package so heavily that every update becomes a risk, or when you pay per user for something you use ten percent of. If you can get away with a package, we say so in the first conversation.

Doing the maths helps here more than principles. Put the licence cost per user over five years next to a one-off investment plus maintenance, and count the manual work an off-the-shelf product does not remove. A subscription is usually the right choice for a common process, few users or a short horizon. Own software wins with many users, a process that deviates from the norm or an integration the package does not support. If you want to sell software as a service rather than use it, that is a different route; see /webapplicatie-laten-bouwen.

A web application sits on the open internet, so the basics have to be right: encrypted traffic, password policy with two-factor authentication, permissions checked per role on the server and not only in the interface, validation of all input and logging of sensitive actions. On top of that we keep dependencies current, because most incidents are not caused by a creative attacker but by a package that has not been updated for a year. For environments with personal data we host inside the EU and limit in the design who sees which data.

The code is yours and lives in a repository in your own organisation. We set hosting up on your accounts: usually Vercel or a European cloud, depending on where your data is allowed to live and what your customers require. The database belongs with that, including backups and a recovery plan we have actually tested rather than only the promise that backups exist. You can give another party access at any moment without needing anything from us.

Maintenance is not optional but a given: frameworks, browsers and security patches keep moving. We work with a maintenance plan with a fixed number of hours per month for updates, monitoring, small improvements and user questions. Hours left over we spend on further development in consultation with you. It is not mandatory: because code, hosting and documentation are in your name, you can also place maintenance internally or with another party. What we do recommend is reserving annual budget, regardless of who does the work.

Describe in a few lines which process is failing today and who works with it, and send that via /contact. We schedule a half-hour conversation in which we mostly ask questions. Bring what you work with now: the Excel files, a screenshot of the current system or the form where things go wrong. That is more useful than a finished functional specification. After that comes a proposal with scope, a price range and milestones, or honest advice that an existing package helps you faster.