Website Versus Web Application

A website presents information. A web application does work: it holds state, enforces permissions, runs business rules, processes transactions and has to be correct when two people act on the same record at the same time.

That distinction matters commercially because the two are priced, built and maintained differently. Most of the failed projects we are asked to rescue were quoted as websites and turned out to be applications somewhere around week six.

If your requirement includes logins, roles, workflows, approvals, calculations or reporting, you are buying software. We scope it that way from the beginning, which is less pleasant to hear at proposal stage and considerably cheaper by month four.

What We Build

  • Internal tools and operations dashboards
  • Customer and supplier portals
  • Booking, reservation and scheduling systems
  • Quotation, order and approval workflows
  • Reporting and business intelligence interfaces
  • Document management and e-signature flows
  • Membership and subscription platforms
  • Marketplaces and multi-party platforms
  • Progressive web apps that work offline and install to the home screen
  • Admin panels for existing systems that never had a decent one

Architecture and Stack

We choose a stack we can defend in five years rather than one that is currently fashionable. In practice that usually means PHP with Laravel or Node.js on the server, React, Vue or Next.js on the client, PostgreSQL or MySQL for data, Redis for caching and queues, and containerised deployment with automated pipelines.

The decisions that actually determine whether an application survives are less visible: a data model that reflects the business rather than the first screen, permissions enforced on the server rather than hidden in the interface, background jobs for anything slow, and an audit trail on every record that matters. We get those right early because retrofitting them is expensive.

Security Is Not a Phase

Business applications hold exactly the data attackers want: customer records, pricing, contracts, financial history. Security is designed in rather than tested at the end.

That means server-side authorisation on every endpoint, protection against injection and cross-site attacks by construction, rate limiting, secure session handling and two-factor authentication where the data warrants it, encryption in transit and at rest, secrets in a manager rather than in code, and a full audit log. Before launch we run a penetration test, and we would rather find the problem than have your customers find it.

How the Project Runs

We start with process analysis and a written scope for version one, then a clickable prototype of the screens that carry the most complexity, because those are where requirements turn out to be wrong. Development runs in two-week sprints with a working build at the end of each, so you steer rather than wait.

Testing covers automated tests on business logic, load testing where volume matters and a security review. Launch includes data migration, a parallel-run period where relevant, role-based training and documentation. Afterwards you own the code, the infrastructure and the accounts, and we support under an agreed SLA or hand over completely.