The implementation “factory”
For vertical AI platforms like Kintow, implementation is the bottleneck. Customers just want the work done, and it’s our job to mitigate the friction in going from demo to working system. But our customers are small and their ACVs don’t allow for customer-specific, labor-intensive work.
There’s been a lot of discussion of building software factories as pipelines that go from customer request to ticket to pull request to production. AI-produced software has followed roughly this trajectory: fancy auto-complete within a developer’s IDE, to AI that edits code synchronously with the user, to agents that take high level product directives and produce pull requests. The trend is AI coding (and, therefore, the developer) operating at increasing levels of abstraction.
The same now goes for software implementation. The starting point is humans implementing each component of the system. Synchronous AI makes each of these tasks less cumbersome. And then agents take increasingly higher-order tasks until the system is self-implementing. The time-to-value collapses for the customer, and the vendor’s implementation costs are denominated in tokens. That’s the holy grail.
Modeling implementation factories on software factories
Agents have penetrated software more than any other domain. There are two pretty clear reasons: first, code lives in self-documenting git repositories that provide rich context; second, automated tests make each new commit verifiable. A powerful set of harnesses has grown around these two properties (like Claude Code).
The more Kintow’s implementation agents resemble coding agents, in their context and verifiability, the more the software implements itself.
Invoices as git history
Invoices are the git history of a business’s back office. They tell the story of the vendors, SKUs, stock levels, prices. And more specifically for the restaurant back office, they let you figure out cases and pack sizes, which informs how ingredients should be inventoried. An accurate reading and interpretation of a new invoice lets the implementation factory correctly update the system.
We can think of this as an inference problem. The goal is to update the system given its current state and the new invoice. It’s the new brand of Oat Milk added to the “Under Counter Fridge” inventory sheet. A mis-parsed unit of measure results in the next inventory count triggering the wrong quantity to order and stocking out on a busy Saturday morning.
Context and harnesses are what make agents effective in a domain. Alongside their instructions and skills, coding agents have the git history; Kintow’s implementation agents have the invoices. Developers approve commits after running them through a series of tests to prevent bugs. The implementation factory uses content-based routing to inject vendor-specific prompts, and an assembly line of agents that judge where and how to update the system.
Even small errors compound and poison the context. But each invoice we parse makes the next one cheaper and more accurate. The compounding happens at the data layer, with the increasing context we can provide; and in the litany of consistency problems we’ve squashed over time.
Why it changes the game for restaurant back office software
The bottleneck of all restaurant back office software is implementation. To understand what makes the problem so hard it’s worth stating it clearly. Restaurants are like mini factories. In come the supplies, out go the croissants. The back office software (like Kintow) coordinates what to make, what to order, and measures precisely how much it costs. The map of inputs is vast and tedious.
Incumbents like MarginEdge and R365 charge hefty implementation fees, so that they can throw humans at the problem. Look at MarginEdge’s recent $80mm raise.
Sometimes, the AI tools do not read handwriting accurately on the average 300,000 invoices per week across 12,000 restaurants including Cava and Maman. That’s why MarginEdge employs hundreds of people — to ensure that information is gathered accurately, per Davis… “We needed humans in the loop from the beginning,” Davis said, “to provide the level of quality we wanted.”
Their commitment to accuracy is admirable, but the high-touch nature of onboarding makes the CAC/LTV unfavorable and leaves a large portion of the market un-or-underserved. Starting from invoices as the primary change log of the business, we’re building an implementation factory that bends the cost curve and lets restaurants serve themselves in the back office for the first time.