Skip to content

Web application development

A website tells people about your business. A web application does work for it: takes bookings, tracks jobs, manages stock, replaces the spreadsheet three people are emailing back and forth. The difference matters because the second one has to be right rather than merely look right.

Web apps

The expensive part is deciding what it should do

Most failed software projects did not fail in the code. They failed because nobody wrote down precisely what the thing was supposed to do, so it was discovered during the build, changed three times, and delivered late as something nobody quite wanted. Writing the specification first is unglamorous and it is where the money is saved.

So we start with the actual process — who does what, in what order, and where it currently goes wrong. That produces a written specification you approve before anything is built. It also frequently produces a smaller project than expected, because a good half of what people ask software to do turns out to be a workaround for something that could simply stop happening.

What you receive

Written down, not assumed

Everything below is part of the service rather than an upgrade, and each item is something you can hold us to.

  • A written specification you approved before the build
  • The working application, deployed and accessible
  • Secure login with roles and permissions
  • An admin interface for day-to-day changes
  • Source code and accounts in your name
  • Written handover covering hosting, support and how to request changes

Why it matters

The expensive part is deciding what it should do

Most failed software projects did not fail in the code. They failed because nobody wrote down precisely what the thing was supposed to do, so it was discovered during the build, changed three times, and delivered late as something nobody quite wanted. Writing the specification first is unglamorous and it is where the money is saved.

So we start with the actual process — who does what, in what order, and where it currently goes wrong. That produces a written specification you approve before anything is built. It also frequently produces a smaller project than expected, because a good half of what people ask software to do turns out to be a workaround for something that could simply stop happening.

What's included

What web app development covers

Specification before code

A written spec covering screens, roles, rules and edge cases, agreed with you first. Changes after that are priced, not absorbed silently.

Secure authentication and roles

Proper login, password handling and permissions, so the right people see the right things. Not an afterthought bolted on at the end.

Database design

A schema that reflects how your business actually works, so reports are possible later without restructuring everything.

Third-party integrations

Payments, email, accounting, calendars and whatever else the process already depends on — connected rather than re-keyed by hand.

Admin interface

A back office you can actually operate, so day-to-day changes do not require a developer and a support ticket.

Testing and handover

Tested against the specification, with a written handover covering how it runs, where it is hosted and how to get support.

How it runs

Four stages, agreed as we go

  1. Process mapping

    We map how the work happens today, including the parts done in spreadsheets and WhatsApp, because that is usually where the requirement really lives.

  2. Written specification

    Screens, user roles, business rules and what happens when something goes wrong. You approve it before a line is written.

  3. Build in stages

    Delivered in working slices on a preview link, so you are using something real early rather than waiting months for a reveal.

  4. Launch and support

    Data migrated, users set up, and an agreed support arrangement. Nothing goes live on a Friday afternoon.

Deliverables

What you actually receive

Set out here so there is no ambiguity later about what was included in the price.

  • A written specification you approved before the build
  • The working application, deployed and accessible
  • Secure login with roles and permissions
  • An admin interface for day-to-day changes
  • Source code and accounts in your name
  • Written handover covering hosting, support and how to request changes

Questions

Web App Development: common questions

How much does a web application cost?

Far more variably than a website, because the range is enormous — a single-purpose internal tool and a customer-facing platform are not comparable. The specification stage exists partly to answer this: once the scope is written down, the number is real rather than a guess. We would rather quote a specification than quote a hunch.

Do I own the code?

Ownership is set out in the written proposal for your project, and accounts, hosting and data are in your name from day one. Ask about the code before you commission the work rather than after — it is a reasonable question and any honest developer will answer it plainly.

Can you take over an existing application?

Sometimes. It depends entirely on how it was built and what state the code and the documentation are in. We will look at it honestly and tell you whether taking it on, rebuilding it, or leaving it alone is the sensible option — including when the answer costs us the work.

What happens when it breaks?

Agree the support arrangement before launch, not during the first incident. We set out what is covered, what response looks like, and what falls outside it, so nobody is negotiating while something is down.

Thinking about web app development?

Tell us what you are working with and what you need it to do. You will get a straight answer and a fixed written price.