Contents
- Why it’s free, stated plainly
- How the session is structured
- What we typically find
- What to have ready
- What ninety minutes cannot do
- Who this is a bad fit for
- FAQ
- Book it
Ninety minutes. Two of our engineers. Your codebase and your worst problem. Live and recorded, and you keep the findings whether or not you ever speak to us again.
The reasonable response to that is “what’s the catch.” So this article is the session, described in advance: the structure, what we typically find, what to have ready, and — the part that matters most for calibration — what ninety minutes cannot do.
Why it’s free, stated plainly
Not because it’s a lead magnet that happens to be labelled differently. Because of how the rest of our business works.
Nothing above the free tier gets bought cold. Nobody signs a $250K–$750K modernization program off a first call, and we wouldn’t want them to. Those engagements are bought by people who have already watched us work — who have seen how our engineers think about a problem before any money moves.
Ninety minutes of engineering time is what that costs us. It’s cheaper than the sales process it replaces, and it selects for the clients we actually want: the ones who saw the work and chose it.
There are no salespeople on the call. That’s a staffing fact, not a tagline — we don’t employ any on the delivery side. The ninety minutes is spent reading code.
How the session is structured
First 10 minutes — the problem in your words. You describe what’s wrong. We mostly listen. The specific thing we’re listening for is the gap between what you say the problem is and what you say when you’re describing a symptom — those two are often different systems.
Minutes 10–30 — orientation. Repository structure, deploy pipeline, the shape of the data model, where the monitoring is. We’re building a rough map fast. Expect questions that seem tangential; how you deploy tells us more about your constraints than the code does.
Minutes 30–70 — the actual problem. We go into the code. Screen shared, both directions, your engineers welcome and encouraged. This is the part that is not a meeting — it’s two people reading something difficult out loud.
Minutes 70–85 — what we found. Stated plainly, including the things we’re unsure about and why. If we think you don’t have a problem worth paying anyone to solve, this is where we say so.
Last 5 minutes — what we’d do next. Sometimes that’s an engagement. Frequently it’s “here are three things your own team should do, in this order, and you don’t need us for any of them.”
You get the recording and our notes. No follow-up sequence, and nobody from a CRM will call you.
What we typically find
- The reported problem is a symptom of a different system than the one suspected
- A performance issue that’s a data-model problem, not an infrastructure problem
- A “we need to rebuild” conviction that turns out to be a tooling and CI problem
- A risk nobody had noticed at all, unrelated to the reason for the call
What to have ready
None of this is homework and none of it needs to be prepared specially. If you have it, the ninety minutes goes further.
- Repository access, or a screen share from someone who has it. Read-only is fine. If access needs legal sign-off, start that before booking — it’s the most common reason a session runs short.
- The person who knows the system best, even if they’re junior. Especially if they’re junior.
- One specific problem, not a general sense of unease. “Checkout times out under load on Mondays” beats “our system is slow.”
- Your deploy process, described honestly. Including the manual steps and the one nobody talks about.
- Recent incidents — the last three, roughly what happened.
- Anything you’ve been told by another firm. We’ll tell you whether we agree, and we’ll say so if we do.
What you don’t need: a prepared deck, a cleaned-up repo, an architecture diagram, or your best engineer to have rehearsed. A tidied codebase is actively less useful.
What ninety minutes cannot do
Setting this out matters more than the sales pitch, because a session that oversells itself produces a disappointed client and a wasted ninety minutes on both sides.
It is not an audit. We see one problem properly and form impressions about everything else. Impressions are not findings. A Systems Audit takes two to three weeks and produces four artifacts you own — that’s the document you take to a board. Ninety minutes is not that and cannot be compressed into that.
It is not a security assessment. We’ll flag anything alarming we happen to see. We are not looking systematically, and “nothing came up in ninety minutes” is not a clean bill of health on security.
It is not an estimate. We will not price a rebuild off a session. Anyone who does is guessing, and you’d be paying for their guess later. [INTERNAL LINK: /insights/fixed-price-vs-time-and-materials “why fixed-price quoting requires a diagnostic first”]
It won’t settle an internal argument on its own. If your team is split on [INTERNAL LINK: /insights/rebuild-vs-refactor-vs-replace “rebuild vs refactor”], ninety minutes gives you an outside opinion, not evidence. The scoring rubric in that article, or an audit, is what settles it.
It cannot fix anything. We don’t write code on the call.
Who this is a bad fit for
Worth saying, because a wasted session helps nobody.
- You need a vendor quote for a procurement process and already know what you’re buying
- Your problem is organizational rather than technical — we’ll spot it and say so, but we can’t fix it
- You can’t grant any code access, even read-only, even under NDA
- You need a second opinion in writing today
FAQ
Is the free code review really free?
Yes. Ninety minutes, two engineers, no charge, no obligation, and you keep the findings and the recording whether or not you hire us. Our larger engagements are bought by people who have already seen how we work, so the session replaces a sales process rather than starting one.
Are there salespeople on the call?
No. We don’t employ salespeople on the delivery side. Two engineers, and the time is spent reading code.
What do I need to prepare for a code review session?
Read-only repository access or a screen share, the person who knows the system best, and one specific problem rather than a general unease. Don’t tidy the codebase — a cleaned-up repo is less useful to us.
How is this different from a paid systems audit?
Depth and output. Ninety minutes examines one problem and produces findings plus a recording. A systems audit takes two to three weeks, costs $18K–$35K, and produces four artifacts you own outright: architecture map, risk register, remediation plan and fixed-price build proposal.
Will you sign an NDA before the session?
Yes. Start that process before booking if your legal team is slow — NDA and access approval are the most common reasons a session runs short.
What if you find nothing?
We’ll say so. It happens, and it’s a legitimate outcome — sometimes a team’s instinct that something is wrong is anxiety rather than architecture. You’d have spent ninety minutes to find that out, which is cheap.
Book it
Ninety minutes. Two engineers. No charge, no salespeople, no follow-up sequence. You keep whatever we find.
