Case Study · Commercial delivery

A commercial RACE Programming delivery

A fixed-price, end-to-end product delivery for a US-based supply-chain client, run in the shape of RACE Programming: a working prototype produced between sales calls, a foundation-level redesign absorbed mid-engagement, and four Definition-of-Done gates kept green every Stint.


Before and after

Before

  • A two-page methodology describing the math, not a specification.
  • No defined user experience, data sources, or workflow.
  • Conventional path: a discovery sprint, scoped requirements, and a multi-month statement of work.
  • A foundation-level scoring change would mean a multi-sprint replan and a months-long change cycle.

After

  • A working, production-shaped prototype delivered between sales calls, before the contract was signed.
  • Proof-of-concept to production in about three months, fixed-price.
  • A mid-engagement foundation redesign absorbed in roughly ten days, without contract renegotiation.
  • Four Definition-of-Done gates green every Stint; the client moved to a paid follow-on engagement.
What is being sold

The price basis is judgment, not typing

AI-augmented delivery is not faster typing. It is a different unit of work. What First Line Software bills is the engineering judgment that decides what gets shipped, the architecture that makes shipping safe, and the production accountability carried on a fixed-price basis. The AI is a tool inside that envelope. Clients pay for the envelope; velocity is a benefit of how the work happens, not the price basis.

The engagement at a glance
Sector Supply-chain operations, US-based client
Engagement End-to-end product delivery, fixed-price
Team Three people (one Forward Deployed Engineer, one AI Product, one Pit Crew Software Engineer) working with the Silicon Software Engineer (the AI agent)
Duration Approximately three months, proof-of-concept to production
Stack React, Python, Ridge-regression ML
Headline outcomes Working prototype delivered between sales calls; product shipped to production; mid-engagement foundation-level redesign absorbed within scope
The challenge

A two-page methodology, not a spec

The client arrived with a two-page methodology: a tool for AI-augmented management of purchase orders, combining heuristic supplier-reliability rules with a machine-learning layer that improves with decision data. The methodology described the math. It did not describe the user experience, the data sources, or the workflow. A traditional Scrum delivery would have opened with a discovery sprint, scoped requirements, and a multi-month statement of work. The client needed something more direct.

The team and method

Three roles, aligned to the framework

The engagement was run with three roles aligned to RACE Programming. The engagement and the framework's formalisation developed in parallel through 2026; the team operated with the framework's core ideas as they were taking shape.

  • Forward Deployed Engineer owned the Pit Wall: architecture, the client relationship, and the working prototype.
  • AI Product owned specifications, client communication, and UI/UX prototypes, bridging Pit Wall and Pit Crew.
  • Pit Crew Software Engineer owned implementation, the Definition-of-Done gates, and the daily Inner Cycle with the AI agent.
Three proof moments

What the model produced in practice

1. A working prototype between sales calls

Before the engagement contract was signed, the team delivered a working web application that ran the client's methodology end-to-end on synthetic data, with a step-by-step ML training visualisation, embedded methodology explanations, and a production-shaped architecture (React front end, Python back end, proper separation of concerns). The structural decisions in the prototype (the architecture, the methodology page, the embedded user guide) survived the transition to production. The throwaway parts (synthetic data, no persistence, no authentication) were replaced cleanly in the weeks that followed. The prototype was production-shaped, not just fast.

2. A foundation redesign in days, not months

Mid-engagement, the client returned with a sharper version of their own scoring framework: a foundation-level change to how the engine weights operational features. In a traditional engagement this would have meant a multi-sprint replan, a scope renegotiation, and a months-long change cycle. Here the change-request analysis, the planning documents, and Phase 1 in production were completed within roughly ten days. Concentrated work, not concentrated calendar, and the client absorbed the change as additional paid work without contract renegotiation.

3. Four DoD gates green every Stint

The Pit Crew Software Engineer held the Definition-of-Done gates (unit-test coverage at or above 80%, integration tests, end-to-end tests, and acceptance tests) green across every Stint, evidenced by continuous-integration history and pull-request descriptions in the repository. The senior engineering skill the team grew through the engagement was validation: reading AI-generated code and deciding what is structurally right, not merely what passes tests.

The outcome

Shipped, and extended

The product shipped to production in about three months, and the client moved to a paid follow-on engagement. The mid-engagement foundation redesign, initiated by the client's own self-correction rather than in response to a team mistake, was absorbed and delivered without commercial friction.

Beyond contracted scope, the engagement also delivered multitenancy infrastructure, an Excel import system with field-level guidance, an embedded user guide, and a methodology page documenting both the heuristic and ML components, all supplied as production-shaped extras within the existing engagement envelope.

RACE Programming, demonstrated in commercial delivery. For engagements that need to move fast without losing engineering rigor, First Line Software delivers in the shape of the RACE Programming framework.

Read the framework → · More case studies →

FAQ

Frequently asked questions

What was delivered in this RACE Programming engagement?
A US-based supply-chain client engaged First Line Software for end-to-end, fixed-price delivery of an AI-augmented purchase-order management product. A three-person team (one Forward Deployed Engineer, one AI Product, one Pit Crew Software Engineer, working with the Silicon Software Engineer, the AI agent) took the product from proof-of-concept to production in about three months. The client then moved to a paid follow-on engagement.
How fast was the working prototype produced?
Before the engagement contract was signed, First Line Software delivered a working web application that ran the client's methodology end-to-end on synthetic data, with a step-by-step ML training visualisation, embedded methodology explanations, and a production-shaped architecture (React front end, Python back end). The prototype was production-shaped, not throwaway: its structural decisions survived into production.
How was a mid-engagement foundation redesign handled?
Mid-engagement, the client returned with a sharper version of their own scoring framework, a foundation-level change to how the engine weights operational features. In a traditional engagement this would have been a multi-sprint replan and a months-long change cycle. Here the change-request analysis, planning documents, and Phase 1 in production were completed within roughly ten days, absorbed as additional paid work without contract renegotiation.
What does RACE Programming bill for, if not raw speed?
The price basis is engineering judgment: deciding what gets shipped, the architecture that makes shipping safe, and the production accountability carried on a fixed-price basis. The AI is a tool inside that envelope. Velocity is a benefit of how the work happens, not the unit the client pays for.