Skip to main content
Engineering

Engineering built around
the requirement.

The same requirement can be built several different ways, and most of them will work. The one worth choosing is decided by what the product has to do, what already exists around it, and who has to keep it running afterwards. We settle that first. The stack is what is left.

Architecture Before Stack

Nothing on this page is a starting point.

A stack chosen before the requirement is understood is a guess wearing a technical vocabulary. These are the things that actually decide it — and none of them is a language.

  • The Product

    What users and teams actually have to accomplish, and how often they have to do it.

  • The Existing System

    What is already running, and whether it should be extended, connected to or replaced.

  • The Data & Integrations

    What has to be read, written, exchanged and kept in step with everything else.

  • The Operating Model

    Who maintains and extends this once it is handed over, and what they already know.

  • The Release Context

    Where it has to run, and how often it can safely be changed.

Only when those are settled does the stack get chosen — and by then the shortlist is usually short.

Three Engineering Families

Grouped by the job, not by popularity.

Ten technologies, organised by the part of a system they serve. A family is a working context, not a ranking, and nothing here is interchangeable with everything beside it.

Interface & Application

The layer people actually touch, and the runtime behind it. These occupy different positions in one ecosystem rather than competing for the same job — a language, an interface library, an application framework and a server runtime.

Services & Integration

Server-side systems: the APIs, processing and integration work sitting behind an interface. They overlap in what they can do and differ in what they suit, so the choice usually comes down to the surrounding system and who maintains it.

Enterprise & Systems

Long-lived applications and the systems already running inside an organization. Work here is more often modernization than a blank page — extending, integrating or migrating something that has been in service for years.

How The Decision Gets Made

Four phases.
The stack is chosen in the second.

  1. Phase 1

    Requirement & Existing-System Context

    We establish what the system has to do and what already surrounds it — the systems it must work with, the constraints it inherits, the people who will run it — before any technical option is on the table.

  2. Phase 2

    Architecture & Technology Fit

    The architecture is decided first: how the system is structured, where data lives, what it integrates with. Technology is selected to fit that, and the reasoning is written down — including what we ruled out.

  3. Phase 3

    Engineering & Integration

    The system is built against that architecture, with the connections into what you already run wired in as the work proceeds rather than attempted at the end.

  4. Phase 4

    Verification & Evolution

    Testing against real conditions, then a controlled release. What follows is planned as part of the work, because software is a version history and the second version is where most of the value arrives.

Where This Sits

The system is the job. The stack is how it gets built.

Web Application Development is the engagement — the browser-based system, scoped around the process it has to run. Engineering is how that system's implementation gets decided. If the open question is whether you need software at all, start there instead.

Web Application Development

On AI & Automation

AI and automation work meets engineering only at implementation. Which processes to automate, and whether AI belongs in them at all, is decided in that capability — not by the language it eventually gets built in.

AI & Automation
Technology Fit

Capable is not the same as correct.

A technology can be entirely capable and still be the wrong fit. Capability is rarely the constraint — maintenance, integration and the team inheriting it usually are. Every technology page in this section says where it fits and, just as plainly, where it does not.

Questions

Before you ask.

Where To Start

Before choosing the stack,
define the requirement.

Start with a conversation about what the system actually has to do. The architecture follows from that, and the technology follows the architecture.

Start a Conversation →Get the Growth Blueprint