Tiger Team and Embedded Build

Senior hands in the repo with your team. Cassandra migrations, performance tuning, production readiness, data model redesigns. We build it, we hand it off, we leave.

Best for: Teams four to twelve weeks from a Cassandra cutover, engineering leads managing a production performance crisis, and platform teams pushing a stateful service toward production under a real deadline.
Engagement shape: Scoped and priced per engagement on the first call. Project fee, not hourly. Senior operators only.
Typical triggers: A Cassandra cutover with a hard deadline and a team that has never done one before.
Production performance crisis the team cannot get out from under without pulling their best people off the roadmap.
A stateful service heading toward production with a real launch date.
A data-platform build the team has scoped but does not have the senior bench to ship on time.
What you walk away with: Working code, shipped to production with your team.
A written runbook for the system we built, owned by your engineers.
A cutover plan, a rollback plan, and a post-cutover review.
A post-handoff window for the questions that surface once you are running it.

The problem

Advisory is great until the cutover is in four weeks. At that point you do not need another opinion. You need someone in the repo with you, reviewing the data model at 11pm, running the load test on Saturday, and sitting next to your on-call when the first 10% of traffic flips.

This is where most consulting firms fall apart. Most advisors cannot code anymore. Most builders never see the pattern. The combination is rare and it is the only thing that matters when the deadline is real. Depth to know. Skill to fix.

We have watched a lot of migrations succeed and a lot fail. The successful ones all had a small group of people who cared more about the cutover than anything else on their plate that month. The failed ones had a vendor, a consultant, and a team all pointing at each other. A tiger team is a bounded commitment to care: small group, short timeline, specific outcome.

What we do

We join your team for the duration of the engagement: repo, Slack, daily standups. The work is whatever the problem is: Cassandra migration, data model redesign, performance investigation, production readiness push.

Senior operators only, drawn from a curated bench we have worked with for years
Daily standup with your team and regular written updates to your leadership
Pairing with your engineers continuously so knowledge transfers as the work happens
Cutover support: we are on the bridge, next to your on-call, not running it

We do the work and then we leave. No hidden retainers.

What you get

Working code. Written runbooks. A cutover plan. A post-cutover review. And a post-handoff window for questions that surface after we are off the clock.

The handoff is written and includes live pairing sessions for the engineers who will own the work. When we leave, your team owns what we built.

Every engagement is led by someone who has shipped production data systems for decades. We do not hand off to juniors.

How it works

We scope the engagement to the work in front of us. A two-week production readiness push and a multi-month Cassandra migration are not the same project, and we don’t price them like they are. After a triage call we send a written proposal with a defined outcome and a project fee.

Triage. A working session with your senior engineers to understand the actual problem and the actual deadline. We come out of that session with a scoped plan.

Land and build. We join your Slack, get repo access, and start producing. Daily standup with your team and regular written updates to your leadership.

Execute. The work: migration, performance tuning, data model redesign, production readiness. We pair with your engineers continuously so knowledge transfers as we go.

Cutover or launch. We are on the bridge. We are not the on-call. We are next to the on-call.

Handoff. Written runbook, pairing sessions, and a window of availability for questions that surface after we are off the clock.

Advisory is great until the cutover is in four weeks. At that point you do not need another opinion. You need someone in the repo with you.

Questions teams ask

Who is on the bench?

Engineers we have worked with for years, mostly from DataStax and platform teams at scale. We only bring in people we would hire at a company we were running. No rotating roster.

Do you carry the pager?

No. We are next to your on-call during cutover windows. The pager stays with your team. We are there to make sure they never have to lift it.

Can you start next week?

Sometimes. We run one or two active engagements at a time. If the calendar is full, we will tell you on the first call and give you an honest date.

Can the same engagement turn into a fractional CDO retainer afterward?

Sometimes, if both sides want it, and only after a clean handoff on the tiger team work. We will not blur the two.

Do you do Kafka, Flink, or other streaming work?

Yes, when the engagement is data infrastructure and the streaming layer is part of the system. We are not the right people for a pure-streaming engagement with no storage component.

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