How this works

Fractional Engagements

Fractional is the amount of time you buy — not the amount of rigor you get. Whether it's a one-week assessment or a multi-month build, every engagement runs on the same method: a defined shape, real checkpoints where nothing gets to surprise you at the end, and artifacts you keep. You're not renting a slice of a person. You're getting a complete consulting method, right-sized to the problem in front of you and priced to match.

Start a conversation →
shape
shape
shape
shape
shape
shape
shape
shape
How this works

What "fractional" actually means

You get senior architectural judgment — a few focused days a month — without a full-time salary, benefits, or a six-month hunt to fill the seat. When the intensive work is done, we scale down instead of you carrying idle headcount. But "fractional" describes the cadence, not the depth: you get the full method every time, just sized to the problem. It's the senior call made correctly, on the rhythm your problem actually needs.

Who this is for

  • Small and mid-sized teams who need the right architecture but not a full-time architect.
  • Founders past the prototype who now need it to scale without falling over.
  • Teams mid-modernization who need someone who's done the migration before — and finished it.
  • Orgs adopting AI-assisted development who want it to pay off instead of quietly backfire in production.

The same method, whatever the size

Every engagement runs in two modes, in order — and the discipline is in keeping them separate.

Mode 1

Understand before you commit

Gather the reality, or define the machine. For an assessment that's fieldwork: meetings, interviews, access, watching a real request move through the system. For a build it's design and de-risking: settling conventions, standing up the delivery environment, and spiking the uncertain parts with throwaway code. The output of this mode is raw material and de-risked unknowns — not polished deliverables yet.

Mode 2

Prove before you scale

Then the heads-down work: synthesize the findings into an honest assessment and a costed target-state, or build the walking skeleton that proves the architecture end-to-end. This is where the value is, and it's protected — it doesn't share days with calendar-bound fieldwork, because when it does, the writing loses.

checkpoint ▶

Between the two modes sits a checkpoint, and at the end sits a readout. That's the rigor: you see the findings before they're finalized, and you leave the engagement with a decision you can fund and a team that can start. No black boxes. No surprises at the end.

Understand before you commit. Prove before you scale. That order doesn't change with the budget — only the number of sessions does.

How engagements usually shape up

Three common shapes — most start with a conversation that sorts out which one fits.

Architecture assessment. An honest — sometimes brutal — read of where your systems stand: what's working, what's quietly costing you, and what breaks first under load or change. You leave with a written recommendation you can act on, with or without me — not a 40-slide deck that says nothing.

Project-based build. A defined deliverable, scoped and shipped — a modernization slice, a greenfield platform, or a right-sized feature set. We agree on it up front and I build it with you in reviewable layers, with cost-effectiveness as the design constraint, not a slogan.

Ongoing fractional architect. A recurring few days a month: design decisions, architecture and code reviews, and hands-on building where it helps — senior judgment on the cadence the work demands. Often it picks up where an assessment or build left off, and scales down when the intensive stretch passes.

1

Architecture Assessment

Runs on: the Architecture Discovery method
What it is
A fixed-scope review of a system or a decision, ending in a written recommendation you can act on with or without me.
How it runs
Gather in the field, then synthesize and write. Sized S/M/L from ~1 week to ~1 month.
Touchpoints
Kickoff ▶ · a findings-so-far checkpoint ▶ (medium/large) · a readout ▶ that ends in a clear go/no-go.
You walk away with
A documented current-state, a ranked risk register, a right-sized target-state, a sequenced roadmap, and the readout that lets a sponsor fund it and engineers start.

Pick this when the question is "where does this stand, and what's going to hurt us?"

2

Project-Based Build

Runs on: the Development Discovery method
What it is
A defined deliverable — a modernization slice, a greenfield platform, or an AI-delivery practice stood up in your team — scoped and shipped.
How it runs
Design the machine, de-risk the unknowns, then prove the architecture on a walking skeleton — before building breadth. Sized S/M/L from 2–3 days to two weeks for the inception, then the build.
Touchpoints
Definition checkpoint ▶ (the green light to build) · plan-first approvals through the build · a harden-and-hand-off readout ▶ with a live demo.
You walk away with
A manifested engineering environment, the SCRUB prompt library, de-risking spikes, a running walking skeleton, a green CI baseline, starter ADRs, and a build-out plan for the rest of the work.

Pick this when there's something concrete to ship and you want it built right the first time.

3

Ongoing Fractional Architect

Runs on: a standing cadence
What it is
A recurring few days a month — design, reviews, hands-on building, and the senior calls as they come up.
How it runs
A regular working session, design reviews in reviewable layers, plan-first on anything non-trivial, and async progress in your dedicated space between sessions.
Touchpoints
A recurring working session ▶ · design/decision reviews as work lands · a running decision log so nothing is tribal.
You walk away with
Momentum that compounds — designs and decisions documented, standards held, the committed prompt library growing in your repo, and a team that levels up because I stay hands-on and mentor as I go.

