Web application development

A web application is software that runs in the browser and does a specific job for a company: it takes orders, manages documents, tracks processes or serves customers. It differs from a website in that a website informs, while an application does work: it has user roles, data logic and actions that change the state of the business.

When a custom application pays off

An off-the-shelf tool is a cheaper start and in many cases the right choice. A custom system starts to pay off once at least one of these signs appears:

• The process is your competitive advantage, and ready-made software forces you to simplify it.
• The same data is entered into several systems because they do not talk to each other.
• Licence costs grow with headcount, even though you use a fraction of the features.
• You need integrations the platform does not allow or charges extra for.
• Data has to stay on your own infrastructure because of regulations or contracts.

What we typically build

• Order and job management: from enquiry to invoice in one place.
• Document workflows: drafting, approval and electronic signing.
• Self-service portals: for customers or partners, with separate permissions.
• Internal registers and logs: attendance, resources, schedules.
• Management reporting: real-time metrics instead of month-end summaries.

Technology

On the server side we use Laravel (PHP), for the interface Vue or Livewire, and for data MySQL or PostgreSQL. It is a mature, widely used stack: finding another maintainer will not be a problem, and security updates are released regularly.

We choose the architecture to fit the project, not the other way round. If a monolith is enough, we build a monolith; if the system has to serve several interfaces, we separate out an API.

Process and maintenance

We start with a paid discovery phase that ends with a defined scope, an architecture decision and an estimate. Then come a clickable prototype, development in two-week sprints, testing, and launch with user training. After launch the system is covered by SLA maintenance with an agreed response time. More about our process.

If the system needs to talk to the software you already run, see integrations and automation.

A web application or an off-the-shelf tool

A custom web application is not always the right answer. If the process is standard and an off-the-shelf tool covers it without major compromises, it is cheaper and faster to adapt that tool. Building your own system makes sense when at least one of these is true:

• the process is your competitive advantage and cannot adapt to someone else's logic;
• you keep several spreadsheets next to the tool because part of the work does not fit in it;
• you need integrations with accounting, registers or internal systems that the tool does not offer;
• per-user licences cost more over a few years than a system of your own.

We assess this together during discovery. If it turns out an off-the-shelf tool is enough, we say so: the discovery output is yours and works for any decision.

How long it takes

A web application is built in stages, so you can start using the first version well before everything you plan is finished.

• Discovery - 2-4 weeks, ending with a scope and an estimate.
• Prototype - 1-2 weeks for the main scenarios.
• Development - in two-week sprints; a first working version usually within 2-4 months.
• Launch - 1-2 weeks including data migration and training.

Every stage ends with a result you can assess before moving on. More on this on our process page.

Public sector

Public institutions usually need a web application for applications, registers or e-services. In such a project the procedure matters as much as the features.

• A technical specification for the tender, based on the discovery results.
• WCAG 2.1 AA accessibility checks during testing.
• GDPR requirements and data retention rules from the start of the project.
• SLA-based support with an agreed response time and a monthly report.

How we work with public institutions is described on the public sector solutions page.

What drives the cost

• How many processes and user roles the system has to serve.
• Integrations with accounting, registers, payments and other systems.
• Security, audit and accessibility requirements.
• Migrating data from existing systems and spreadsheets.

A first version usually covers one core process and one integration; the rest is built in sprints based on how the system is used. We cover market data and how to calculate the total cost of ownership in our article on custom software development cost.