01 / 06
Discovery and scoping
A short, structured pass to establish what the product has to do, who has to use it, and which constraints are real. The output is a scope you can argue with, not a document nobody reads.
SERVICE · PRODUCT
Product Engineering
We take a product from an idea somebody can describe to a system somebody can operate. That means deciding what not to build, choosing an architecture that matches the size of the problem rather than the size of the ambition, and writing the code so the next engineer can change it without archaeology.
THE PROBLEM
Most products do not fail at launch. They fail at the second year.
The first version of almost anything can be built quickly, and usually is. What goes wrong is what comes after: the shortcuts taken to hit a demo date become the structure of the system, the decisions nobody wrote down stop being remembered, and each new feature costs more than the last one because it has to be threaded through code that was never meant to carry it. By the time this is obvious, the people who could explain the original reasoning have moved on. We build for the point where the team changes, not the point where the demo lands, because that is where most of a product's cost actually accumulates.
Signals you might recognize
You have a prototype nobody is willing to put in front of a paying customer.
Every new feature takes measurably longer than the last one did, and nobody can say exactly why.
The person who understood how the system fits together left eight months ago.
There is no environment where you can test a change without risking real data.
WHAT WE DELIVER
What this actually includes.
Concrete engineering capabilities deployed as part of this service practice.
02 / 06
Architecture and decision records
The shape of the system, written down with the reasoning attached. Each significant decision records what was chosen, why, and what was given up — so a future team can revisit it deliberately rather than by accident.
03 / 06
Full-stack build
Interface, services, data model, and integrations built as one system by the people who designed it, in .NET, Node.js, Python, or a combination, with React and Next.js on the front.
04 / 06
Environments and delivery pipeline
Local, preview, staging, and production that behave the same way. Automated tests, checks, and deploys, so shipping is a routine event rather than a scheduled risk.
05 / 06
Handover and documentation
Runbooks, architecture notes, and a working local setup that a new engineer can follow without a phone call. We assume you will eventually take this in-house, and build accordingly.
06 / 06
Ongoing iteration
Continued work after launch on a predictable cadence — the part where a product usually finds out what it should have been.
HOW WE WORK
How we approach Product Engineering.
Milestone-driven delivery, so integration problems surface in week two rather than in week ten.
01
Frame the problem
Before any architecture, we establish what has to be true for this product to be worth building, and what would make it fail. Most of the value in this stage comes from removing scope rather than adding it.
Stage 01 activities
- Sessions with the people who will use and operate the system
- Constraint mapping: compliance, existing systems, budget, timeline
- An explicit list of what is out of scope for version one
- Success criteria that can be checked, not admired
02
Design the system
We choose the architecture that fits the load, the team, and the failure modes that actually matter here. Boring choices are preferred, and each non-obvious one gets a decision record explaining the trade.
Stage 02 activities
- Data model and service boundaries
- Integration contracts with anything already in place
- Architecture decision records for every significant choice
- A rough capacity and cost model before commitment
03
Build in working slices
We ship a thin, end-to-end path first and thicken it, rather than building layers that only meet at the end. Every slice runs in a real environment, so integration risk surfaces early instead of at the deadline.
Stage 03 activities
- Two-week cycles with something demonstrable at the end of each
- Automated tests written alongside the code, not after it
- Preview environments per change for review
- Weekly written progress notes, including what went wrong
04
Harden for production
The work between demo-quality and production-quality: error handling, observability, access control, backup and restore, and load behaviour. This is the stage most projects skip and most incidents come from.
Stage 04 activities
- Structured logging, metrics, and alerting on the paths that matter
- Access control and audit review
- Restore tested from an actual backup, not assumed
- Load and failure testing against realistic data volumes
05
Hand over and continue
Documentation, runbooks, and enough pairing that your team can operate and extend the system without us. Then a continuing cadence for whatever the product turns out to need next.
Stage 05 activities
- Runbooks for the operational tasks that recur
- Walkthrough sessions recorded for whoever joins later
- A prioritised backlog with our honest read on each item
- An agreed support and iteration rhythm
TECHNOLOGY DEPTH
Technologies behind Product Engineering.
The libraries, runtimes, and services we standardise on for this work, and keep patched.
Frontend
- TypeScript
- Next.js
- React
Backend
- .NET
- Node.js
- Python
Data
- PostgreSQL
Cloud
- Docker
- Azure
Engineering workflow
- Cursor
- Claude Code
DELIVERABLES & OUTCOMES
What you receive, and what actually changes.
We measure success by durable working software in your possession, not presentation slides.
What you get
A scoped, argued specification for version one
Architecture decision records covering every significant choice
A working system in production, with source and infrastructure definitions
Automated test suite and a delivery pipeline your team can run
Environments that match, from local to production
Runbooks, architecture notes, and recorded handover sessions
What changes
A product that a second team can pick up and extend without a rewrite
Deployment as a routine event rather than a scheduled risk
Written reasoning behind the architecture, so it can be revisited deliberately
A realistic view of what version two costs, before you commit to it
QUESTIONS & ANSWERS
Questions about Product Engineering.
Direct answers to common technical and engagement questions.
Usually, yes. We start with a paid assessment: we read the code, run it, and report on structure, test coverage, dependency health, and the specific risks we would want addressed first. That report is useful whether or not you continue with us: it is written so that your own team, or another supplier, could act on it directly.
We scope the first slice tightly and the rest loosely, then re-scope after each cycle. Fixed-price for a whole product built from unsettled requirements produces either padding or a fight, and often both. What we can commit to firmly is the discovery stage and the first working slice.
Yes. Source, infrastructure definitions, and documentation are yours, in your repositories, from the first commit. We do not build on a proprietary platform that makes leaving expensive.
That is a normal outcome and we plan for it. The documentation, environment setup, and decision records exist so a new team can take over, and we will run handover sessions and stay available for questions during the transition.
Yes, and we are direct about it. We use Cursor and Claude Code inside the repository, with a human reviewing every change before it merges. It makes migrations and repetitive work considerably faster. It does not review architecture, and we do not let it decide anything a client is paying us to judge.
Have something ambitious to build?
Tell us what you're working on. We'll tell you honestly whether we're the right team for it.