The Forward Deployed Engineer, Chapter 8: The Inner Loop — Prototype to Production

This is Part 8 of a series walking through my book The Forward Deployed Engineer. In the previous chapter, we walked discovery. This one picks up the moment discovery closes and runs through the first production milestone — the inner loop of the engagement.

The phase between the close of discovery and the first production milestone has a distinct operational shape, and it is worth giving it its own name. I call it the inner loop, in deliberate contrast to the outer loop that begins the moment production goes live (which is Chapter 9). The inner loop is tight cycles — prototype, demo, feedback, rebuild — against a stakeholder group that is still forming its view of the deployment. The outer loop is something else entirely. Conflating the two is one of the most common mistakes I see in engagements run by teams whose backgrounds are in either traditional consulting or pure platform engineering, neither of which has quite this rhythm.

The operational pattern that’s emerged for managing the inner loop is what I call DARE. It is not a methodology in the heavy sense; it is a discipline, the kind of four-phase cycle that becomes invisible once a team has internalized it. Each phase produces a specific artifact, exists to prevent a specific failure mode, and hands off cleanly to the next. The full treatment is in the book; what matters here is that the cycle exists, that it is visible to the customer as well as to the team, and that it gives the engagement a rhythm the customer can match with their own organizational cadence. Engagements without a visible cycle drift. Engagements with one converge.

Running alongside DARE is a complementary discipline I call Minimum Viable Architectures. This is not the same as a minimum viable product — that’s about what the customer sees. The MVA is about what the engineering team carries; it’s the smallest architecture that demonstrates the load-bearing technical risk has been retired. The trap is treating the MVA as a throwaway. In practice, MVAs that are built well graduate cleanly into the production architecture, and MVAs that are built badly turn into rewrites in month four. The discipline of building the MVA so that it could graduate is the discipline that separates the inner loops that ship from the ones that stall.

Demo-Driven Development and the Hardening Phase

The technique that anchors the whole DARE cycle is what some practitioners call demo-driven development, and the name slightly undersells it. Weekly demos to the stakeholder group, structured feedback capture, and the simple but underused question — “what would make you click yes on this?” — turn vague customer commentary into specific implementation tickets. The demo is a forcing function. It converts “I’m not sure about this” into “the column needs to show approver name first,” and the gap between those two sentences is where most engagements lose weeks. The FDE who can’t run a weekly demo will, in my experience, be stuck in spec-debate by the fourth week of the engagement and recovering from it for the next six.

At the end of the inner loop comes the hardening phase — the work of preparing the deployment for first production exposure. Hardening is where most engagements are tempted to cut corners, because hardening doesn’t produce new functionality and it isn’t exciting to demo. The instinct to skip it usually arrives at the same time as a customer comment about wanting to launch a week early. Saying yes to that comment, in my experience, costs roughly six months of trust later, when the deployment hits its first real failure and the customer realizes that the FDE team launched a system they hadn’t fully hardened. Saying no, kindly but firmly, is one of the most underrated soft-stack moves the role asks for.

The Customer Wants to Help, and When Things Go Wrong

One inner-loop dynamic deserves its own paragraph: the customer team that wants to participate in the build. This is usually a good sign — it means the deployment matters to them — but it has to be channeled carefully. The customer engineers will not be able to maintain whatever they help build unless the FDE team explicitly designs for that handoff, and the customer’s sense of ownership over their contributions can produce resistance to changes the deployment later needs. The pattern that works is to invite the customer team into peripheral build work (dashboards, test fixtures, eval inputs) while keeping the core architecture inside the FDE team. The pattern that doesn’t work is to let the customer team contribute to the critical path and then try to refactor around them in month six. The inner loop fails in a few characteristic ways — demo theatre, scope creep, the disappearing sponsor — and the chapter walks the early signals each one gives. Tomorrow: what happens after the first production milestone, when the outer loop begins.