Web application development for custom business processes

A website presents content, while in a web application the user does work: logging in, recording data, booking, approving or creating reports. Behind a web application there is therefore always a database, permission handling and business logic.

If the system will be used on both desktop and phone, and you don't need deep device features, a web application gets there faster and more cheaply. A store app is needed when users look for it in the App Store or Google Play, or when you need Bluetooth, background location and similar features.

A PWA is a web application that can be installed on the phone's home screen, runs full screen, works offline and can send push notifications. From the outside, it is barely distinguishable from an installed app.

For internal company use it is almost always enough, because there is no store approval and updates take effect for everyone immediately. It falls short when the goal is reaching consumers through the app stores, or when deep device features are needed.

If ready-made software exists that covers the process, it is almost always cheaper, and we say so. Custom development is justified where the way you work differs from the template, where several systems need connecting, or where monthly SaaS subscriptions and per-user fees cost more over the years than a system of your own.

A mixed solution is common too: the ready-made software stays, and a smaller custom interface is built alongside it for the part it can't handle.

Making an existing website installable (a PWA conversion) starts from €700 + VAT, a custom PWA web application from €1,900 + VAT, and one with its own back end and integrations from €3,900 + VAT. The price of a custom business management system or customer portal depends on the size of the user roles, integrations and data migration involved, so we give a detailed, written quote for this after an assessment.

A PWA conversion takes roughly a week, a custom PWA is typically ready in 2 to 5 weeks. For a custom business management system or customer portal, we give a concrete schedule after the assessment, and development proceeds in stages, so the first usable version is ready well before the complete system.

Because the price of a web application isn't set by the number of screens, but by the rules: who can see what, what happens on approval, what should happen with exceptions. This isn't fully clear yet in the first conversation.

That's why we work in two steps: first a short, fixed-price assessment produces a process description and a data model, and from that a detailed, firm quote can be given. The assessment result is yours: you can even hand it to another developer.

Yes, and in most cases we recommend it. The first version contains the few features without which the work can't happen, and it goes into live use straight away. This way, it becomes clear sooner what is genuinely missing, and you don't pay for features that no one ends up using.

The further stages follow with a separate quote and schedule, so the cost is spread out too.

In PWA form, yes: the device stores the recorded data and uploads it to the server once the connection returns. We plan this at the assessment stage, because how to handle conflicting changes needs to be decided in advance.

Yes, if the other system has an API or an exportable data source. Connecting invoicing software, ERP, payment gateway, courier service and webshop eliminates double data entry.

A typical company system (from a few dozen up to a few hundred concurrent users) runs comfortably on a single, well-tuned VPS. The limit typically isn't the number of users, but the heavier operations, such as large reports and bulk exports.

If load grows, the server can be upgraded first, then the database and the web layer can be separated. We design the data model from the start so that this doesn't mean a rewrite later.

Yes, the interface is responsive, and the same system runs on every screen size. The screens used for field work (surveys, worksheets, stock counts) are designed specifically for the phone: large buttons, minimal typing, photo and location data with a single tap.

Both are yours. The handover includes the source code, the database and the documentation, and you can request a full data export at any time. We don't tie the system to a closed platform of our own, so another developer can take it over later too.

The security fundamentals aren't a separate line item: prepared database queries, permission checks on every action, encrypted connections, password storage with a modern method, and logging of who changed what.

For GDPR, we also think through what personal data enters the system, who can access it and how long it is kept. We build in support for deletion and data-export requests too, because adding it later costs more.

We move it across. The migration starts from your actual files: we check what's usable, what's duplicated and what's incomplete, then load it into the new data model, cleaned up.

The first load always goes into a test environment, and you check that the numbers add up. The old spreadsheets remain as a readable copy even after go-live.

The system runs on a dedicated VPS with monitoring and regular backups, and we handle the hosting too. This starts in the region of €150 a month + VAT, depending on the size of the system and the response time agreed.

Operation includes security updates, checking the backups and fixing bugs. You can also run it on your own server if you have a team for it.

That's fine, and we prepare for it: the code is documented, the system runs on standard foundations (PHP, MariaDB, Redis), and we hand over access with a handover record. We don't use closed solutions that would lock anyone else out of continuing the work.

There are two routes: a one-off development with a detailed quote, or a monthly development allowance if new requirements come up regularly. The advantage of the allowance is that you don't need to ask for a quote for every small thing, and the cost is predictable.

Incoming requests are tracked on a shared list, so it's clear what's being worked on and what's next in line.