The Demo Worked. Production Was the Real Job

A team usually calls an experienced engineer too late.

The deadline is close. A customer or investor needs to see something working. The requirements are incomplete. Several people have discussed the problem, but nobody owns the full path from input to outcome.

At that point, the first job is not to design the final platform.

It is to build the smallest legitimate version that proves the workflow can work.

That is the demo.

The second job is harder:

Turn the working path into a system people can depend on.

That is production.

I work across both stages. I can reduce an unclear problem, implement the full path, and then harden the parts that fail when real users, malformed data, retries, permissions, external services, and operational pressure arrive.

A Demo Answers One Question

A useful demo answers:

Can this idea produce the intended result?

For an automation, the first path may look like this:

input
  -> process
  -> decide
  -> perform action
  -> return result

That path matters. Until it exists, most architecture discussions are speculation.

A working implementation exposes the real constraints:

• which data is actually available
• which integration is unreliable
• where the business rule is ambiguous
• which step dominates latency
• which output the operator really needs
• which exception breaks the entire flow

The demo is not disposable. It is an instrument for discovering the system.

But a demo usually contains hidden assumptions:

• the input is valid
• the dependency responds
• the action is authorized
• the operation runs once
• the model returns the expected structure
• the operator notices a failure
• damaged state can be repaired manually

Production removes those assumptions one by one.

The Production Gap

A prototype may be correct on the happy path and still be unsafe to operate.

Consider a simple automation:

Find stale records and delete them.

The first implementation can be short:

DELETE FROM records
WHERE created_at < NOW() - INTERVAL '90 days';

It works.

It also leaves the important questions unanswered:

• What qualifies as stale?
• Which records are under audit hold?
• Can one malformed status cause a large deletion?
• What happens when the job runs twice?
• How will an operator know the candidate count increased 40 times?
• Can deleted state be recovered?

The demo proved that deletion is possible.

Production requires a safer workflow:

select candidates
  -> validate invariants
  -> compare with normal volume
  -> cap the batch
  -> record evidence
  -> execute
  -> verify result
  -> preserve recovery path

The added steps are not ceremony.

They define the boundaries of being wrong.

My Sequence

I use a simple sequence when a team needs speed without creating avoidable fragility.

1. Find the fixed constraint

What cannot change?

It may be a deadline, an existing API, a deployed contract, a customer promise, a data format, a legal boundary, or a system that cannot be paused.

Naming the fixed constraint makes the problem smaller. It prevents time from being spent on solutions the situation cannot accept.

2. Isolate the state transition

What exact change creates value?

Not “build an AI platform.”

Maybe:

Turn each support request into a validated priority and route it to the correct owner.

Not “improve infrastructure.”

Maybe:

Stop the same expensive calculation from running five times inside one request.

The narrower the state transition, the faster a working path becomes visible.

3. Implement the shortest legitimate path

The first version should be small, but not fake.

It should use real inputs, produce the real output, and exercise the integration that carries the most uncertainty.

Mocking everything produces a presentation, not evidence.

4. Attack the assumptions

Once the path works, I look for the conditions the demo quietly relied on:

• What if the request is duplicated?
• What if one item is malformed?
• What if the provider times out after completing the action?
• What if a credential is compromised?
• What if the model returns valid JSON with the wrong item IDs?
• What if the candidate count is unexpectedly large?
• What if the operator approves a conclusion without seeing the evidence?

These questions define the hardening work.

5. Put boundaries outside unreliable components

Prompts, models, users, external APIs, queues, and retries can all behave unexpectedly.

The reliable boundary belongs in application code and infrastructure:

• strict schemas
• narrow tool contracts
• permission checks
• idempotency keys
• rate and cost limits
• bounded batches
• timeouts
• explicit stop conditions
• approval for high-impact actions

The component may propose an action.

The system decides whether the action is allowed.

6. Leave operational evidence

A production system must answer:

• What happened?
• Why did it happen?
• Which version made the decision?
• Which inputs were affected?
• Which validation checks passed?
• Was the operation retried?
• Can the result be reversed?

Logs are useful only when they preserve the evidence needed to operate and investigate the system.

7. Make failure recoverable

Retries are not a recovery strategy by themselves.

A reliable v1 needs the smallest practical recovery unit:

• retry one item instead of an entire batch
• quarantine before permanent deletion
• invalidate one credential instead of redeploying every service
• roll back one release
• replay from an idempotent event
• compare the new path against the old path in shadow mode

Recovery changes an incident from improvisation into a known procedure.

What I Deliberately Avoid

Urgency creates pressure to add impressive machinery quickly.

That is often the wrong response.

I do not add Redis before proving shared caching is required.

I do not create a general agent tool when one narrow operation is enough.

I do not hide uncertainty behind a flexible interface when the operation can destroy data or move money.

I do not optimize token price if the cheaper path breaks the delivery promise.

I do not call a system secure because one preventive control exists.

Every new component creates another dependency, credential, failure mode, dashboard, and operational obligation.

Complexity is justified only when it closes a measured gap.

The Definition of Done

A demo is done when the intended path works.

A reliable v1 is done when the team can answer:

1. Which inputs are accepted?
2. Which actions are authorized?
3. What must remain true during failure?
4. What is the maximum blast radius?
5. How does unusual behavior become visible?
6. What happens when the operation is repeated?
7. Which evidence remains afterward?
8. How is damaged state recovered?
9. Who owns the response?
10. Can the system be changed without guessing what happened before?

Not every v1 needs enterprise infrastructure.

Every v1 needs explicit operating boundaries.

The Work I Am Built For

The most useful time to involve me is when the problem is urgent but still poorly shaped:

• a manual workflow needs to become automation
• an AI prototype needs production boundaries
• a product demo must become a real service
• an existing system is slow, fragile, or expensive
• a small team needs one person to own backend, integrations, deployment, and reliability

I do not separate execution from architecture.

I build the path, observe where it breaks, and harden the boundaries that matter.

That is how an idea becomes a demo—and how a demo becomes a dependable v1.