Web app development for UK businesses

What we build most often

Four shapes cover nearly everything people ask us for, and they differ mainly in who logs in.

Web app, website or mobile app: a decision table

These three get confused constantly and the wrong choice is expensive, so here is the short version.

Choose a website when the job is being found, read and trusted: marketing pages, content, a contact form. Nobody logs in, and search visibility is the point.

Choose a web app when people log in and do work: viewing their own records, submitting things, managing something over time. It is indexed where you want it to be, shared by a link, updated the moment you ask, has no app store review queue and no store commission on anything you sell.

Choose a mobile app only when you genuinely need reliable push notifications, real offline working, or phone hardware like the camera, sensors or Bluetooth, or when people will open it several times a week so an icon on the home screen earns its place. Otherwise a web app does the same job for less, and you can add the mobile app later once real usage has proved the case.

How the build runs

Discovery first, and it is free. We map who uses the thing, what each of them needs to do, and what data sits underneath. That produces a written scope, a fixed price and a timeline before you commit to anything, plus an honest answer if a smaller version would serve you better.

Then short build cycles with something clickable in your hands from the second or third week, so you are correcting the direction as it goes, instead of reacting to a reveal at the end. Data migration, where you have existing records, runs alongside: mapped, cleaned as it moves, and reconciled against the original before anyone relies on it.

Then launch, and either you run it or we do. A first version is typically six to ten weeks from first conversation to real users, and larger platforms are delivered in phases so something useful is live early, and everything does not arrive at once.

Security, accessibility and the parts that bite later

Anything people log into carries obligations, so these are standard, not an upgrade tier. Access control enforced on the server rather than implied by the interface, which is where most real breaches of small applications begin. Encryption in transit, sensible session handling, an audit log of who changed what, and automated backups with restores that have actually been tested.

Accessibility is built in, not retrofitted: keyboard navigation, screen-reader support, sensible contrast and touch targets big enough to hit. That matters legally if you serve the public sector, and it matters commercially everywhere else, because an application people cannot use generates support calls, not value.

Scaling is deliberately not over-engineered. We build for the users you have plus a realistic year of growth, on infrastructure that scales when it needs to. Architecture for a million users, built for the fifty you have, is the most expensive form of optimism in software, and we would rather spend that money on the product.

Proof: a platform we built and still run

PolicyMind is a web app of exactly this shape. Organisations log in to manage policies through their whole life: drafting with AI assistance, review and approval routing, versioning, staff acknowledgement, and the evidence trail an inspection asks for.

It has the properties that make this work worth paying for: several kinds of user with real differences in what they may see, a data model shaped around a workflow no off-the-shelf product matched, and an audit trail designed for people who will be asked months later to justify a decision. Same team, same stack, still running it.