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
- 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.
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.
| 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 |
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.
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.
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.
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.