Outcomes, Not Disciplines
Named problems, running systems.
Services describe the crafts we practise. Solutions describe what ends up in production — the thing your team opens on Monday morning. Here are the shapes we are asked for, and how we work out which one a problem actually needs.
Solution Set
Nine outcomes, delivered whole.
Each one covers strategy, design, engineering and the running system afterwards. Rarely all nine at once — usually one, or two that share a single data model.
-
Business Software
The line-of-business system that runs your company and exists nowhere else — quoting, scheduling, approvals, compliance. Often the work a spreadsheet has been holding together for years.
-
ERP
One operational core across finance, inventory, procurement and production, configured to your process, migrated with records people trust, and rolled out department by department, not in a single weekend.
-
CRM
Pipeline, accounts and service history on one record, with fields your salespeople will actually complete. Wired to billing and support so a customer stops being three disagreeing versions of the truth.
-
AI Automation
Judgement-heavy steps handled by an agent with retrieval, tool access and a review path — triage, extraction, drafting, reconciliation — running inside the system that owns the work, not in a separate chat window.
-
SaaS Platforms
A product other companies pay to use: sign-up, tenancy, plans, permissions, metering and the admin console your own staff need. Versioned and observable before the first paying tenant arrives.
-
Dashboards & Analytics
One place where the numbers agree. Modelled metrics with their definitions written down, a refresh schedule you can see, and drill-downs that end at a row somebody can check.
-
Customer & Partner Portals
A front door for the people outside your organisation — clients, suppliers, franchisees, applicants. Scoped accounts, document exchange and a status they can read without emailing someone on your team.
-
E-commerce
Catalogue, checkout and the operations behind them: pricing rules, stock, tax, fulfilment and returns connected back to whichever system is already the master record. A promotion becomes a content change, not an engineering ticket.
-
Systems Integration
The layer between the systems you are keeping. Contracts, queues, retries and reconciliation, so an order or an invoice arrives once, in the right shape, with somewhere to look when it does not.
Choosing The Shape
The cheapest system is the one you don't build.
We argue against writing code more often than an engineering company is supposed to. Requirements get separated before anything is estimated, and only some of them earn a custom build.
- 01
Buy where the problem is solved
Payroll, accounting, identity, helpdesk. Mature categories with no strategic upside in owning the source. We will name the product, configure it properly, and move on.
- 02
Build where the process is yours
The steps that make you different — how you price, route, approve or manufacture. No vendor models that faithfully, and bending one until it fits costs more than writing it.
- 03
Integrate what remains
The value tends to sit at the seams: getting a record out of the bought system and into the built one without a person retyping it at eight in the morning.
- 04
Cut the scope at first usefulness
We draw the line where the work starts earning — one workflow, end to end, with real users on it — and sequence the rest as a roadmap instead of a phase two that never arrives.
Brief To Running System
How a solution gets from words to work.
- Step 01
Frame
Your brief comes back as a written restatement: the outcome, the limits around it, and which existing systems get a vote. Nothing is estimated until you agree it is right.
- Step 02
Decide
Each requirement gets a verdict — buy, build, or wire between the two — and the reasoning is recorded, so the call can be revisited later without arguing it from memory.
- Step 03
Prove
The riskiest assumption is tested first: the API that may not expose what we need, the accuracy a model has to reach, the migration nobody has attempted yet.
- Step 04
Deliver
One workflow at a time into a real environment, with your people using it while the next is being built. Feedback arrives while acting on it is still cheap.
- Step 05
Operate
Monitoring, a support route and a change process, plus the runbooks and credentials to run it without us. Keep us on, take it in-house, or split the work — all three are fine.
Tell us the outcome, not the feature list.
Describe what should be true when the work is finished — who does what, where the record lives, what stops being manual. We will come back with what we would build and what we would buy instead.