Pick this when the need is continuous and you want senior judgment on tap without a full-time seat.

An assessment often ends by pointing at a build; a build often starts from an assessment. They're the same rigor at two points in the lifecycle.

The cadence — what it's actually like

Rigor isn't a promise, it's a rhythm. Every engagement, regardless of size, moves through the same heartbeat. On a one-week assessment it's compressed into days; on a one-month engagement each beat gets room — but none of them get skipped.

1

Kickoff

We align on goals, drivers, and the forcing function driving this, agree what "success" means, and draw the boundary: what gets assessed deep, what gets surveyed, and what's explicitly parked so nobody assumes it was covered.

2

Access & setup

Repos, a read-only environment, dashboards, docs, incident history — and your dedicated Teams/Slack space and shared workspace stood up on day one.

3

The working rhythm

Mode 1 then Mode 2, kept apart on purpose. Calendar-bound sessions for the parts that need you; protected deep work for the parts that need focus.

4

Checkpoints

A findings-so-far review (assessment) or a definition checkpoint (build) before anything is finalized. This is where misunderstandings get corrected and gaps get filled — so the readout is a confirmation, not a reveal.

5

Plan-first

Every non-trivial step is planned and approved before code, and every session comes with an agenda sent ahead and notes captured after. The plan review is the single biggest quality lever there is.

6

Readout

The decision-ready session. For an assessment: the go/no-go and the funding call. For a build: the demo of a walking skeleton running green. Larger engagements get separate exec and technical readouts.

7

Handover

Every artifact is editable and yours. Designs, decisions, diagrams, the committed prompt library, the runbook. The machine goes with you — no black boxes, no lock-in.

On a small engagement you might get one combined readout instead of two, and one checkpoint instead of three. You never get fewer standards — just fewer meetings.

Right-sized — small doesn't mean shallow

The method scales down to fit the problem. A small engagement is compressed and focused, not corner-cut. Here's roughly how the tiers land — the same logic whether it's an assessment or a build:

 
When
Timebox
Modes
Touchpoints
Depth
Small
WhenNarrow and urgent — "is this one thing going to hurt us?"
TimeboxDays to ~1 week
ModesBraided / compressed
TouchpointsKickoff + one combined readout
DepthOne focused area, proven
Large
WhenA whole estate, or a new architecture with real unknowns
Timebox~2 weeks to a month
ModesTwo weeks each
TouchpointsKickoff, checkpoints throughout, dual readouts
DepthThe whole landscape, ADRs and cost view

How to size it: most signals point to one column — that's your tier. Split across columns — take the higher one for the timebox and the lower one for scope. We settle this together at kickoff.

What you walk away with

Scaled to the tier, but every engagement hands over real artifacts — editable, in your repo, yours to keep:

A documented current-state or a manifested engineering environment

how the system is really built today (C4 diagrams + prose), or the CLAUDE.md + .claude/ toolkit committed and enforcing.

Ranked risks or de-risked unknowns

a risk register scored by likelihood × blast radius with mitigations, or throwaway spikes that prove out the uncertain parts before the real build.

A right-sized target-state or a running walking skeleton

the recommended direction with the reasoning, or the architecture proven end-to-end, green and observable.

A sequenced roadmap or build-out plan

the path to the target in demonstrable slices with effort ranges.

A readout

the session that lets a sponsor make a funding decision and engineers start.

Medium and large engagements deepen the package: a quality-attribute scorecard, starter ADRs, a gap analysis and modernization approach, an investment and cost view, and separate exec + technical readouts.

No black boxes, no lock-in. The value doesn't walk out the door when I roll off.

What I need from you

The timebox holds because the touchpoints are honored. To keep an engagement tight, I need:

A named sponsor or tech lead for the kickoff, the checkpoints, and the readout — and for same-day sign-off when a decision is on the line.
Access by day one — read-only repos, a running environment, and dashboards or traces.
The people who know the system, for interviews and walkthroughs — a few hours each, across the fieldwork.
Whatever docs exist — diagrams, incident history, ADRs, however incomplete.
Timely decisions. The single thing that blows a timebox is a sign-off that takes a week. Depth depends on access and availability.

How you'll know it worked

An engagement is done — not "out of hours," but actually done — when:

The current-state is documented and agreed by the people who own the system (assessment), or the architecture builds and runs with one command, nothing hardcoded (build).
The target-state is drawn, justified, and right-sized — every added moving part has a problem that earns it.
The risks are ranked and the "fix first" set is unambiguous, or the riskiest path is proven and visible in a trace or a passing test.
The roadmap sequences the work into demonstrable slices with effort ranges.
The investment view — including the cost of inaction — is on the table (medium/large).
The sponsor can make a funding decision and the engineers can start — or add the next feature with a short prompt, without the architecture drifting.

