Build · Digital Products
Product engineering
End-to-end delivery of web platforms and internal systems, from architecture decisions to a stable production release.
The challenge
Institutional software is rarely greenfield. A new citizen portal, student record system or clinical scheduling tool has to sit alongside decades of existing systems, procurement rules and audit obligations, and it has to keep working long after the delivery team has left.
Many programmes fail not because the code is poor but because decisions are undocumented, quality is inspected at the end rather than built in, and the organisation cannot operate what it has been handed. The result is a platform that works on launch day and becomes a liability within a year.
We run product engineering as a disciplined, evidence-producing activity: architecture decisions are recorded, tests are written first, every change is reviewed, and the handover is designed from the first sprint rather than bolted on at the end.
Our method
How the work is done.
- 01
Discovery and framing
Stakeholder interviews, process mapping and a review of existing systems to agree scope, constraints and measurable outcomes before any code is written.
- 02
Architecture and decisions
A target architecture, threat model and set of architecture decision records that explain what was chosen, what was rejected and why.
- 03
Iterative delivery
Two-week increments with working software at the end of each, test-first development, peer review on every change and a demo to stakeholders.
- 04
Assurance
Automated security scanning, accessibility checks, performance testing and an independent review before each production release.
- 05
Release and stabilisation
Staged rollout with feature flags, monitoring and a defined hypercare period in which the delivery team remains on hand.
- 06
Handover
Runbooks, documentation and pairing sessions so your team, or a managed service, can operate and extend the platform with confidence.
Deliverables
What you receive.
- Production-ready source code in your repositories, under your ownership
- Architecture decision records and a maintained architecture overview
- Threat model and record of security testing performed
- Automated test suites and a CI/CD pipeline that runs them on every change
- Operational runbooks and an on-call guide
- Accessibility conformance report against WCAG 2.2
- Backlog of known issues and recommended next increments
Engagement options
Ways to buy it.
- 012–4 weeks
Discovery sprint
A fixed-scope phase that produces a validated scope, architecture, delivery plan and estimate.
- 023–9 months
Delivery squad
A senior cross-functional team building against an agreed roadmap with fortnightly reviews.
- 034–8 weeks
Platform rescue
Assessment and stabilisation of an existing platform, followed by a prioritised remediation plan.
Standards
Frameworks we work to.
- OWASP ASVS
- OWASP Top 10
- WCAG 2.2
- ISO 27001 (Annex A secure development controls)
- DORA metrics
- NIST SSDF (SP 800-218)
Questions
What buyers ask us.
Who owns the code and intellectual property?
You do. Code is written in repositories you control from the first day, and the engagement terms assign ownership of project deliverables to you.
Can you work with our in-house developers?
Yes. We regularly form blended teams, and we plan pairing and knowledge transfer so your engineers are able to own the platform after handover.
How do you handle changing requirements?
Scope is managed through a prioritised backlog. Changes are discussed at fortnightly reviews and traded against existing items, so the impact on timeline is visible before it is agreed.
What technology stack do you use?
We choose based on your constraints, existing skills and hosting environment. Each choice is recorded in an architecture decision record so it can be revisited later.
What happens after go-live?
A hypercare period follows each major release. After that you can operate the platform yourselves, or move it to one of our managed service arrangements.
Related services
Often delivered together.
Build
UX & product design
User research, service design and accessible interfaces that make complex institutional services simple to use.
Run
Platform engineering
Internal developer platforms, CI/CD pipelines and infrastructure as code that let teams ship safely and quickly.
Train
Secure development
Practical training for developers on writing, reviewing and testing code that withstands real attacks and passes security review.
Discuss product engineering.
A senior engineer reviews every enquiry and replies within one business day.