Product launch
Product audit
A review of an existing product: where it loses users, what blocks growth, which parts of the code and infrastructure have to be touched first.
- Reply to your brief
- within 24 hours
- First call
- 30 minutes, no commitment
- First working version
- in 2 weeks
Process
What happens, and when
The work is split into stages, and each one has a named result. You see it yourself rather than reading about it in a report.
Days 1–3
The subject of review
We agree on what counts as a problem: a product that loses people at sign-up and a product that falls over under load are ill in different ways. We take the access — repository, server, metrics — and the first thing we look at is what is measured at all, and what nobody has ever counted.
You get — An agreed problem statement and access
Days 4–9
Code and product
We read the code and the infrastructure: where the module boundaries have worn away, which places have been rewritten most often, what happens when the database or an external service fails. In parallel we walk the product as a user and mark every point where you have to guess. If a hole in the access rights turns up on the way, you hear about it that day rather than from the report.
You get — Findings across the code, infrastructure and journeys
Days 10–12
Weighing the findings
Every finding gets a weight: how many people it touches, what happens if it is left alone for six months, and what the fix costs. Without that you get a list of forty items nobody ever picks up.
You get — Findings weighted by reach and repair cost
Days 13–14
Report walkthrough
We go through the report out loud, and with your developers rather than only with the manager: the tasks have to end up with the people who will do them. Each item says what to change and how to check afterwards that it got better.
You get — Tasks with a way to check each fix
After the report
What happens next
From there it is your call: fix it in-house, hand some of the items to us, or touch nothing. The report does not go stale in a month — six months on it still shows what was fixed and what stayed where it was and grew more expensive.
You get — A report that shows what was fixed and what was not
What the work covers
What counts as a problem
people leaving at sign-up, failures under load, or changes that cost more every month — those are different reviews
Reading the code
where the module boundaries have worn away, what has been rewritten most often, and which dependencies stopped being updated
Walking the product
sign-up and the main journey seen as a user, and every point where you have to guess what happens next
Failure and access
what happens when the database or an outside service goes down, and who can reach what; a hole in the rights reaches you the same day
The numbers you have
which events are counted today, which numbers are missing, and why the product ends up argued about by feel
A report with weights
who each finding affects, what the fix costs and how to check the result; walked through out loud with your developers
What we need from you
- Access to the repository, the server and the metrics — read-only is enough, but for every environment
- A developer or a manager who remembers the project’s history and can say why it was built this way
- An hour of your developers’ time for the walkthrough, or the list stays with the manager and never becomes tasks
What people usually ask
Contact
Send a description of the task
A reply with the scope, the timeline and a budget estimate comes within 24 hours.
The first call is 30 minutes, with no commitment on your side.
01
You describe the task
Five questions in the form, or a plain email — whichever suits you.
02
We answer within a day
With the scope, the timeline and a budget estimate, based on what you told us.
03
We talk for 30 minutes
To clear up whatever is unclear. It commits you to nothing.