A trade association runs an afternoon on AI for manufacturers, and every case study on the screen belongs to a company whose logo your suppliers already know. A platform team of a dozen people. A pilot budget larger than your last capital purchase. A slide that says the tool paid for itself within the year, from a company that could have absorbed a year of it not working. You run forty people. There is no platform team — there is a person who does the accounts and, this quarter, also fixed the printer. You leave the room with the correct impression that none of this was built with you in mind, and go back to running the business the way you were before lunch: from memory, from a spreadsheet, and from whoever picked up the phone last.
Why we build it this way
Most AI transformation plans assume a buyer who already has something to integrate against — an IT department, a data team, a compliance function that can write the policy before the pilot starts. That is a reasonable assumption for a company with a thousand employees. It is a bad one for a business your size, because it means the entire category of getting value from AI is priced and staffed for headcount you do not have and are not going to hire.
The obvious answer is a cheaper, smaller version of the enterprise product. That does not fix it, because the design is still built around integration — it assumes six systems worth connecting, when what you actually have is one shared inbox, a phone, and a spreadsheet the founder trusts more than anyone should. Shrinking the price does not remove the assumption that somebody is available to do the connecting.
We did not take the enterprise plan and make it smaller. We started from a company with no platform team and asked what it could run on one box.
So the plan for a business of forty people is not a scaled-down version of the plan for a thousand. It is the same thesis — a company that knows what it knows, a record that grows as a by-product of the work, hardware the company owns — built from the smallest unit that thesis can run on: one server, one record, no integration project.
How it works, roughly
On that one box, the systems a business runs on day to day — mail, drive, the sales pipeline, projects, hiring — share the same record instead of six separate logins each holding a slice of it. It reads:
- The mail and the drive, so nothing important lives in a folder only one person can find
- The calls and messages where a deal actually gets discussed, not just what someone typed in afterwards
- A quote or a drawing as it arrives, however it arrives — a photograph, a PDF, a scan off a fax
What comes back is a pipeline that is true because nobody had to type it in, and a draft that names the email or drawing it drew on, so checking it costs a minute instead of an afternoon. The part that would once have needed a hire is that someone who is not a programmer — a planner, an office manager — can build something new on top of the record in an afternoon, because the record already exists and the new thing only has to be pointed at it. When what it proposes is wrong, or the moment matters, a person still says yes or no, and that decision becomes part of the record too.
A year on, the business is not still running on a founder's memory and a trusted spreadsheet. It is running on a record that grew while everyone did their actual jobs, and the shortlist, the quote, the reason a supplier was chosen are all in it, in the company's own words. A person decided every one of them. The record sits on a box the company owns, so if a person leaves — including us — it stays in the building.
See the 2030 vision for a business this size →