The most experienced person on the shop floor told us, to our faces, that he would never use the software we were there to talk about.
Not “I’m worried about the learning curve.” Not “we’ll see how it goes.” What he said was closer to: whatever you guys make, I will not be using it. Then he explained the system he already has. He finishes a job, walks over to the person who runs the office, tells her he used ten of these and ten of those, and she types it in. Then he goes back to his work.
That was one of the most useful things anyone has said to us in a scoping conversation. He is not an obstacle to the project. He is the specification.
The business is a small fabrication shop — the kind of firm where everyone who can approve a purchase also operates a machine. We were there about inventory. And the conversation clarified something we have been circling for a while: the hardest and most valuable market in software right now is not startups. It is Main Street.
Why nobody ever built anything for them
Almost all software gets designed for people who already like software. Technology companies, startups, early adopters — people who will read a changelog for fun. Meanwhile the plumbing outfit, the glazier, the eight-person millwork shop and the family-run supplier have been served two things: a generic subscription tool built for everyone and therefore for no one, or nothing at all.
There is a straightforward reason for that, and it isn’t snobbery. It’s arithmetic. The system we are scoping for that shop — voice capture, live inventory, document parsing, guardrails on every transaction — would have taken thirty or forty engineers two years to build a decade ago. Several parts of it were not purchasable at any budget. Reliable speech-to-text was a research problem, not a line item. No sane software company was going to spend that to serve one firm with a handful of staff.
That arithmetic broke. The pieces that used to require a research team are now an API call, and a small expert team can build genuinely bespoke systems on a budget a small business can actually approve. The market didn’t change. The cost of serving it did.
There’s a second reason Main Street is the better market, and we learned it by knocking on the wrong doors first. When you pitch a branch of a national chain, you hear a version of the same sentence every time: there’s a head office somewhere else, they give us our software, we have no say. Polite interest, zero authority. In a small independent firm, every decision-maker is standing in the same room, usually within earshot of the machines. Three or four thumbs-up and it’s a project. They have less budget and infinitely more agency.
Three things that are true of every Main Street project
Before the tests, the constraints. We now assume all three at the start of any custom software project for a small business, and we have stopped treating them as bad news.
- They are extremely busy. Their time is the scarcest resource in the project, including ours. A discovery process that needs twelve hours of their week will fail, no matter how good the software at the end would have been.
- They don’t fully know what they want. They know what hurts. Translating that into a system is our job, not theirs, and asking them to hand over a specification is passing our work to someone with a shop to run. Worth noting: the first time we presented this shop with a deck of five proposed solutions, the thing they actually wanted — inventory — wasn’t one of the five.
- They are cynical about technology. Usually because they have been sold something before that made their week worse. That cynicism is earned, it is information, and it is the most reliable quality filter you will ever be handed.
- Show the transcription instantly, on the same screen, while he’s still holding the phone. The person best placed to catch the mistake is the one who just spoke, and he catches it in one second — but only if we show him.
- Refuse impossible actions outright. If the system is told to draw a thousand units and there are five hundred in stock, that is not a transaction to record, it is a question to ask. Most misheard numbers die right there, before any human is involved.
- Confirm, or ask — never guess. Enough information means a confirmation screen. Not enough means two or three multiple-choice questions and then a confirmation screen.
- Oversight as review, not as a bottleneck. The office gets a running log to scan — three days of correct entries at a glance, with anything doubtful flagged for a reply — instead of being the air traffic controller every entry has to pass through.
- Who on my team is going to love this, and what happens if they don’t? If the answer assumes cooperation, the plan is fragile.
- Which steps of my current day disappear? Not “which screens do I get.” Which steps stop existing. If the honest answer is “none, but they’ll be nicer,” that’s a redesign, not a saving.
- What happens when it gets something wrong? Any system with AI in it will. The good answer describes how errors get caught, by whom, and how far they get first.
- What do I own at the end? A system you keep, or a dependency you rent.
Which brings us to what we think good technology for these businesses has to do. Four tests. They are in order of difficulty, not importance.
Test one: somebody in the building has to love it
Not tolerate. Not comply with. Love.
The tempting response to the man who said he’d never use it is to design around him — build something lovely for the office, let him keep shouting numbers at a human. That would be the professional failure mode. It ships, it gets signed off, and the actual behaviour on the floor is unchanged.
So he is the bar. Success is the most sceptical person in the building choosing the software when nobody is making him, and eventually saying some version of I wish we’d done this five years ago. If we get there with him, the rest of the team is trivial by comparison.
We have not won him over yet. Nothing is built. This is a bar we have set for ourselves in public, which is the only kind that counts for anything.
Test two: hand back time by deleting steps, not by teaching new ones
Here is the thing that made the project click for us. Listen again to what he described: he speaks his materials out loud to a person, and that person converts speech into a database record.
He is already using a voice interface. It just happens to be a colleague.
So we don’t need to change how he works at all. We need to remove the steps in the middle. He holds a button on his phone on the walk to his truck, says “used twelve feet of aluminum on the station job,” and the inventory moves. Same instruction, same words, same fifteen seconds of his day. Nobody has to be waiting at a desk to receive it.
The principle generalizes past this one shop, and it is the thing most small business software gets backwards: don’t redesign the human’s workflow, delete the connective tissue between the steps they already do. Filler steps. Re-typing. Waiting for someone else to be free. Being the human router between two systems that don’t talk. That is where the hours actually are. A scheduling control centre we built for a swim-lesson operator saved them roughly fifteen hours a week, and almost none of that came from anyone doing their job differently — it came from deleting the relay work between the parts of the job.
Practically, for us, that means three rules. Voice first, because nothing is faster than talking when your hands are full. Manual second, always — a full conventional interface for anyone who prefers to tap, and as the record of truth. And no typing where a tap will do: when the system needs more information, it asks in multiple choice, not with an empty text field. A form with six blank boxes is a small act of hostility toward a busy person.
Test three: the output has to be better, not just faster
Speed alone is a weak promise, and it’s the one everybody makes. The stronger claim — the one that survives contact with a sceptic — is that the work comes out better than it did before.
With voice and AI in the loop, that starts with taking errors seriously rather than pretending they won’t happen. Ours will mishear “a hundred” as “a thousand” eventually. So the design assumes it:
Then there’s the better-output opportunity that has nothing to do with typing. This shop, like most, describes the start of a job the same way: we’re scrambling, we don’t really know what we need, we wait until we’re on site and then it’s do or die. But the information existed the whole time. It was sitting in a set of blueprints and a contract.
Feed those documents in, and the system can draft the materials list and the purchase orders for a job before anyone drives anywhere. A human still reviews and sends — that part is not negotiable. But the difference between guessing on site and knowing on Monday is not a time saving. It’s a better job. That is what AI in a small business should look like: not a chatbot in the corner, but fewer surprises on a Thursday afternoon.
If a process today takes thirty steps and the new version takes five, and the five produce fewer mistakes than the thirty did, you don’t have to sell anybody on it. They can feel it by the end of the first week.
Test four: every build should be a seed
The fourth test is the one clients don’t ask for and should still get, because it is what makes the third one affordable for the next shop.
A one-off system that solves one firm’s inventory is worth building. A one-off system that also leaves behind a set of components — a voice capture layer, a guardrail engine, a document parser, a process board where each step can be configured with its own assistant — is worth considerably more. The next business gets the same kitchen and a different meal. Less work on our side, a lower number on their invoice, and a better system than a from-scratch build would have produced, because the parts have already been beaten up by real use.
We should be honest about the shape of that, because it’s where studios oversell. The ambition is a configurable platform that any small operation could switch on. The reality is that you get there by installing bespoke versions for several very different businesses first and finding out which parts genuinely generalize. Anyone promising you the finished platform on day one is describing a hope as though it were an inventory.
This is also why we’d rather learn on real work than on a pitch deck. A venture fund backed us to build software for small operators, and the apps that came out of that mandate taught us more about this market than any amount of theorizing would have. A real client with a real inventory problem is better validation than anything we could say about ourselves.
How to tell whether you’re being sold Main Street software
If you run one of these businesses and someone is pitching you custom software for a small business — us included — the four tests turn into four questions worth asking out loud:
The reason we are publishing the four tests before we have passed them is that the bar is the interesting part. Everybody can produce a case study after the fact. Far fewer will tell you in advance that the project is a failure if the grumpiest man in the shop is still walking his numbers over to a colleague’s desk.
Less time. Better work. Something the crew actually reaches for. And a component left behind for the next shop on the next street. That is what technology for Main Street should be — and for the first time, it is genuinely buildable for businesses this size.