Web applications your team can live inside all day

The difference between a website and a web application

A website presents information. A web application does work. That distinction sounds academic until you are pricing one, at which point it becomes the single most important thing to establish. A website can be finished. An application is a piece of business machinery that will keep changing for as long as the business does, and it needs to be built with that in mind from the first day.

The applications we are asked for usually start with the same story. A process is currently held together by a spreadsheet that several people edit, an email chain, a shared folder and somebody memory. It worked when the company was smaller. Now records go missing, two people make conflicting changes, nobody can answer simple questions about volume or status, and the person who understands the whole thing is on holiday.

Replacing that with software means far more than putting the spreadsheet online. It means deciding who is allowed to see and change what, what must be recorded when something changes, which rules are enforced by the system and which remain human judgement, what happens when two people act at once, and how the information you need for decisions gets summarised without somebody spending Friday afternoon building a report by hand.

We handle all of that as part of the specification stage, before any code is written. The document that comes out of it describes every screen, every role, every rule and every report in plain language, and it becomes both your approval point and our definition of finished.

Accounts, roles and permissions

Almost every application we build has several kinds of user, and the differences between them matter enormously. A supervisor can approve. An operator can record but not delete. A finance user can see costs that others cannot. An external partner can see only their own records. Getting this wrong is not a cosmetic problem, because showing one customer another customer information can cost more than the entire project.

Our permission checks are enforced on the server, not merely hidden in the interface. Hiding a button does not stop somebody who knows the address of the page behind it, and we have taken over more than one system where that was the only protection in place. We also record who changed what and when, because the first question after any dispute is always who did this, and an application that cannot answer it creates arguments instead of settling them.

Designing for the person who uses it constantly

The buyer of a business application and the daily user are usually different people, and their priorities conflict. The buyer wants a dashboard that looks impressive in a board meeting. The user wants to complete the same task two hundred times a day without their wrist hurting. We design for the user, because their experience decides whether the data going into the system is accurate, and inaccurate data makes the dashboard worthless anyway.

In practice that means the most frequent task gets the fewest clicks. Fields that can be filled automatically are filled automatically. The keyboard works without reaching for the mouse. Errors are caught as they happen rather than after a long form is submitted. Lists remember the filter you were using. Nothing here is glamorous, and all of it is the difference between software that gets adopted and software that gets circumvented.

Reporting that answers real questions

Reporting is where many applications quietly fail. Data goes in reliably for a year, then management asks a question the system cannot answer because nobody thought about it during design. Fixing that later can mean restructuring tables and reprocessing history, which is expensive.

We ask about the questions early. What will you want to know weekly? What does the board ask for annually? What would you check if something looked wrong? Which numbers must reconcile with your accounts? Those answers shape the data model so that reports are simply a matter of querying properly rather than reconstructing information that was never captured.

Where reports are heavy, they are generated by background workers rather than made to run while somebody stares at a loading screen, and the result is delivered as a download or an email when it is ready. That single pattern keeps large applications feeling fast no matter how much data accumulates.

Built to survive the third year

Applications rarely fail on launch day. They fail in the third year, when the table has ten times more rows than anyone anticipated, when a new requirement does not fit the original shape of the data, or when the framework version reaches the end of its support and upgrading turns out to be a rebuild.

We plan for those moments deliberately. Indexes are chosen from the queries the system will actually run. Fields likely to need history are given history from the start. Anything that might later belong to more than one parent is modelled that way immediately. Dependencies are pinned so deployments are repeatable, and framework upgrades are scheduled as small pieces of work well before support ends. None of this is visible in a demonstration, and all of it decides what year three costs you.