Having a custom web application built: a guide for small businesses

Having a custom web application built means you get software that mirrors your actual processes, runs in the browser, and replaces the spreadsheets, duplicate entries and workarounds your team relies on today. It pays off when a recurring process costs time every week and no off-the-shelf product covers it without contortions. For everything else, standard software is faster and cheaper. This guide shows how to tell the difference, which factors move the price, how a project runs, and which obligations apply to data protection and AI features.

When is it worth having a custom web application built?

A custom web application is worth it when a recurring process costs measurable time and no standard product covers it without extra work. The test is not the technology but the frequency: a task that happens ten times a day and creates three minutes of rework each time costs more per year than the application replacing it.

Three signals point towards your own application in practice. First, the spreadsheet that has quietly become business software and that only one person in the company can maintain. Second, the duplicate entry, because two systems do not talk to each other and somebody copies data by hand. Third, customer contact that fails because of your software: appointments arranged by email ping-pong, status questions by phone, quotes left sitting in mailboxes.

Work out the cost of today's process before you ask for a quote. For one week, note how often the task occurs, how many minutes it takes, and how often it has to be repeated because information was missing. Multiply that across a year and compare the total with the development effort. This calculation is the most factual part of the decision, and it protects you in both directions: it shows when building your own pays back within months, and it shows just as clearly when a process happens too rarely to deserve its own application.

The opposite matters just as much. If your process matches the industry standard, if accounting, payroll or inventory management is the subject, or if you cannot yet say which function is needed first, then building your own is the expensive answer to a question nobody asked. We say so openly before a quote exists – and then point to standard products or to ready-made web apps from our range, which start without a development project.

Custom software or standard software – which fits your company?

Standard software fits as long as your process resembles the standard; a custom web application fits as soon as the process itself sets your offering apart. A useful split is between differentiating and administrative processes: what customers value about you deserves its own software, what looks the same in every company is bought in.

Situation in the company	Standard software	Custom web application
Accounting, payroll, tax matters	First choice, including updates when the law changes	Rarely sensible
Process with its own rules, deadlines and approvals	Only possible with makeshift solutions	First choice
Several systems need to work together	Depends on the interfaces that exist	Interfaces are part of the project
Customers should handle something themselves	Often only available as a rigid portal	Portal built around your process and your roles
Requirements still unclear	Inexpensive entry point for learning	Only after a phase with real data

A look at how widely software is used helps with the classification. According to the German Federal Statistical Office, around 54% of companies with at least ten employees used paid cloud services in 2025, most often for email and file storage; cloud-based ERP and CRM software, by contrast, reached only 23% each. Basic supply therefore comes out of the box, while the processes close to day-to-day operations remain the gap a custom application fills.

What does a custom web application cost?

A custom web application at ZeuZ IT starts at €2,500, and the fixed price for each stage is agreed in writing before work begins. That budgets in the German SME sector are calculated tightly is clear from the KfW Digitalisation Report 2025: digitalisation spending by small and medium-sized companies fell to just under €24 billion, and only 30% of them carried out digitalisation projects at all. That makes it all the more important for the first step to be small and the price to be known in advance.

Which factors actually move the price can be clarified in advance – and that is exactly where it is decided whether a project stays within budget.

Cost driver	Why it moves web application costs	What you can settle in advance
Number of user roles	Every role brings its own views, permissions and checks	Start with two roles, add more later
Interfaces to existing systems	External data formats and edge cases cost development and testing time	Build only the interface used daily
Data migration from legacy systems	Historical records are incomplete and have to be cleaned up	Set a cut-off date, archive old data read-only
Real-time and notification features	Delivery, retries and logs create additional effort	Begin with a daily summary
Operation and further development	Hosting, security updates and changes continue permanently	Show operating effort separately in the quote

It is also worth comparing against the website alternative: a company website is calculated differently, in both build and upkeep, than an application with sign-in and stored data. How website costs are made up is broken down in our guide to website costs for small businesses; the packages for design and support are listed under prices and scope of services.

Which processes do small and medium-sized companies automate with a web application?

Processes can be automated wherever information is passed on by hand today: appointments, approvals, deadlines, status reports and documents. The benefit does not come from the automation itself, but from the fact that nobody has to ask where a case stands any more.

• Booking and appointment systems that handle availability, confirmations and reminders without a phone call.
• Administration and document systems, for example contract management that warns before deadlines expire.
• Customer portals in which clients view progress, files and invoices themselves.
• Internal tools that connect two systems and put an end to duplicate entry.
• Multi-tenant platforms that let you provide the same application to several clients separately.
• Ticketing and support systems, plus dashboards that bring key figures from several sources together on one screen.

