Architecture Review and Audit

A structured diagnosis from people who were in the conversations when your stack\u2019s assumptions got set. A written report, readouts for leadership and your engineering team, and a prioritized list of what to fix first.

Best for: Cassandra-at-scale leads, platform engineering leaders, VC and PE partners running technical due diligence, and CFOs who suspect their cloud bill is structurally wrong.
Engagement shape: Scoped and priced per engagement. Project fee, not hourly. Written report plus executive and technical readouts.
Typical triggers: You are about to commit to a new database, platform, or vendor and want an outside read before signing.
You are mid-migration and something feels off, but the team that designed the plan is also the team validating it.
The cloud bill grew 40 percent year over year and nobody on the team can name which line items are load-bearing.
VC or PE technical due diligence on a portfolio company's data stack.
What you walk away with: Written report with findings and prioritized recommendations.
A current-versus-should-cost picture of your data spend.
Executive readout for leadership and technical readout for the engineering team.
An action list your team can run with the next morning.

The problem

You inherited a system. Or you are about to commit to one. Or you are three months into a migration and something feels off, but the people who designed the original plan are also the people you would ask to validate it. That is a closed loop, and closed loops get expensive.

Here is what we keep finding. The shape of your data platform reflects what a vendor sells, not what your workload actually needs. The data model was right at launch and wrong at 10x. The cluster is tuned for a workload that no longer exists. The migration plan understates cutover risk by a factor of three. The cloud bill grows every quarter and nobody on the team can explain which line item is load-bearing and which is paying for somebody else’s roadmap.

We have reviewed more than 100 architectures. The failure modes repeat. A review will not find everything. It will find the five or six things that matter, in an order you can act on, with the cost picture written down so nobody can say later they did not know.

What we diagnose

We offer four scope options:

Cassandra cluster review. Topology, data model, JVM and GC, compaction, upgrade path, cost-per-workload.
Data platform architecture review. End-to-end data platform, batch and streaming, storage layer, vendor lock-in audit, full cost picture.
Migration readiness review. Source system, target system, cutover plan, rollback plan, total migration cost.
AI data infrastructure review. Vector store, retrieval, feature pipelines, training data lineage, inference cost.

Every review is led by a senior operator with decades of production data experience. We do not hand off to juniors.

What you get

Every review delivers the same core set of artifacts:

A written report structured around findings and prioritized recommendations
A cost picture: current spend mapped against what the workload should cost on a sanely designed stack
An executive readout for your leadership
A technical readout for your engineering team
A prioritized action list your team can run with the next morning
A follow-up call once your team is back in the system

How it works

We scope the engagement to the system in front of us. A small Cassandra cluster review and a full multi-region data platform audit are not the same project, and we don’t price them like they are. After a scoping conversation we send a written proposal with a defined deliverable set and a project fee.

Scope. A call to confirm the right systems, the right people to talk to, and the questions you want answered. We sign an NDA and a statement of work. You share docs.

Discovery. We read everything you give us: architecture docs, recent incidents, on-call runbooks, the current roadmap, the data model, the cloud bill broken down by service. We run targeted diagnostics or watch your team run them, and interview the engineers closest to the system.

Analysis. We write. We come back with specific questions, not a survey, but the questions we only know to ask after time inside the system.

Report and readouts. Draft report, comment-and-revise cycle with your team, final report, then the executive and technical readouts back-to-back.

Follow-up. One conversation once the report has been digested and implementation has started.

The decisions downstream of a bad architecture call are worth ten to a hundred times the cost of the review. Most reviews pay for themselves in the first quarter through the cost picture alone.

Questions teams ask

Why is this modeled on Jepsen?

Because Kyle Kingsbury figured out that the highest-trust shape for a deep technical review is a published, self-contained report. We borrowed the shape. The difference is that Jepsen reports are public research. Our reports are private to the client unless both sides agree to publish.

Will the report tell us what our stack should cost?

Yes. Every review includes a section comparing your current spend against what your workload should cost on a sanely designed stack. That number is usually the most-quoted line in the report.

Can the report be published as a case study?

Yes, if both sides want that, after a redaction pass. Many clients prefer private reports.

Can you review a system you helped design?

No. If we already designed it, we are not the right people to audit it.

What if you find something so bad we need you to stay and fix it?

Then we scope a Tiger Team engagement separately. The review fee is still the review fee.

Do you do security audits?

No. We will flag obvious issues. Security audits are a separate discipline and you want a firm that does only that.

Let’s look at it together.

Bring us whatever you're wrestling with. A new architecture, a migration plan, a bill that keeps growing, a team that needs a sounding board. Thirty minutes, no pitch. We'll tell you what we see.

Book a 30-minute introduction call hello@mcfad.in