Web applications people use for eight hours a day.

Not a website. The interface an operation runs on, built for the person who did not choose it and cannot close the tab.

  1. 01Who uses it
  2. 02What it must not do
  3. 03How it is built
  4. 04What it costs to change

In productionGuru ERP and Guru POS are web applications in daily operational use in four countries, and both are open to inspect on the public demo tenant.

What goes wrong with operational web applications

Almost never the framework. Almost always one of these four.

  • Built for the demo, not the shift

    It shows beautifully with eleven records and falls over at four thousand, which is the number the customer actually has.

  • The screen and the database disagree

    Two people edited the same record and the last write won silently. Nobody finds out until a number is wrong.

  • Permissions bolted on afterwards

    Roles were added once the first customer asked. Now every new screen is a security question nobody can answer quickly.

  • Slow in the one place that matters

    The dashboard loads fast and the screen the shift supervisor opens two hundred times a day does not.

The parts that decide whether it holds up

These are the sections the structural plan lists individually. They are one build.

  1. Frontend engineering

    Component boundaries that match the data, not the mockup. Every state designed, including the four nobody demos.

  2. Backend engineering

    The rules live on the server. A validation that only exists in the browser is a suggestion.

  3. API development

    One contract, versioned, documented, and stable enough that the mobile client and the web client can disagree about when to upgrade.

  4. Database architecture

    Constraints and indexes chosen against the queries the application actually makes, measured rather than guessed.

  5. Authentication and access

    Sessions, roles and permissions modelled against roles that exist in the business, enforced server side on every path.

  6. Integrations

    Designed for the third party being down, slow, or returning something it has never returned before.

  7. Performance

    Core Web Vitals on the public surfaces, and time-to-interactive on the screen somebody opens two hundred times a day.

  8. Accessibility

    Keyboard paths, focus order and contrast checked against the standard rather than against an opinion.

What we build

Every platform we own is one of these, which is why the list is short and specific.

  • Operational dashboards

    A live picture of what is where, what is moving and what happens next, correct while the work goes on.

  • Transactional interfaces

    Tills, order entry, dispatch. Screens where a mistake costs money and the interface has to make the mistake hard.

  • Multi tenant back offices

    One codebase, many customers, and configuration rather than a fork per client.

  • Customer portals

    The resident, the buyer or the client seeing the same record the operator does.

  • Design systems

    A component library with the states designed, not just the happy path. Empty, loading, partial, failed, denied.

  • Public sites that have to be fast

    Server rendered and statically exported where it fits, because a page that needs JavaScript to say what it is does not exist for half the crawlers that matter.

OutcomeAn interface the people who have to use it stop noticing.
CapabilitiesWeb application engineering · Design systems and component libraries · API design and integration · Role based access control · Real time interfaces · Accessibility and performance

What we build it on.

Grouped by what it does rather than shown as a wall of marks, and short enough that your own team can judge whether they could take it over.

Frontend
ReactTypeScriptNext.jsDesign systems
Backend
PythonDjangoFastAPINode.js
Data
PostgreSQLMySQLRedisData modelling
Cloud
AWSDockerCI/CDInfrastructure as code

Questions we get asked.

The objections specific to this line, answered here rather than in a first call.

Can we see a web application you built, running?

Yes. Guru ERP and Guru POS run in a public demo tenant seeded with generated data, and the credentials are printed on the product pages. It resets overnight, so you can change anything in it.

Which frontend framework do you use?

React with TypeScript by default, and we will use yours if you have one and a team who maintains it. The framework is close to the least consequential decision on an operational application; the data model and the access model are the ones that are expensive to get wrong.

Do you redesign an existing application or rebuild it?

Whichever costs less over three years, and we will tell you which we think it is before you commit. A rebuild that is really a redesign is the most common way an application budget disappears.

Where to go next

You do not need to arrive with a perfect technical specification.

Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.

Start your build