Web applications & business tools
Web application development
Our web application development covers customer portals, internal tools and the replacement of spreadsheets your operation has outgrown. We build custom web apps that follow your processes as they actually run – with considered roles and permissions, accessible to WCAG 2.2 AA, and documented so your team can carry on without us.
Perspective
When web application development is the right call – and when it is not
Not every problem needs its own software. We settle that before any proposal is written.
A custom web application is the right answer when a process is central to your business and no off-the-shelf product understands it the way you run it. Typical examples are customer portals, where clients check orders, documents or progress for themselves, and internal tools for scheduling, quotes, inspections or approvals. Because everything runs in the browser, there is nothing to install, updates arrive centrally, and APIs connect the application to the systems you already use.
The trigger is often the same: a spreadsheet or Access database that started as a pragmatic fix years ago now carries a significant part of the operation. Several people work in copies of the same file, nobody is sure which version is current, permissions exist only as folder sharing, and knowledge of the macros sits with a single person. Reports are assembled by hand shortly before they are needed – and are out of date again by the next meeting.
The other side matters just as much: for accounting, time tracking, ticketing or a standard CRM, mature products exist that are cheaper and faster to roll out than any bespoke build. A well-kept spreadsheet that does its job does not need replacing at any cost either. If a ready-made product covers most of what you need, we recommend it – and we tell you so in the first call, not after the analysis.
Services
What we build in this field
Web application development with us means custom software shaped around your own workflow – from the first database table to the finished interface.
Customer portals
A secure area where your clients look up orders, documents, invoices or the status of their request themselves. That spares your team follow-up calls and emails, and you decide exactly who sees which data.
Internal tools and business software
Tools for scheduling, quoting, inspections or approvals that follow the way your team works. Forms validate input where it is entered, and every step stays traceable instead of disappearing into email threads.
Replacing spreadsheets and Access databases
We move the logic out of spreadsheets and desktop databases that have grown over years into a clean data model, migrate the existing records and check with you that calculations and results match before the old solution is switched off.
Dashboards and reporting
Figures and overviews built on real operational data rather than exports copied by hand. Filters, time ranges and downloads follow the questions that actually come up in your meetings.
Roles and permissions
A permission model that matches your organisation: departments, sites, external partners and clients see and change only what they should. Important changes are logged, so you can establish later who did what, and when.
Accessible interfaces
Interfaces built to WCAG 2.2 AA: fully usable by keyboard, with sufficient contrast and understandable to screen readers. That helps everyone who works with them daily – and gives you a solid basis where legal accessibility requirements apply to your service.
Approach
How your web application comes together
The same four steps as in every project we run – focused here on what matters for web applications.
Analysis
Over one to two weeks we look at how the work is done today: which spreadsheets, forms and emails are involved, who needs which data, and which systems have to be connected. It ends in a written assessment with a price range.
Plan
In one week we settle the data model, the permission model and the sequence. You learn which part of the application goes live first, which data moves across for it, and how you will know it works.
Delivery
We deliver in short cycles: you see progress every week and work with the real application early instead of mock-ups. A first productive version is typically live after six to twelve weeks, depending on scope. Every change is versioned, tested and documented.
Handover
Source code, credentials, documentation and runbooks are handed over in full. We walk your team through it – the people who will look after the application and the people who use it every day. We keep operating it if you want us to, with monitoring and planned updates.
Example
A typical scenario: from three spreadsheets to one shared application
An assumed case that shows how a project like this can unfold.
Not a client project
Suppose a service company with around 40 staff plans jobs, materials and appointments across three spreadsheets that are passed around by email. Customers call to find out when the technician will arrive and whether their paperwork is complete. The dispatch team knows the answers – but only if the current file happens to be open. The monthly report for management is pieced together by hand each time, just before the meeting.
In the analysis we would typically start by working through the files and the workflow: which columns are master data, which calculations are hidden in formulas, who changes what? From that come a data model and a permission model for dispatch, technicians, management and customers. The first productive version would be deliberately narrow: shared job planning in the browser, with the existing records migrated, so nobody works in copies any more.
Building on that, a customer portal could follow, where customers check appointments and documents themselves, along with a dashboard showing the figures that used to be collected by hand. The spreadsheets would only be retired once both sides had compared the results. How much time this saves in a given case cannot be stated honestly in advance – but it can certainly be measured afterwards.
Technology
Technology your team can take over
For web applications we usually work with TypeScript, React and Next.js, with PostgreSQL as the database. These are widely used, well-documented tools, so you will still find developers for them years from now. Where your organisation already has a standard, we work inside it. Connections to ERP, CRM or line-of-business systems run through documented REST APIs to an OpenAPI specification, or through webhooks.
Sign-in can be tied to an existing company account, for example via OAuth 2.0. The application runs in containers, on servers in the EU or on your own infrastructure, with metrics, logs and alerts in place from day one. We treat accessibility to WCAG 2.2 AA as part of the whole build, not as a check just before launch.
- TypeScript
- React
- Next.js
- PostgreSQL
- OpenAPI
- OAuth 2.0
- Docker
- WCAG 2.2
FAQ
Frequently asked questions about web applications
What people typically ask before deciding on a web application of their own.
How much does web application development cost?
It depends mainly on scope: the number of roles, migrating existing data, integrations with other systems and what reporting you need. Smaller tools start in the four-figure range, from around €1,000. Full web applications typically land in the five figures, larger platforms above that. After the analysis you receive an estimate with a price range.
Can we replace our spreadsheet or Access database step by step?
Yes, and that is usually the better route. We start with the part that causes the most friction, migrate the existing records and only switch the old solution off once the results match. A first productive version is typically live after six to twelve weeks, depending on scope.
Will the application work on phones and tablets?
Yes. A web application runs in the browser and adapts to the screen size – with nothing to install from an app store. For work on the move, such as reporting back from a job site, we design interfaces specifically for small screens. Whether individual features must also work without a connection is something we clarify in the analysis, because it changes the effort noticeably.
How are roles and permissions handled?
We derive the permission model from your organisation: who may view, create, change or approve data – by department, site or client. Permissions are enforced on the server, not merely hidden in the interface. Important changes are logged, and sign-in can be tied to an existing company account.
Can a web application be run in line with the GDPR?
We lay the technical groundwork: data stays on servers in the EU or on your own infrastructure, access follows a documented permission model, and we plan personal data in only where the workflow needs it. The legal assessment stays with your data protection officer or legal counsel – we supply the technical details they need.
More services
What often goes with it
APIs & system integration
Interfaces that connect existing systems cleanly – specified, versioned and documented.
- OpenAPI
- REST
- Webhooks
- OAuth 2.0
AI assistants & LLM integration
Assistants and chatbots that work on your own data and can show where an answer came from.
- LLM
- RAG
- Vector search
- MCP
Process automation
Recurring work that runs without manual steps in between – with explicit failure handling.
- Workflows
- Queues
- Event-driven
- Cron
Thinking about a web application?
Tell us briefly which process currently lives in spreadsheets, email threads or an ageing database. You get an honest assessment – including when off-the-shelf software is the better choice.