How we work together

Remote-first, by design. We favor Teams and Slack over on-site work unless the problem genuinely calls for a room — and with proper agendas and planning, virtual sessions are often more effective, and they save you time and travel cost.

Remote-first, not in-person by default

We work over Teams and Slack and reserve travel for the rare moments it genuinely earns its cost — a kickoff, a hard whiteboard day. Most architecture work does not need a plane ticket or a conference room, and skipping them saves you on-site days, travel expense, and the calendar gymnastics of getting everyone in one place.

Virtual meetings with an agenda and a point

Every session comes with an agenda sent ahead, a decision to reach, and notes captured after. Planned that way, a focused 40-minute call decides more than a half-day on-site would — without costing your whole team an afternoon. Well-run virtual is not a compromise; it is usually the more effective option.

Your own dedicated space to work together

Each client gets a dedicated Teams and Slack space plus a shared workspace: decisions, designs, reviewable layers, and the committed prompt library, all in one place. Your team collaborates asynchronously between sessions, so momentum keeps building instead of waiting on the next meeting.

What you can expect

I stay hands-on and work in reviewable layers.
I run the same method whether it's a week or a month — fewer sessions on a small engagement, not less rigor.
I keep the two modes separate, so the deep work that you're paying for doesn't get eaten by scheduling.
I default to remote — Teams and Slack — and only ask for in-person when the work truly needs it.
I tell you when the boring option is the right one.
I leave behind artifacts — designs, standards, committed prompt libraries — so the value doesn’t walk out the door when I roll off.
Real Talk — on fit

If a few days a month of the right senior judgment isn't enough to move your problem, I'll say so, and we won't start. I'd rather turn down a bad fit than take an engagement that can't succeed. That's not principle for its own sake — it's how the referrals keep coming.

Real Talk — on size

A one-week assessment gets the same method as a one-month one: the same kickoff, the same checkpoint discipline, the same editable artifacts at the end. What shrinks with the budget is the breadth and the number of sessions — never the standards. Small engagements are where I earn the bigger ones, so they get done properly or not at all.

Questions I get asked first

How do you hire a fractional .NET architect?

It starts with a conversation about the problem in front of you. If a few focused days a month can move it, we scope one of three shapes — an architecture assessment, an ongoing fractional retainer, or a project-based build — and get started. No lengthy intake process.

How much does a fractional architect cost?

Engagements are priced by shape rather than a single rate: fixed-scope assessments are quoted per deliverable, ongoing fractional work is a monthly retainer for a set number of days, and project-based builds are scoped to the deliverable. The point is senior judgment without a full-time salary and benefits.

How many days a month is a fractional engagement?

A few focused days a month is typical — enough to make the senior calls correctly and stay hands-on, without carrying idle headcount when the intensive work is done.

Do you work remotely, or do you need to be on-site?

Remote-first, by design. We work over Teams and Slack, with agendas and decisions captured, and reserve travel for the rare moments it genuinely earns its cost — a kickoff, a hard whiteboard day. Most architecture work does not need a plane ticket.

What does an engagement actually look like, week to week?

It runs in two modes — understand, then prove — with a checkpoint between them and a readout at the end. You'll have a kickoff to set the boundary, working sessions with agendas, a findings or definition checkpoint before anything is finalized, and a readout that ends in a decision. Between sessions, work moves async in your dedicated space.

How do you keep a small engagement from being shallow?

By compressing the method, not cutting it. A small engagement braids the two modes into a few days and lands one combined readout — but it still has a real kickoff, a scoped boundary, ranked findings, and editable artifacts. Fewer sessions, same standards.

What are the checkpoints, and how do you avoid surprises at the end?

Every engagement has at least one mid-point checkpoint where I walk you through findings-so-far and correct course before finalizing. That's the point of separating the modes — by the time we reach the readout, it's a confirmation of things you've already seen, not a reveal.

What do I walk away with?

Editable artifacts in your repo — a documented current-state or a running walking skeleton, ranked risks or de-risking spikes, a right-sized target-state, a sequenced roadmap or build-out plan, and the readout itself. No black boxes, no lock-in. The machine goes with you.

What's the natural next step after an assessment?

Usually a scoped build — kicked off by a development discovery that stands up the delivery machine and proves the architecture on a walking skeleton — or a lightweight advisory retainer while your team drives the roadmap. Or nothing at all, if "fix these first and you can drive it yourselves" is the honest answer.

Start with a conversation.

Tell me what's in front of you — the migration that stalled, the platform that won't scale, the system nobody has mapped. If a few focused days a month can move it, I'll tell you how I'd approach it. If I can't, I'll tell you that too.

Start a conversation →