OKFDE FIELD NOTES #006｜Two hundred scripts later, are we building a product?

KEY TAKEAWAY
A deployment can work well for one customer and still leave little that another team can use. After sign-off, the engineering team needs to separate customer policy from shared code, test the failure-handling components, and document what the next engineer needs to know. Customer records and confidential rules stay within the agreed customer boundary.

This article uses a fictional post-deployment project. Characters, filenames, timelines, and results are illustrative.

The repository after sign-off

The final payment has cleared. Alex has signed the user acceptance report, and Clara has sent a thank-you emoji in Slack. For two weeks, she has left at 5:30 without staying late to reconcile standard purchase orders.

Back at OKFDE headquarters on Monday, Leo opens the production branch and runs git log.

The commit history brings back a few late nights. There is

parse_clara_17tab_override_temp.py, fix_lou_soggy_manifest_ocr_v3.sh, and soap_gateway_DO_NOT_TOUCH_CRITICAL.py.

“If I copy this into the next customer’s environment,” he says, “I’ll be apologizing in their server room within seventy-two hours.”

The scripts helped get the deployment working. Some contain customer-specific decisions. Others solve problems the team will encounter again. At the moment, both are in the same repository.

Sign-off leaves Leo with another job: decide what belongs in customer configuration, what can become a supported component, and what should be retired. OKFDE calls this work reverse productization: using a deployment to improve the shared product.

He opens a refactoring branch.

01 / Separate customer policy from shared code

The first file contains Clara’s discount-validation rules. Among its if-else branches is a condition for SKU category NEW-2026 in the East Coast sales region. It raises the automatic approval ceiling to $85,000.

That is a commercial decision made for Alex’s company. Another customer should not inherit it because someone copied a Python file.

Leo moves the SKU codes, regional limits, and approval assignments into a declarative YAML configuration stored inside the customer’s private environment. The customer’s IT administrators maintain it with the relevant business owners.

Customer policy needs a clear owner. Moving a rule into YAML makes it easier to find and change, but the configuration still needs validation, review, and a record of approved changes.

The shared engine keeps the workflow mechanics: receive an event, validate its structure, gather the required context, check policy, hold an exception, request approval, and write the authorized result back to the ERP.

The approval step verifies the required signature before processing resumes. Customer-specific mappings determine who can sign and which limits apply.

This separation gives the next deployment a starting point. It does not remove the work of understanding a new customer’s systems and authority rules. “Online before lunch” is a useful ambition for a familiar setup, and a poor promise to put in a contract.

02 / Turn the timeout patch into a supported component

Next, Leo opens

soap_gateway_DO_NOT_TOUCH_CRITICAL.py.

During the rollout rehearsal, the ERP’s SOAP endpoint timed out under load. The team nearly submitted eighteen duplicate order approvals. Leo added request identifiers and a read-only status check before allowing a retry.

The emergency patch contains nested exception handlers and enough console output to keep someone busy all night. Its purpose is worth keeping.

A timeout does not establish whether the remote system completed a transaction. Retrying a write without checking can repeat the business action.

Leo extracts the handling into a versioned writeback gateway. Outbound writes pass through it, and uncertain outcomes go to a review queue.

A UUID alone does not make a write idempotent. The identifier must remain stable for the same operation across retries. Duplicate detection must work where the business change is committed, or through an equivalent transaction design. A local lock cannot establish what a remote ERP has already done.

The gateway therefore needs a reliable way to identify the operation and check the authoritative result. It records confirmed completions, allows a controlled retry only when the outcome and safety rules permit it, and holds unresolved cases for review.

Confirmed committed: record success; do not repeat the write.
Confirmed unchanged: allow a controlled retry under the agreed rules.
Unknown: hold the operation and request review.

The gateway can provide shared handling for purchase orders, invoices, and warehouse dispatches. Each integration still needs tests for its own transaction semantics and failure behavior.

Leo also extracts the review widget from Clara’s ERP screen. Customer-specific DOM selectors become adapter settings. The reusable interface keeps evidence retrieval and PDF citations, including the highlighted passage an operator can inspect on hover.

A different ERP or CRM may require another adapter. The team can reuse the interface without promising that every system will accept it in ten minutes. The four clicks saved in Clara’s workflow remain a result to check in each new deployment.

03 / Test the failures without taking customer records home

A clean PDF test set does little to prepare an OCR pipeline for Lou’s water-damaged receiving slips.

