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 →

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.
Every engagement runs in two modes, in order — and the discipline is in keeping them separate.
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.
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.
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.
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.
Pick this when the question is "where does this stand, and what's going to hurt us?"
Pick this when there's something concrete to ship and you want it built right the first time.
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.
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.
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.
Repos, a read-only environment, dashboards, docs, incident history — and your dedicated Teams/Slack space and shared workspace stood up on day one.
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.
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.
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.
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.
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.
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:
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.
Scaled to the tier, but every engagement hands over real artifacts — editable, in your repo, yours to keep:
how the system is really built today (C4 diagrams + prose), or the CLAUDE.md + .claude/ toolkit committed and enforcing.
a risk register scored by likelihood × blast radius with mitigations, or throwaway spikes that prove out the uncertain parts before the real build.
the recommended direction with the reasoning, or the architecture proven end-to-end, green and observable.
the path to the target in demonstrable slices with effort ranges.
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.
The timebox holds because the touchpoints are honored. To keep an engagement tight, I need:
An engagement is done — not "out of hours," but actually done — when:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 →