Build
Product Engineering
Web and mobile products taken from zero to launch — and from launch to the version that actually holds up under load.
A product is not a feature list. It is a set of decisions about what to build first, what to defer, and what to refuse. We work best when we are involved in those decisions rather than handed a specification and asked to type.
The expensive failures in product work are rarely technical. They are building the right thing in the wrong order, or building six things adequately when one thing done properly would have answered the question. An agency paid by the hour has no incentive to tell you that. We would rather have a shorter engagement and a reference than a longer one and a shrug.
Our default stack is boring on purpose: TypeScript, a mainstream framework, a relational database, and infrastructure you could hand to another team without a translation layer. Novelty belongs in your product, not your deployment pipeline. Every unusual technology choice is a hiring constraint and an on-call liability, and it should have to justify itself against those costs.
We ship in increments you can see. If you cannot use the thing within a few weeks, the scope was drawn wrong. That discipline is not about speed for its own sake — it is because feedback from a working system is worth more than any amount of upfront specification, and the sooner it arrives the cheaper the corrections are.
Accessibility and performance are part of the build rather than a phase at the end. Retrofitting either one costs several times what it costs to do as you go, and the version of the product that is fast and usable with a keyboard is simply the better product.
What is included
- Scoping and sequencing: what to build first, and what to leave out
- Interface design and interaction detail
- Frontend and backend implementation
- Database design and migrations
- Automated tests and continuous integration from the first commit
- Accessibility to WCAG 2.2 AA as a build requirement
- Performance budgets, set early and measured
- App store submission for mobile work
What we do not do
- Pixel-matching a design file without questioning the parts that will not work
- Fixed-scope, fixed-price contracts that punish both sides for learning something
- Rewrites of working systems where the real problem is organisational
- Building a second product before the first one has users
How the work runs
- 01
Sequence the work
We agree the smallest version that answers the riskiest question, and write down what is deliberately excluded. Scope creep is normal; unacknowledged scope creep is what kills projects.
- 02
Ship a usable slice
Deployed, tested, and in your hands within the first few weeks. Not a mockup — the real thing, narrow.
- 03
Iterate against real use
Weekly demos on the running system. Changes are welcome and costed openly, so you can decide whether each one is worth its price.
- 04
Harden for launch
Load testing, error handling, monitoring, and the documentation your team needs to own it. Launch is a planned event, not a hopeful one.
Where we have done this
Five projects you can read in full.
A floor designer in the browser, with an order-ready PDF at the end
An interactive tile design and ordering tool: choose layouts, designs and fills, watch the floor render live, and leave with an order-ready PDF template.
ZishesA marketplace with games inside it, and the pipeline that ships it
A React Native marketplace app with Unity games embedded in it, running on self-managed Kubernetes with GitOps delivery — where a deploy is a commit and a rollback is a revert.
A global professional services firmA form builder that took IT out of the loop
A custom platform letting administrators at a global professional services firm build, manage and analyse internal forms in real time — without raising a ticket for every new one.
StratoformA building that assembles itself as you scroll, for a factory that has not opened yet
Stratoform sells precast concrete into an Indian construction market that still mostly pours on site. They had no finished building to photograph and no production floor to film — the German casting line was still being installed. So the site makes the argument structurally instead: scroll, and a three-storey frame goes up element by element, each one labelled with the spec it would carry on a drawing.
TraferrA social platform where the rewards are part of the product
A social media app with built-in rewards, built from the ground up for iOS and Android with a gamified interaction model at its centre.
Shipped with
- React
- TensorFlow.js
- SVG
- Firebase
- React Native
- Unity
- Express
- Redis
- BullMQ
- Kubernetes
- Helm
- Rancher Fleet
- Traefik
- Docker
- Next.js
- Three.js
- WebGL2
- Lenis
- k3s
- nginx
- Let's Encrypt
Taken from the projects above, not from a list of things we have read about.
Capabilities
- Web application development
- Mobile app development (iOS and Android)
- Custom software development
- eCommerce and digital commerce
- UI and UX design
- Enterprise portals
- API design and development
- Legacy application rewrites
- Progressive web apps
- Design systems and component libraries
- Accessibility remediation
- Frontend performance optimisation
Questions we get asked
Do you work fixed-price or time-and-materials?
Time-and-materials against a fixed scope and timebox, with a written estimate and its assumptions. Genuinely fixed-price only works when the requirements cannot move, which is rare in product work — and when it is forced, both sides end up arguing about change requests instead of building.
Can you work with our existing codebase?
Usually. We start with a short review to find out what we are dealing with and tell you honestly whether extending it or replacing part of it is the better bet. We have no interest in recommending a rewrite that is not warranted — rewrites are where projects go to die.
What technologies do you use?
TypeScript across the stack by default, with a mainstream framework and a relational database. For mobile we use native or Flutter depending on how much platform-specific behaviour you need. If your team already has a stack they can maintain, matching it usually beats introducing ours.
Who owns the code?
You do, from the first commit, in your repository. No proprietary components, no licensing that follows you, no dependency on us to keep it running. If you want to take the work in-house at any point, that should be a decision rather than a negotiation.
Do you do design as well as engineering?
Yes, and we prefer to. Interface decisions and implementation constraints inform each other constantly, and splitting them across two vendors adds a translation layer where detail gets lost. If you have a design partner already, we work with them directly.
What happens after launch?
Whatever you need and nothing you do not. Some clients take the work in-house immediately, which is a fine outcome and one we plan for. Others keep us on a support arrangement sized to the system’s real criticality. We review that arrangement periodically and will tell you when it stops being worth its cost.