The deployment has exposed specific failures: faded stamps, skewed scans, water stains, handwritten symbols, and abbreviations in procurement messages. Leo wants those cases represented in future evaluations.

For this engagement, customer records stay inside the customer’s environment. The team cannot copy invoices or screenshots back to headquarters simply because they would make useful test cases.

Leo uses an isolated local sandbox to describe the failure patterns, including Lou’s twelve shorthand symbols. A generator creates 1,200 fictional manifests and invoices with invented company names, SKU codes, and amounts. It applies the relevant visual distortions and message variations.

The team reviews what can be reused outside the customer environment. Synthetic data still needs checking for copied identifiers, confidential rules, or details that reveal the source records.

The approved examples become part of the regression suite. Model and OCR changes must pass the agreed checks before release.

The suite gives the team a repeatable test for known failures. It cannot establish that every document the next warehouse produces will be handled correctly. Lou has already supplied enough variety for one release cycle.

04 / Write the instructions the next engineer will need

By Friday, the refactored components and evaluation suite pass their checks. Leo opens the engineering wiki and creates The Forward Deployed Field Playbook v2.0.

The playbook covers work that cannot be inferred from the code.

On the first day, sit beside an operator. Count the window switches and identify the spreadsheets people use to finish the job. Discuss the required access with IT before requesting production write credentials.

During policy review, identify the owners of the rules and record their approval. Finance and Legal need to see how a transaction is authorized, logged, and checked after a timeout. A model benchmark answers a different question.

Before launch, rehearse in read-only shadow mode. Test the writeback failure paths and give operations an accessible stop control, with clear instructions for pending work and recovery. A button on a screen is an administrative control; it does not become physical isolation because someone labels it a kill switch.

After deployment, review customer-specific code, configuration, and test cases for reuse. The source playbook places these activities at Day 1, Week 2, Week 4, and Day 45. Those are planning points for this example, not a schedule every engagement can follow.

Leo adds one final reminder: when a database field contains final or v2, check the scheduled job that updates it before relying on its contents. A confident explanation from the architect is welcome. A recent successful run is more useful.

He publishes the playbook so the next engineer can find the procedure without calling him at midnight.

What the customer paid for

On Friday evening, Leo merges the refactor into main. The two hundred customer-specific scripts no longer sit inside the shared platform. Their reusable functions are covered by the versioned execution engine, writeback gateway, and 1,200 synthetic regression cases. The customer’s private rules remain in its configuration.

His backpack is beside the desk, with the Ethernet cables and power adapters packed for Monday’s visit to another customer.

The next team will still have to learn that customer’s workflow. It will arrive with tested components and instructions for problems Leo has already encountered.

Alex’s review of the handover

After making the final payment, Alex spends three hours with the CFO reviewing what the company has received. The working system is only part of the handover. They also need to know who can maintain it when the deployment team leaves.

Their review focuses on three questions.

Can we manage our own rules?

The regional discount limits and new-SKU approval rules sit in configuration on the customer’s servers. Operations and IT can review them without asking a vendor to find the right branch in a Python file. Ownership and reuse rights still need to be set out in the agreement; a local file alone does not settle them.

Did our records stay within the agreed boundary?

In this engagement, real purchase orders and supplier invoices stayed inside the customer environment. The team used reviewed synthetic examples for the shared evaluation suite. Alex wants that boundary to be part of the handover evidence, alongside the process for approving any future data use.

Who supports the components left behind?

The writeback gateway and audit records have versions, tests, and operating instructions. Alex needs to know who owns updates and incident response. A reusable component helps the customer only if someone can maintain it.

These questions make the deliverables concrete. They also make it easier to replace a supplier without losing control of the workflow.

Next / Field Notes · 007

When an AI workflow starts moving money

Alex wants to connect the workflow to the banking API for supplier payments and tax reconciliation. Victor, the CFO, wants to see who can authorize a transfer and how Finance can trace it afterward. The next issue examines approval controls, separation of model output from payment execution, and the audit record needed to investigate a transaction.

ABOUT OKFDE

OKFDE is a research, engineering, and talent platform focused on Forward Deployed Engineering for enterprise AI. We turn lessons from real-world deployments into practical methods for delivering, operating, and improving AI systems.

Train. Build. Deploy.

For enterprise deployment inquiries, workshops, or field research:

leo@okfde.net