Examples from our work include a booking system for appointment-based businesses, contract management with deadline alerts, and a platform for finance advisers with separate tenants. Once text, documents or enquiries also need to be evaluated, the topic borders on AI automation for recurring tasks; the role models play in the development work itself is described in our article on AI in web development.

Measure the effect after go-live against two or three figures you defined beforehand: the time from enquiry to answer, the number of follow-up questions per case, or the share of appointments customers book themselves. Without those baseline values, every assessment stays a matter of taste, and the next stage gets planned by volume of complaints rather than by benefit. With them, the application becomes a tool whose further development can be justified – including to a management team that has to account for every additional step.

What is a web application – and what technology sits behind it?

A web application is software that runs in the browser and is operated on a server; “web app” means the same thing. It consists of three parts: the interface in the browser, the application logic on the server, and the database. Nothing is installed; the application is reachable through an address, on computers, tablets and smartphones.

At ZeuZ IT these parts are built with React for the interface, Node.js for the logic, PostgreSQL or MongoDB for the data, and deployment in the cloud. The choice follows the task, not fashion: an application with a clear table structure and reporting is better served by a relational database, an application with widely differing documents by a document-oriented one. Both routes are proven, and both can be extended later, provided the data model was cut cleanly at the start.

Four technical building blocks are almost the same in every project, and they determine how well the application feels in daily use. Sign-in with roles and permissions defines who may see and change what. Interfaces connect the application to existing systems so that no island is created. Notifications bring deadlines and approvals to the people they concern. And logs make it traceable who changed which record and when – which during complaints and audits often matters more than any extra feature.

For operation, reliability counts above all: a monitored environment, security updates that are actually applied, tested backups, and a clear route for reporting and fixing errors. These points belong in the quote, not in a later conversation, because they make up the permanent part of the cost.

How does a project run when you have a web application built?

A project runs in four stages, and each stage ends with a result you can review yourself. The order is deliberately chosen so that the expensive decisions are made while they are still cheap to change.

1. Gathering requirements: processes, user roles and interfaces are recorded, and it is defined what the first version has to deliver – and what it explicitly does not.
2. Concept and fixed price: data model, interface and architecture are settled, and you receive a written quote with a fixed price for the agreed stage.
3. Development in steps: you test working intermediate versions with real cases from your company, instead of seeing a finished product for the first time at the end.
4. Go-live and further development: the application goes into operation, and actual use then decides which functions come next.

Two things decide how a project goes. First, a responsible contact on your side who settles questions within days – without one, every stage takes longer. Second, real test data: an application checked only with invented examples reveals its gaps only in everyday use. How we scope projects and which applications have come out of them is shown in our completed projects.

What do you need to watch regarding data protection, operation and AI features?

Data protection belongs in the planning, not in the acceptance test. If a service provider processes personal data on your behalf – for hosting, maintenance or troubleshooting – a data processing agreement under Article 28 of the General Data Protection Regulation is required; paragraph 3 lists what it has to cover. Also settle the server location, the retention periods, and the question of who in the company may see which data. Roles and permissions are not an add-on but part of the data model.

AI features have had their own framework since 2024. Regulation (EU) 2024/1689 – the AI Act – requires in Article 50, among other things, that people can tell when they are interacting with an AI system; these transparency obligations apply from 2 August 2026. In practice that means an assistant in the customer portal states what it is, suggestions stay traceable, and a decision with consequences for people remains with a person. Answer these points in the concept and no retrofit is needed later.

The third point is operation. Settle in writing before work begins who owns the source code, where the application runs, how security updates are applied, and how often backups are created and restored. A backup that has never been restored is an assumption, not a backup.

Which mistakes drive up development costs most often?

Projects rarely become expensive because of technology, but because of decisions that are too big too early. Four patterns show up particularly often, and all four can be avoided beforehand.

• Everything at once: a scope that covers every special case from the past ten years delays the benefit by months and raises the price before a single line runs in production.
• Digitising instead of cleaning up: a convoluted process does not get better through software, only faster at being convoluted. Before development comes the question of which steps can go.
• Nobody maintains the data: without clear responsibility for master records, the new application ends up as messy as the old spreadsheet.
• Operation not budgeted: if no budget for changes is set aside after go-live, the application freezes in its first-day state and gets replaced within two years.

If you are unsure which stage makes sense first, it is worth looking at our services for custom web applications and portals – you will find the typical application types there, with scope, duration and entry price.

Custom web applications mit ZeuZ IT

We record your processes, scope a first version around the functions with the greatest benefit, and build it for a fixed price – from the database to the interface, with roles, interfaces and operation. If a project does not justify the effort because a standard product is enough, we say so openly in the initial consultation and propose the cheaper route. Tell us the one process that costs your team the most time – we will reply with an assessment and a fixed price.