What It's Like to Hire a Fractional Architect: An Engagement You Can Actually Inspect
How a fractional or contract engagement with Architect4Hire runs — from first conversation to handoff — told through OrderFlow2026, a reference build I put in the open so you can see the work before you buy it.
Most consulting relationships ask you to buy on faith. You read the case studies, you like the person on the call, you sign — and then you find out what "senior architecture help" actually means in practice. Sometimes it means a diagram and an invoice. Sometimes it means a stack of slides that never turns into code. You don't know until the money's spent.
I'd rather you know first. So I put an entire engagement in a public repository — the design docs, the architecture decisions, the delivery plan, the prompt library, and a working system built from all of it — and left it open at github.com/architect4hire/orderflow2026. This post walks you through what hiring me actually looks like, using that repo as the worked example. Not a testimonial. The artifacts themselves.
First, the honest part
OrderFlow2026 is a reference build for a client who doesn't exist. It's an event-driven order-fulfillment system I designed and built solo, and as I write this it's a proof-of-concept sitting at roughly ninety percent — fully scaffolded, mostly wired, deliberately still carrying a few TODOs where real client requirements would land.
I build these on purpose. "I do disciplined, right-sized architecture" is a claim, and claims are cheap. Anyone can put clean architecture and AI-assisted development on a slide. A public repo you can clone, read, and run is a different kind of evidence — it shows the process, the decisions, the trade-offs, and yes, the seams. I'd rather show you a real build with an honest ninety-percent label than a polished lie at a hundred. If you're evaluating me, that repo is the most useful thing on this entire site, and it will tell you more in ten minutes of reading than any sales page.
Two shapes of engagement, one way of working
People hire me two ways, and the difference is mostly about time, not method.
A fractional engagement is ongoing: a few days a month of senior architectural judgment, embedded with your team, without the cost or commitment of a full-time principal architect. It's the right fit when you have developers who can build but need someone to set direction, make the hard calls, raise the team's floor, and stay accountable as the system evolves.
A contract engagement is bounded: a defined deliverable, a fixed scope, a clear start and end. It's the right fit when you know what you need built or modernized and you want a senior hand to design it, build it, and hand it over cleanly.
Underneath, the work runs the same way regardless of which one you pick — and OrderFlow2026 is the shape of it. Let me walk you through the phases, because the phases are what you're actually buying.
How the work runs
Every engagement moves through five phases, and I scope and sequence them out loud before any meaningful money is spent. Here's how they played out on OrderFlow.
Discovery. Before I write anything, I write down what I understand — the domain, the constraints, the failure modes that matter. On OrderFlow that produced a high-level design document, C4 diagrams, sequence diagrams, and a set of Architecture Decision Records. The business value here is unglamorous and enormous: misunderstandings get caught while they still cost a sentence to fix, not a sprint. The technical value is that the design exists as a durable artifact from day one, not as folklore in someone's head.
Vision. We settle scope, service boundaries, and contracts — the shape of the thing and the promises its parts make to each other. This is where an experienced architect earns their fee by saying no to the features that don't belong in version one, and yes, but not like that to the ones that do. Right-sizing is the whole game, and it cuts both ways: sometimes it means resisting a distributed system, and sometimes — as with OrderFlow — it means the domain genuinely demands one.
Breakdown. I turn the plan into a committed library of small, disciplined prompts using my SCRUB framework, and I prove the risky path first. On OrderFlow that meant standing up the order saga's happy path before anything else, because if the orchestration spine doesn't hold, nothing built on top of it matters. You're paying for the risky decisions to be made early, cheaply, and visibly.
Development. The build. All the services, the resilience, the frontend. This is the longest phase and, counterintuitively, the one where a disciplined approach spends the least of your attention — because the hard thinking already happened in the phases before it.
Delivery. Failure-injection validation, observability, and a clean handoff: the ADRs, the diagrams, and the prompt library all updated to match what actually got built. You don't get a system and a stale description of a different system. You get a system and its true source of truth.
Discovery through Delivery, OrderFlow ran roughly six weeks, architect-only, no development squad to assemble. That's the shape of a bounded engagement. A fractional one spreads the same discipline across a longer, lighter cadence.
What you actually receive
Here's the part most consulting engagements are quietly bad at: what's left in your hands when I'm gone.
Open the docs/ folder in the repo and you'll find the durable baseline — the high-level design, the C4 and sequence diagrams, the ADRs that record why each significant decision was made, and the SCRUB prompt library that generated the code. The src/ folder holds the scaffolded, near-complete system those documents describe. The two are kept in sync deliberately, because a design that has drifted from its code is worse than no design at all.
Why does that matter to a business, not just an engineer? Three reasons, and they're all about the day after I leave.
Onboarding gets cheap. A new developer reads the ADRs and understands the system in an afternoon instead of reverse-engineering it over a month. That's real money, every time you add a person.
The design stops drifting. Six months from now, when someone asks why the payment handler is built the way it is, the answer is in a committed file with a history — not lost, not guessed at, not "simplified" by someone who didn't know what it protected against.
You own all of it. No proprietary framework you have to keep paying for, no black box, no lock-in. The architecture, the code, and the reasoning are yours. If you never call me again, you lose nothing.
The technical spine — because leadership comes in two flavors
I work with two kinds of decision-makers, often in the same room: the business leader who needs to trust that the money buys an outcome, and the technical leader who needs to trust that the engineering is actually sound. I'd be doing you a disservice if I only spoke to one of you, so here's the engineering, stated plainly.
OrderFlow is an event-driven system: an Angular front end calls an Order service, which runs a saga that orchestrates four reacting services — Inventory, Payment, Fulfillment, and Notification — over a message bus, with a Cosmos event log, a Redis read model behind the status screens, and SQL for the records that have to be exact. It runs on local emulators against the real cloud SDKs, so it boots on a laptop with no cloud spend to evaluate it.
That architecture wasn't chosen to look impressive. It was chosen because order fulfillment is a place where money moves and inventory is finite, and that forces four correctness problems that a naive build gets quietly wrong:
- A multi-step order can fail halfway. Without a compensation path on every failure, a declined payment leaves stock reserved and a failed dispatch leaves a customer charged for nothing. OrderFlow compensates on every path — the measurable target is partial-order incidents at zero.
- Payment callbacks arrive more than once. Message delivery is at-least-once by nature, so the callback will fire twice. Without idempotency, that's a double charge. OrderFlow treats duplicates as no-ops — double-charge incidents at zero.
- Two buyers can race for the last unit. Naive inventory code lets both win. OrderFlow's reservation is concurrency-correct — oversell incidents at zero.
- Designs drift from code. Without a documented, versioned baseline, the two diverge the day the build ships. OrderFlow's ADRs and prompt library are that baseline.
Notice that every one of those technical properties is stated as a business outcome with a number attached. That's not an accident. Correctness under failure isn't an engineering vanity project — it's the difference between a system that quietly erodes customer trust and one that doesn't. Good architecture is a business decision that happens to be written in code.
What it costs you — in involvement, not just dollars
I keep specific figures out of blog posts because they change from engagement to engagement, and I'd rather quote you honestly than have you hold me to a stale number. But cost isn't only money, so here's the part people forget to ask about: your team's time.
A bounded engagement like OrderFlow needs a subject-matter expert available a few hours a week — someone who can answer domain questions and make business calls when a trade-off surfaces. That's it. There's no squad to stand up, no coordination tax, no six-people-in-a-standup overhead. One senior person, working with discipline and modern tooling, carries the build. That's deliberately how I've structured the practice: senior judgment without the full-time price tag, and without asking you to reorganize your world to receive it.
Why this de-risks the decision
Strip away the specifics and here's the actual pitch, stated as plainly as I can: you can inspect the work before you commit to it. The process is written down. The deliverables are real and public. The pricing is transparent and scoped before the spend. The outcomes are measurable, not vibes. And when it's over, you own everything and owe nothing.
That's not a claim I'm asking you to take on faith. It's a repository. Go read it.
How to start
If your team is staring at a problem that needs senior architectural judgment — a distributed system that has to be correct under failure, a modernization that keeps stalling, a codebase that's drifting away from its own design, or an AI-assisted practice that isn't paying for itself yet — that's the work I do.
Fractional or contract, the first step is the same: a conversation about what you're trying to build and whether I'm the right person to help you build it. If I'm not, I'll tell you. If I am, you'll already know exactly what to expect, because you'll have read it.
Reach out at robert@architect4hire.com, or start with the repo at github.com/architect4hire/orderflow2026.
Robert Felkins is the principal architect at Architect4Hire — Chicago-based fractional and contract architecture for small and mid-sized teams. I design right-sized .NET and Azure systems, modernize the ones you already have, and bring AI-assisted development into teams in a way that survives contact with production: senior judgment without the full-time price tag.
