Someone who decides, and answers for it
Teams that can build are no longer scarce. What is scarce is someone who decides which of the five possible approaches you are taking, writes down why, and is still there when the consequence arrives.
Talk to an engineerWhen teams call us
- The team can build anything and disagrees about everything, so the same discussion reopens every sprint.
- Decisions get made by whoever spoke last, and nobody remembers the reasoning three months later.
- There is a senior developer doing the leading on top of a full workload, and it is not sustainable.
- Hiring a full-time architect is not justified yet, but the absence of one already costs.
- Something has to be chosen — a database, a queue, a way to split the system — and the choice will be expensive to reverse.
- The founder is technical enough to see that something is wrong and not close enough to the code to say what.
What the role covers
Decide, and write down why
Architecture decisions recorded with the trade-off and the alternatives that were rejected, so the next person — possibly you in a year — can tell an intentional choice from an accident.
Set the technical direction
What gets built, in what order, and what deliberately does not get built yet. Most delivery problems are prioritisation problems wearing a technical costume.
Review the work that carries risk
Not every change. The ones where being wrong is expensive: data models, boundaries between services, anything touching money or personal data.
Grow the people who are already there
The measure of this role is that your team needs it less over time. If after a year nothing can move without us, the work was done badly.
Be the one who answers
When something fails at three in the morning, there is a person who understands the system and takes responsibility for it. That part cannot be delegated to a tool.
How it usually works
Part-time technical leadership
A fixed number of hours per week: decisions, reviews of what carries risk, and direction. For teams that need judgement more often than they need another pair of hands.
Accompany a specific project
From the design to production, with the decisions written down and handed over. Ends when the project ships, not when the budget runs out.
Second opinion before an expensive decision
A choice that will be costly to reverse, examined by someone with no stake in the outcome. Short, self-contained, and yours to act on with anyone.
Cover the role while you hire
Keep direction while the search runs, and hand over to whoever you hire — including helping you evaluate the candidates.
What you get
- Decisions written down, with the reasoning and the discarded alternatives
- A technical direction your team can follow when you are not in the room
- Reviews on the work where being wrong is expensive
- Your engineers more able to decide on their own, which is the actual goal
- An honest opinion, including when it is that the problem is not technical
Questions we get asked
Is this a full-time hire?
No. It is a defined number of hours per week, agreed in advance. If what you need is a full-time person, we will say so — and we can help you evaluate candidates instead.
How is this different from the architecture review?
The review is a photograph: two weeks, fixed price, one written report about what breaks first. This is ongoing: being there while the decisions are made. Many teams start with the review and continue here, but neither requires the other.
Do you write code in this role?
Some, on the parts that carry risk. But if most of the time goes into writing code, then what you needed was a developer and the role is being paid for the wrong thing.
What if we disagree with a decision?
Then it gets discussed with the reasoning on the table, and the team decides. The value is in the decision being explicit and written down, not in it being ours.
Start a conversation
Tell us what you are building, or what is currently breaking. You will get a straight answer from an engineer, not a sales script.