About
We build software the way we would want it built for us
Why we started
Drezen began because three of us had spent years watching good engineering budgets produce disappointing software, and we had a fairly specific theory about why.
It was rarely the technology. It was that the people who scoped the work were not the people who delivered it, that estimates were commitments made before anyone understood the domain, and that the incentive structure of most agency relationships quietly rewards saying yes to everything. By the time a project was visibly in trouble, too much had been spent to change course.
So we built the firm around a small number of decisions that are inconvenient for us. Discovery is paid, because free discovery is shallow discovery. Fixed-scope estimating errors are our risk, not yours. Code lands in your repository from the first commit. And we say the uncomfortable thing in week one — that the scope is unrealistic, that the technology choice is wrong, or that you should buy something rather than build it.
Seven years on, that has turned out to be good business rather than a sacrifice. Clients who were told the truth early come back, and they send people to us. Roughly two-thirds of our work now arrives by referral.
How we operate
Six things we actually do
Not aspirations on a wall. Each of these costs us something, which is how you can tell we mean them.
Say the uncomfortable thing early
If the estimate is wrong, the scope is unrealistic, or the technology you have chosen is the wrong one, you hear it in week one. Bad news does not improve with age, and we would rather lose a project than deliver one we know is going to disappoint.
Measure before rebuilding
The instinct to rewrite is almost always stronger than the evidence for it. We profile, trace and quantify before proposing anything expensive — and we have talked more clients out of rewrites than into them.
Leave nothing locked in
Your repositories, your cloud accounts, your documentation, from day one. No proprietary runtime, no licence to renew, no knowledge that lives only in our heads. If you want to take it in-house, we will help you do it well.
Small teams, senior people
We add a second team rather than growing one past the point where it stays coherent. Everyone who works on your project is someone we would be happy to have you interview.
Working software over status reports
Every two weeks there is something running you can use. Progress that only exists in a document is not progress, and a green RAG status has never shipped anything.
Accessibility is not a phase
WCAG 2.1 AA is an acceptance criterion in every engagement, designed in from the first component rather than audited at the end when fixing it costs five times as much.
How we work
Five phases, no surprises
The same shape on every engagement. You always know which phase we are in, what comes out of it, and what decision is needed from you next.
- 01
01 · 1–4 weeks
Discover
1–4 weeks
We map the domain, the constraints and the actual decision the software has to support — before anyone proposes an architecture.
- Stakeholder and user interviews
- Domain model and process map
- Technical constraints and risk register
- Prioritised backlog with a fixed-scope phase one estimate
- 02
02 · 2–4 weeks
Design
2–4 weeks
Architecture and interface designed together, so nothing gets built before it has been agreed on paper by both sides.
- System architecture and data model
- API contracts and authorisation matrix
- High-fidelity UI covering every state
- Infrastructure topology and security design
- 03
03 · 8–20 weeks
Build
8–20 weeks
Two-week increments against a shared board. Every increment is deployed and demoable — progress is visible in the product, not in a document.
- Working software every two weeks
- Automated tests in CI from the first sprint
- Deployed staging environment with real data
- Open board, open repository, open metrics
- 04
04 · 2–4 weeks
Launch
2–4 weeks
Hardening, rehearsal and a cutover with a tested rollback. Launch day should be uneventful, and that takes preparation.
- Load, penetration and accessibility testing
- Runbooks and monitoring in place
- Rehearsed cutover with rollback proven
- Analytics and success measures instrumented
- 05
05 · Ongoing
Support
Ongoing
SLA-backed operations with reserved capacity for improvement — or a structured handover to your team. Your choice, not ours.
- Severity-based SLA with reported performance
- Preventive maintenance and dependency upgrades
- Monthly improvement allocation
- Documented handover path whenever you want it
The team
You will meet the people doing the work
Before you sign anything, you speak with the delivery lead and at least one engineer who will be on your project. We do not run a pre-sales team that hands over to strangers.
Team photography placeholder
Leadership headshots, names and short bios go here. We have deliberately not generated placeholder people — inventing colleagues would be exactly the kind of thing this page argues against. Supply real photos and bios and this becomes a grid.
Meet the team on a call insteadWant to know if we are a fit?
The fastest way to find out is a 30-minute call. We will be direct about it either way.