The value Velocity Curve gives us is that things which were never going to make it onto our list are now on it, and in production. We run more AI in daily operations than most companies in specialty food distribution, and people in our industry are consistently surprised when they see how much of it is live. That is a direct result of this collaboration.
How the change happened
GFM (Gourmet Food Marketplace) is a US B2B platform for specialty foods with 3,500 products. Its team has felt the bottlenecks and growing pains that come with rapid growth.
Not hard, just a lot of it
When we met GFM, the team was running 3,500 products and listing about 70 new ones every week. Listing, sorting, replenishment, pricing against sales velocity and shelf life, catalog updates, inbound and outbound scheduling, customer service — none of it is hard, but all of it is work, and together it took about 130 hours every week.
The real problem is that the work scales with the catalog, not with the team. Add enough products and a small or mid-sized business drowns in its own growth.
B2B is not rocket science. It is a massive number of small workflows, every one of which has to be carried out correctly, because one mistake upstream turns into dozens downstream. When each of those workflows costs four or five hours a week, they add up to your SG&A. In a labour-intensive business like ours, that is what growing pains look like.
We didn't build the tools — we made them buildable
The first time we sat down with GFM, we said plainly that we were not there to build them a tool. We were there to give the people who know the industry best the ability to build the tools they need themselves.
Instead of writing a spec for an engineer and then paying for weeks of waiting, they vibe code the tool they need in the afternoon and use it by early evening. What mattered was not what we did while we were at GFM — it was that after we left, those tools folded seamlessly into the way their people work.
He was not there to build us a specific tool. He was there to give the people with domain knowledge the ability to build their own, so that we could create whatever our industry needs without waiting on anyone. In other words, what mattered was what would happen after they left.
The reason it worked is that they treated us as capable of doing this ourselves. They did not sell us a system and a maintenance contract. They built the foundation, showed us the method, and left.
Building a tool is not the same as running one
Staff built their first tools quickly, then hit a ceiling: a tool only ran on the machine of the person who made it, data would not sync across the system, and every tool pulled its own figures, so the numbers disagreed. Being able to build a tool had solved the question of function, not the question of how that function runs across a company.
So we built GFM a layer of infrastructure, one that lets a finished tool deploy safely to the cloud and be used company-wide the same day. In this architecture the company's data and code each have a designated place to be used from, and when something breaks, someone knows.
What Vincent and Joanne built for us can be compared to a safe playground: a place where we can develop tools for the many jobs at hand and deploy them in a secure environment. Our customer-service agents now handle more than 90% of customer-service work automatically, and we have agent systems that check and monitor each other and raise an alert when something goes wrong. These agents run around the clock and become smarter with every interaction and every piece of human feedback. Vincent and Joanne gave us fishing rods, not a reason to keep buying fish from them.
Growth no longer means more hands or more stockouts
Every new SKU has to be onboarded, listed, merchandised, received at the warehouse, replenished, and repriced as it ages. None of those steps is hard, but add enough products and the volume alone will bury a small or mid-sized business.
That is exactly what didn't happen. GFM expanded the catalog aggressively and came out with a higher in-stock rate, a more efficient operation, and more capacity to take on the next thing, not less. The agents absorbed the incremental work. The people went out and found more producers.
We expanded the catalog aggressively and came out the other side with a higher in-stock rate, a more efficient operation, and more capacity to take on the next thing, not less. The agents absorbed the incremental work. The people went out and found more producers. Growth used to mean either more hands or more stockouts. Now it means neither.
Fractional CTO: leave the technical judgment to us
Once the infrastructure was done, we changed roles and became GFM's fractional CTO. GFM still has work to hand to outsourced teams and part-time engineers, but the company has no full-time technical lead, and it makes no sense to hire one just to manage a few contractors. All of this used to land on Rebecca, who could keep track of progress but could not always tell whether the work was right or the choices were reasonable. Now we interview new hires, assessing their technical skill and experience as well as how they communicate and collaborate. We sit in on the day-to-day development meetings, review the architecture and security, and manage anything touching access and security. We also decide which technical debt gets dealt with first and which can wait.
For an owner, the difference is twofold. First, a lighter load: no more watching every task personally, or forcing a call on a technical question you are not sure about. Second, better-informed decisions: which option carries risk, which will cost more, and which requirement has a cheaper route are all known before the decision is made.
Tools GFM is using now
Ten jobs, before and after the agents. Each measured row is drawn against its own before: the hatched part is the work the agent took, navy is what is left
Before the agentAfter the agent
- Product launch
- 45
- 6–10min / product
- Receiving reconciliation
- 25
- 5hrs / week
- Replenishment
- 20–25
- 5hrs / week
- Merchandising
- 15
- 2hrs / week
- Customer service
- 10–15
- 2–3hrs / week
- Route planning
- 5–7
- about 3hrs / week
- Pricing research
- Manual lookup
- Researched at launch
- Markdown & revert
- Ad hoc
- Weekly, one click in Slack
- Markdown auditor
- Unverified
- Every change checked
- Warehouse slotting
- Manual
- Coming online
The AI infrastructure's four cores
Data security
AI can use the data, but not touch the core
We built the AI agents a database and an API service of their own, separate from the main product's database: the agents get current business data, but they cannot touch the core database or the transaction logic. That is the line between efficiency and risk — however many tools get built, and however often they run, none of them can affect the system that is currently selling.
Maintainability
Tools stay with the company, regardless of who leaves
We taught the team to use GitHub, and had the AI agents sync finished code to it automatically. A tool is no longer tied to one person's computer: anyone can deploy it, take it over, and read what it does. It used to be “it's on someone's laptop”; now it is “it's in the company's repository”.
Access control
Strict access control, clear accountability
Internal tools are usually the least protected thing a company owns: one URL, and whoever has it can use it. We added account management and permissions to every tool, so data reaches only the people it should — and access can be taken back when someone leaves or moves on.
Monitoring
When something breaks, someone finds out
The dangerous failure in automation is not the one that raises an error — it is the one that doesn't. A tool quietly produces the wrong result, nobody notices, and it reaches data that matters. We added monitoring and alerting, so a problem is caught and fixed the moment it happens.