YakData

The YakData forward-deployed engineering method

The FDE Control Loop

You know the business problem, and AI coding tools get you a working prototype fast. The FDE Control Loop is what comes next: turning that prototype into a system that survives real data, real users, failures, security, and business rules.

Explore the loop See it on a real build →

A forward-deployed engineer owns the whole path, from the business problem to the system running in production. You do not need to be a specialist in every layer. If you can reason about the business, user interfaces, data, and code, you can own that path. AI speeds up the build. It does not make the system design decisions for you.

The system design rule

AI is one part of the system. It is not the whole system.

Use AI for interpretation, extraction, ranking, and drafting. Keep rules, calculations, permissions, saved information, and human decisions explicit around it. If fixing every problem means rewriting one giant prompt, split the system into clear parts.

DataInputs, structure, transformations, quality
AIInterpret, extract, rank, draft
Rules and logicScoring, thresholds, calculations, business logic
Behind-the-scenes logicServices, connections, saved data
InterfaceWorkflow, review, evidence, override
PeopleJudgment, verification, accountability

The FDE Control Loop

Seven stages. One closed loop.

Each stage answers one question and produces something concrete. Real use produces evidence, and the evidence takes you back to value.

The loop closes here. Evidence from real use goes back to the value, not to the backlog.

Testing runs across the entire loop
Meets the goal Parts agree Small parts Major parts Features work Parts work together Whole path Old fixes stay fixed Failure behavior
1

Value

What is worth changing, who owns it, and how will we know it worked?

Stage 1

What you leave with

  • A specific business outcome or recurring decision
  • A named owner who cares about the result
  • The consequence in money, risk, time, or quality
  • Acceptance evidence agreed before broad implementation
  • A clear Version 1 boundary

If you skip it

You can build good software for a weak problem. The engineering works and the business still has no reason to adopt it.

2

Context

How does the work happen today, and where must the system fit?

Stage 2

What you leave with

  • The current workflow before and after the system
  • Who uses it, reviews it, and acts on it
  • The inputs people already rely on
  • The actual environment: office, field, shared, executive, or individual
  • The constraints nobody wrote down

If you skip it

A technically correct system that fights the way people work. The demo goes well and nobody uses it.

3

System

What are the parts, what belongs in AI, and what must stay explicit?

Stage 3

What you leave with

  • A map of the important parts of the system
  • A clear boundary around what AI should and should not decide
  • Explicit rules, calculations, thresholds, and permissions
  • Clear rules for what each part sends and receives
  • A decision about what must be saved and what can remain temporary

If you skip it

The model becomes the architecture. Every problem turns into a prompt change, and the business logic ends up somewhere you cannot test it.

For AI-assisted builders. Make the AI return a predictable format, check it before using it, and keep tool choices and handoffs explicit. AI gets one defined role in the system. It does not get to control the whole design.

4

Complete path

Can one real case travel through the entire system?

Stage 4
  1. Input
  2. Context
  3. AI / logic
  4. Backend
  5. Interface
  6. Human action
  7. Output

What you leave with

  • One real case on representative data
  • The smallest complete end-to-end path
  • Enough interface to use the path, not a polished product
  • A first end-to-end test that already passes

If you skip it

You get impressive pieces that have never worked together. Making the parts work together stops being a step in the plan and becomes the project.

Complete does not mean finished. A first path is usually a minimal interface, one working connection to the system logic, one place where results are saved, and one real case from start to finish. Cross every important layer before adding breadth.

5

Build out

Now that one complete path works, what do we add?

Stage 5
DataCollecting, cleaning, structuring, quality
IntelligenceModels, context, tools, rules, calculations
ApplicationBehind-the-scenes logic, interface, workflow, saved information
ConnectionsCompany systems, outside tools, internal services

What you leave with

  • More capability built against a working spine
  • Different parts moving in parallel where dependencies allow
  • Tests that grow with the code instead of appearing at the end

If you skip it

The lanes run in sequence and each one waits on the last. The risk that the parts will not work together stays hidden until the end, where it costs the most to fix.

6

Production

What does this system actually need to run reliably for real users?

