Web Application Development

When the spreadsheet stops coping

Most businesses run something important on a spreadsheet that several people edit, a shared inbox nobody owns, or a database somebody built years ago and then left. It works, until it does not, usually at the point where you want two people doing it at once, or you need to know who changed what.

A web application is what that becomes when it grows up: the same job, with logins, a proper data store, a record of what happened and an interface built for the people who use it every day. If what you actually need is a site that presents information well, that is website design. Plenty of projects turn out to be partly both.

Bespoke applications built around your process, not the other way round
Database design, reporting and data you can actually get back out
Integration with the back-office systems you already run
User accounts, permissions and an audit trail as standard
Browser-based, so there is nothing to install on anybody’s machine
Built in stages, so it earns its keep before it is finished

2008

Developing since

Long-running clients

Direct

People, not a queue

We already know your setup

100%

UK-based team

Local & nationwide

Bespoke

Built to your process

Not a product you bend to fit

We build the software we sell

The clearest evidence of what we do is the site you are reading. It runs on a content management system we designed, wrote and maintain ourselves, and client sites run on it too. That is a fairly demanding application: multi-tenant, editable by non-technical users, and it has to stay up.

It matters here for a practical reason: when we say we will build you something and then keep it running for years, that is a description of what we already do rather than a promise about what we might.

How a build usually goes

It starts with watching the current process, not with a specification. What people actually do is reliably different from what the documented procedure says, and the difference is usually where the real requirements are hiding.

From there we build in stages. The part that hurts most gets built first and put in front of the people who will use it, so it is delivering something before the whole thing is done. That order also means the feedback arrives while changing course is still cheap, which it stops being once everything is built on top of an assumption nobody questioned.

Integration is usually the point

Very few applications stand alone. Most of the value is in connecting to something that already exists: a back-office system, an accounts package, a website, a supplier feed, so that a thing entered once does not have to be entered again somewhere else.

That is a large share of the work we do, and it is the part most likely to be underestimated by whoever quotes on it. We will tell you early if a system you rely on is going to make integration difficult, rather than discovering it halfway through.

What's Included

Everything covered under Web Application Development

From working out what the system actually needs to do, through to running it once it is doing it.

Process and Requirements

Understanding how the work is done now, where it breaks down, and what a system would have to do to be an improvement rather than a different set of problems.

Database Design

A data structure that fits the business, with reporting built on top of it and your information in a form you can query and export.

Integration

Connecting the application to your website, back-office systems and anything else that already holds the same data, so it is entered once.

Accounts and Access

Logins, roles and permissions so people see what they should.

Questions

Web application questions

How is this different from a website?

A website mostly shows people information. An application lets them do something: log in, enter and change records, run a process, get data back out. In practice a lot of projects are partly both, and it does not matter much which word you use when you call.

We already have systems. Will it talk to them?

Usually, and that is often the main reason for building it. It depends on what those systems will let us connect to. Some are straightforward, some are awkward, and a few are genuinely closed. We will tell you which yours is early rather than partway through.

Do we need to have it all worked out first?

No, and it is usually better if you have not. We would rather start by looking at how the work is done now. Detailed specifications written before anyone has watched the process tend to describe the procedure rather than the job.

What happens to our data?

It stays yours, and it stays exportable. We build so that your information can be got back out in a usable form. That is a deliberate design constraint, not an afterthought. An application holding client data also raises questions a brochure site never did, which is what security covers.

Who maintains it afterwards?

We do, if you want us to. An application that people depend on needs patching, monitoring and the occasional change as the business changes, and that is the arrangement most clients settle into.