01
A big bet with no second opinion
Rebuild or refactor, monolith or services, buy or build — the decision will cost seven figures either way, and everyone advising you has something to sell.
Services
IT consulting services
Some decisions are too expensive to get wrong and too technical to decide alone: the architecture bet, the acquisition, the platform that's slowing down and nobody knows why. We put senior engineers on the question and give you the answer in writing — with the evidence attached.
Who this is for
You’ll recognize the situation
02
Due diligence on a deadline
The acquisition closes in six weeks and someone needs to tell the board what the target's codebase, team, and infrastructure are actually worth — in writing.
03
Delivery slowed and nobody agrees why
Twice the engineers ship half the features of two years ago. Engineering blames process, product blames scope, and the honest answer needs an outsider with no stake in it.
What’s included
IT consulting, itemized
Technical due diligence
Codebase, architecture, team, and infrastructure assessed against the deal thesis — delivered as a written report with a risk register your board can read.
Architecture review and roadmap
A senior read on your system's real constraints, then a sequenced roadmap that says what to fix first and — just as important — what to leave alone.
Cloud cost and performance audit
Full cost attribution and utilization analysis producing a ranked savings backlog, each item priced by value, effort, and risk.
Delivery assessment
Two weeks inside your process — repos, tickets, meetings, interviews — producing a specific diagnosis of where throughput actually leaks, backed by your own data.
Security and compliance review
A practical gap analysis against SOC 2, ISO 27001, or your regulator's bar — ordered by real risk, not by checklist alphabetical order.
Fractional CTO support
A senior engineering leader in your leadership meetings — for the stretch between founding and your first full-time CTO, or through a hard transition.
How it runs
Four phases, no surprises
01
Diagnose
We read the code, the tickets, and the org chart — and interview the people who do the work, not just the people who report on it.
02
Plan
Findings land as a written report: evidence, options, and a recommendation with its trade-offs stated — never a deck of platitudes.
03
Build
If you act on it, we sequence the roadmap with your team and stay through the first milestones — consulting that survives contact with delivery.
04
Scale
Quarterly check-ins against the recommendations, revised as facts change. Advice you can re-litigate against what we wrote down.
2–4 wks
typical time to a written recommendation
31
ranked findings in a recent cost audit
100%
of recommendations delivered in writing
Illustrative figures from anonymized engagement profiles.
Case study
What that looks like shipped
A Series B payments platform was watching AWS spend outgrow transaction revenue. We cut the bill 38% in 90 days — with zero customer-facing incidents and the PCI scope untouched.
Read the full case study
In depth
What a written technical diagnostic contains
The default deliverable in IT consulting services is a slide deck: twenty pages of maturity models, a two-by-two, and a recommendation to schedule more consulting. We write a document instead — 30 to 60 pages, sized to the scope — built so your board can read the summary in five minutes and your engineers can check every claim in the appendix.
Four things are always in it. A ranked findings register, where each finding carries its evidence, its cost if ignored, and its estimated effort to fix. An architecture map of the system as it actually runs, not as the wiki describes it. Delivery metrics pulled from your own repositories and trackers — lead time, review latency, deployment frequency — so the diagnosis rests on your data rather than our impressions. And a sequenced plan for the first 90 days, ordered by risk retired per week of effort.
The evidence standard is the point. Every claim in the register traces to something checkable: a commit, a ticket, an invoice, a named interview. When we told a payments client their clusters ran at 22% utilization, the number came from their own metrics — and the fix that followed, part of a backlog of 31 priced findings, helped cut their AWS bill 38% in a quarter.
Just as deliberate is the do-not-touch list. Most systems contain code that is ugly, stable, and profitable, and the cheapest decision available is to leave it alone. A diagnostic that cannot name what to skip is a sales document; ours states it explicitly, because the fastest way to waste a year is refactoring something that was never the constraint.
Technical due diligence your investment committee can act on
When you are acquiring a company or leading a round, the target's engineering is part of the price — and the data room rarely says what it is worth. Our technical due diligence assesses four things against the deal thesis: the codebase, the architecture, the infrastructure and its cost trajectory, and the team that comes with the deal.
The method is a fixed evidence checklist, applied the same way every time. On the code: dependency age, test posture, licensing exposure, and bus factor — how many people can safely change the systems that make the money. On infrastructure: unit economics today and what the bill does at five times the load. On the team: who wrote the critical paths, who is a retention risk, and what the interviews say that the org chart does not.
Findings arrive priced, not described. Instead of 'technical debt is significant', the report states what remediation costs after close — engineer-months and calendar time — and sorts every issue into one of three buckets: walk-away risks, negotiating points, and first-100-days work. That is the difference between a report your investment committee files and one it acts on.
We are also plain about the limits. Two to three weeks of access cannot read every line, so we sample by risk — the revenue path, the data layer, whatever the deal thesis depends on — and the report says what was examined and what was not. A diligence that claims total coverage on that timeline is telling you something about its other claims too.
Build vs buy and replatform vs refactor, decided on evidence
These two decisions burn more money than any outage, and they fail in predictable ways. Build-vs-buy comparisons put the vendor's list price against an optimistic build estimate and ignore integration, customization drift, and the cost of leaving. Rewrite decisions get made on frustration — the team hates the codebase — rather than on measurement of where the pain actually lives.
Our build-vs-buy framework prices the full three-year path on both sides: licences plus integration plus the customizations you will inevitably bolt on, against build cost plus the ongoing ownership nobody budgets. Then one question does most of the deciding: is this capability something your customers choose you for? Buy commodity, build differentiation — the hard part is drawing that boundary honestly, and it is where an outside reviewer with nothing to sell you either way earns the fee.
For replatform-vs-refactor we measure before we recommend: change frequency crossed with defect density shows which modules actually hurt, and it is usually a short list. That is why the answer is rarely a big-bang rewrite — an incremental, route-by-route migration keeps the roadmap shipping while it pays down the worst hotspots first. The honest exception exists: when the platform blocks a capability the business needs and the hotspots are everywhere, we will say rewrite, in writing, with the risks attached.
And when the questions keep coming, a decision-scoped engagement works as a fractional CTO alternative: senior judgment on the calls that matter, in writing, without paying for standing days you do not use. If what you actually need is someone in the leadership meeting every week, we will tell you that too — fractional CTO support is on the menu, but it should not be the default.
Tools we reach for
A boring, hireable stack
Chosen so your team can maintain, extend, and hire for everything we leave behind.
- AWS
- GCP
- Kubernetes
- Terraform
- PostgreSQL
- TypeScript
- Python
- Datadog
FAQ
The questions buyers actually ask
Answered the way we’d answer them on a call — specifics included.
Fixed price, fixed scope, fixed deadline — agreed before we start. A due diligence or delivery assessment is a defined deliverable, not a meter running. Fractional CTO work is the exception: a flat monthly rate for an agreed number of days, cancellable monthly.
You do. Reports, analyses, scripts, and anything else produced during the engagement are yours on payment, unencumbered — share them with your board, your investors, or another vendor. We keep nothing proprietary in the deliverable.
Read access to repos, infrastructure, and trackers, plus interview time — typically 45 minutes per key person. We work at least four hours overlapped with your day so interviews and findings sessions happen inside your working hours, under NDA from the first call.
A standard technical due diligence takes two to three weeks from access to written report; for deal deadlines we compress the timeline to ten working days. Speed comes from a fixed method — the same evidence checklist every time — not from skipping the reading.
Yes — it's assumed in the work. NDAs before any access, least-privilege read-only credentials you can revoke at will, no data copied off your systems, and findings shared only with the people you name. For M&A work we're comfortable operating inside formal deal-room protocols.
Then you'll disagree with something specific, because the recommendation comes with its evidence and stated trade-offs — not a vibe. We'd rather you reject a clear argument than accept a vague one. And if mid-engagement it's clear we're not adding value, we say so and stop billing; the reputational math is simple.
It's the right question to ask any consultancy that also builds. Two guardrails: every recommendation is scoped and priced so you can hand it to your own team or any other vendor without us, and the diagnostic is priced to stand on its own — an engagement that ends with the report is a fine outcome, not a loss we need to recover. If we recommend a build and you want us to do it, that's a separate decision you make after reading the evidence — never a condition of the report.
Depends on the shape of the problem. One expensive, well-defined decision — an architecture bet, an acquisition, a stalled platform — is answered faster and cheaper by a scoped diagnostic than by a standing hire. A continuous stream of decisions with no senior technical voice in the room is a fractional CTO problem, and we offer that too. We'll tell you which one you have on the first call, and the scoped engagement is the cheaper way to find out.
Not if it's run properly, and running it properly is most of the method. Interviews happen under stated ground rules — nothing attributed without permission — and findings name systems, incentives, and constraints, never individuals. In practice engineers tend to become the report's strongest advocates, because it puts in writing, with evidence, what they've been saying in retrospectives for a year.
Related services
Services often paired with this one
Have something ambitious in mind?
Tell us where you're headed. We'll reply within one business day with an honest read on whether we can help.