Services
Software architecture and code review
A structured look at your product's architecture, code and operations, ending in a prioritised list of what to change and what to leave alone.
For founders and tech leads with a product in production, or about to launch one.
What a finding looks like
Every item in the review has this shape, so the team can act on it without a meeting.
Change firstExample from a typical review
Background jobs run inside the web process
- What I saw
- Report generation and e-mail sending run in the same process that serves requests. A slow report makes the app unresponsive for everyone.
- Why it matters
- The first large customer will trigger it daily. Support will see timeouts and nobody will connect them to the reports.
- What to do
- Move the jobs to a worker with a queue. The hosting already supports it, so this is days of work, not a rewrite.
How it works
A few days for a typical early-stage product. A pre-launch setup session is one or two days with the team.
A call, then access
We agree on what you want answered and how deep to go. I get read access to the code, the infrastructure and the documentation.
Reading and interviews
I read the code the way a new senior engineer would, trace the paths that matter, and talk to the people who built it. Their view of the weak spots is usually accurate and rarely written down.
Written findings, in order
What to change first, what can wait, what to leave alone. Each item with the reason, the effort, and what happens if nothing is done.
A walkthrough with the team
The findings explained to the engineers, questions answered, and a plan the team owns. If you want me to help implement it, that becomes a separate engagement.
What it costs
A fixed price, quoted after the first call based on the size of the codebase and the questions you want answered. For products that are not live yet, the review becomes a working session with the team at a fixed day rate. Numbers on request.
Ask for a quote
Questions people ask first
- What is a software architecture review?
- A software architecture review examines how a software product is built: its structure, data model, dependencies, tests, infrastructure and the process the team uses to change it. The result is a prioritised list of improvements with the reasoning behind each one, so the team knows where to start and what to leave alone.
- How long does it take?
- A few days for a typical early-stage product, from access to the written findings. The walkthrough with the team usually happens within the same week.
- Is this the same as a code audit?
- A code audit in the narrow sense checks the source code for defects and security issues, often with tools. This review includes that, but it also looks at the architecture around the code, the data model, the release process, the infrastructure and the team, because most of the problems that matter in early-stage products live there rather than in a single file.
- How is this different from a technical due diligence?
- A review works for the company and its team and ends in recommendations. A due diligence works for an investor and ends in a risk assessment. If you are a founder, you want the review. If you are investing in a founder, you want the due diligence.
- Do we need to prepare anything?
- Access to the repositories and the infrastructure, an hour with each of the engineers, and an honest list of what worries you. No documentation needs to be written beforehand. The state of the documentation is part of what I look at.
- Will you implement the changes?
- If you want me to, yes, as a separate engagement with its own scope. Many teams implement the findings themselves and come back with questions, which is fine too. The review is written so that it works either way.