Stage 6
User identityPermissionsConnectivitySaved dataHistoryFilesSafe updatesScheduled data loadsLive eventsAPI keys + secretsSecurityAI quality checksUsage limitsBackup behaviorLogsHealth metricsRecoveryRelease

What you leave with

  • Only the production capabilities the system truly requires
  • A reason for each important capability included or left out
  • Known failure behavior and a recovery path that has been tested

If you skip it

One of two bad outcomes. A prototype pretending to be production, or an enterprise stack that delays a simple system for months.

Production is not a bigger prompt. It is the right mix of access, secrets, input checks, monitoring, backup behavior, recovery, and human override for the consequence this system carries.

7

Real users

What do real users teach us that tests cannot?

Stage 7
Testing asks

Does the system behave the way we expect?

Real use asks

What did we not know?

What you leave with

  • A small group of real users doing real work
  • Usage signals, defects, workflow friction, and model failures
  • Rapid feedback on what helps and what gets in the way
  • A short observation window, often two to four weeks
  • Expansion and deferred features decided from evidence

If you skip it

You discover the unknown problems at full scale, in front of the whole organization, when learning costs the most.

Return to value

Did the system create the value we started with?

Close the loop
ExpandImproveRedesignNarrowReplaceStop

What you decide

  • What changed in the real business outcome
  • What the evidence says about the original assumptions
  • Which of the six next moves is justified

Why the loop matters

A backlog always wants more work. The loop makes the next move, including stopping, compete against business value again.

Stage 1 of 7

When the prototype becomes a system

The prototype is not the problem. Keeping the prototype design for production is.

AI tools make the first working version far faster. Production begins when you separate responsibilities, validate outputs, test failures, and put the system in front of real users.

Fast prototype pattern
  1. Giant prompt
  2. Prompt tweaks
  3. Raw model output
  4. Features first
  5. Happy path

Fast to create and useful for learning, but fragile once messy data, unusual cases, permissions, and real users arrive.

FDE production response
  1. Separate responsibilities
  2. Validate outputs
  3. Complete path
  4. Failure tests
  5. Limited release

Keep the speed. Add explicit logic, clear handoffs, tests, recovery, and real-user evidence before you broaden the system.

Responsibility lanes

The work overlaps. One person keeps it connected.

Product, user experience, frontend, backend, and testing are responsibility lanes, not a waterfall. You do some of it yourself and bring in specialists where depth matters.

ProductOutcome, scope, workflow, acceptance
User experienceReview behavior, exceptions, human control
FrontendWhat users see, click, and experience when things fail
BackendData flow, rules, AI connections, saved results, monitoring
TestingWhat must work, edge cases, repeat tests, release evidence

The forward-deployed engineer keeps the lanes connected. The job is not to be the best specialist in every lane. The job is to keep the business outcome, the system, the tests, and the operating reality connected.

Who this is for

Become the person who can carry an important problem all the way to production.

For business-strong builders and engineers who already make software with AI tools, user interfaces, data, and code, and want the systems discipline that makes it dependable.

  • Business-strong AI builderYou understand the workflow and use tools like Cursor, Claude Code, Windsurf, Lovable, or v0 to make working software.
  • Engineer ready to own moreYou want to move past individual tasks and take the full path from business problem to a production system people can run.
  • Thinks across the systemYou can reason about how data, AI, rules, behind-the-scenes logic, the interface, testing, and people fit together, even where specialists go deeper.
  • Knows when to get helpYou can tell when security, infrastructure, or data engineering needs real expertise.

Before you put it in front of users

Audit your system against the FDE Control Loop.

The one-page FDE Production Readiness Checklist finds missing handoffs, tests, operating controls, and real-user evidence before they turn into production failures.

Download the checklist
1-page checklistMarkdown + spreadsheetUse it on your current build
Free asset FDE Production Readiness Checklist Download the readiness checklist

Email only. No account required. Unsubscribe anytime.

By subscribing, you agree to receive FDE Lab email from YakData. See Privacy.

Building something now?

Run your system through the loop.

Production Reviews takes one non-confidential piece of your system and one consequential decision from work you already own, then finds where your system is strong, weak, or incomplete.