Four phases, each with a defined exit
A sequence designed so you can stop after any phase and still be better off than when you started. Nothing about it depends on you continuing.
- 01
Assess
2–4 weeksWe read the code, the incidents and the obligations before drawing anything. You get a written assessment of what is actually true about your systems — architecture, risk, delivery capacity — and a prioritised set of moves.
- 02
Architect
3–6 weeksTarget architecture, migration sequencing and the decision records behind both. Every choice is traceable to a constraint: a regulation, a latency budget, a team you actually have.
- 03
Build
3–12 monthsA small senior team working inside your repositories and your ceremonies. Production increments from the first month, with tests, observability and runbooks treated as part of the deliverable rather than a later phase.
- 04
Hand over
Defined up frontWe are not trying to become permanent. Documentation, pairing and on-call rotation transfer ownership to your engineers, and we stay reachable for the quarter that follows.
The habits we are deliberately not repeating
Most of us have been on the receiving end of a consulting engagement. These are the parts that made them worth less than they cost.
A team of ten from week one
A scoped assessment first. Headcount is the last thing a struggling programme needs and the first thing most consultancies sell.
A discovery phase with no artefact
Every phase ends in a document you own — assessment, architecture, decision records — whether or not you continue with us.
Knowledge that leaves when we do
Pairing and written decisions throughout, with handover conditions agreed before the first commit rather than negotiated at the end.
Compliance bolted on at the end
Obligations are gathered in the assessment and treated as architectural constraints, because retrofitting controls is what costs a year.
What you can hold us to
Alveron is a new firm without a decade of case studies behind it. These commitments are what we offer instead, and they are in the contract.
A fixed-scope first step
Every engagement starts with a scoped, fixed-fee assessment. You know the cost and the deliverable before anything begins.
A written deliverable, always
Findings, architecture and decisions arrive as documents you own and can circulate internally — not as a conversation you have to reconstruct later.
An honest answer on fit
Alveron is new and deliberately narrow. If your problem sits outside what we are genuinely good at, we will say so in the first call.
No lock-in by design
You keep the repositories, the infrastructure accounts and the documentation throughout. Nothing about the engagement makes leaving expensive.
Senior people only
Nobody learns on your budget. Work is done by people who have already run systems where mistakes are measured in money, and we would rather decline an engagement than staff it thinly.
Regulation as a design input
Compliance obligations shape architecture from day one. Retrofitting controls onto a finished system is how programmes lose a year.
Written before built
Decisions are recorded, trade-offs are explicit, and the reasoning survives the people who made it. Your team inherits arguments, not just code.
Exit is part of the plan
Handover conditions are defined before the first commit. A long engagement should be a choice you keep making, not a dependency you cannot unwind.
Start with the assessment.
Fixed fee, fixed scope, a written deliverable at the end. If it tells you the work should go to someone else, that is still a useful answer.