Everyone is asking whether AI can build software. It can. That question is settled and it was never the interesting one.
The interesting question is who knows what to build.
A working example
An operator in door-to-door solar spent years at the step. Not managing a team that knocked — knocking. Long enough to know that most doors are not home, that a polite exit from a “no” is worth more than an argument, and that the number which predicts a rep’s week is doors per hour rather than hours worked.
He wanted a platform. We built it. What is worth writing down is which part was hard.
What he handed over
Not a feature list. A method, described precisely, by someone who had run it thousands of times.
The canvassing screen has seven outcomes: not home, refused, moved, deceased, come back, registered, already registered. That set did not come from a product workshop. It came from a person who has stood at enough doors to know that those are the seven things that actually happen, that “refused” needs to be one tap because it is most of them, and that “deceased” has to be on the list because pretending otherwise makes a rep feel like a fraud when it occurs.
Every visit stamps location and time automatically. Not because location tracking is a feature, but because he knew what happens when reps are asked to self-report door counts, and he wanted the argument to end.
The record captures a photo and a voice note. He knew the truck is where notes go to die.
The app shows an online indicator and keeps working without signal. He knew that the moment you need the software most is standing in a driveway with one bar.
None of that is technically difficult. All of it is obvious in hindsight. None of it would have been in a specification written by anyone who had not done the work.
The part that was hard, and the part that was not
Building it took weeks. The platform scores proposals against pricing benchmarks and regulatory requirements, models rooftop potential against real solar data, maps panel layouts on a specific roof, tracks warranty claims and contract reviews, and holds a directory of tens of thousands of licensed contractors. That is a substantial system and it was not the hard part.
The hard part was the years.
You cannot compress that. There is no model that has stood at a door and been told no four hundred times in a week. There is no dataset that teaches you which of the seven outcomes a rep will quietly mislabel to protect their numbers, or why. That knowledge is only available to someone who was there, and it is the reason the software is any good.
Why this generalises
The instinct in vertical software is to hire a domain expert as an advisor and let product people design around them. That produces systems which are almost right, in the specific way that a tourist’s directions are almost right.
The alternative is the one worth taking seriously: let the person who knows the work describe it exactly, and treat that description as the specification rather than as input to one.
That only became practical recently. When building took quarters, the domain expert’s account had to be filtered through analysts, translated into requirements, negotiated against estimates, and by the time it reached an engineer it had been paraphrased four times. Now the distance between “here is exactly how the work goes” and a running system is short enough that nothing is lost in the middle.
Which inverts where the scarcity sits. Engineering capacity used to be the bottleneck. It is not anymore. The bottleneck is people who understand a trade well enough to describe it without hand-waving — and historically we paid those people the least and listened to them last.
The same five moves
The training curriculum for new reps and the software they use turn out to be the same document. Knock, qualify, build the pain, sell the appointment, keep the record. The curriculum teaches the five moves; the platform runs them. Neither was derived from the other. They match because the same person authored both, and he only knows one way the work goes.
That is what a vertical platform is, when it is done properly. Not a database with an industry theme applied. A method, written down twice — once for people, once for machines.
What we take from it
We build these for a living, and this one clarified something we had half-understood.
Our job is not to have opinions about someone else’s trade. It is to be fast and faithful enough that a person who has done the work can see their own method running, recognise it, and correct the parts we got wrong. The correction loop only works if the build is quick enough that correcting is cheap.
The experience is the asset. It always was. What changed is that it no longer has to wait in a queue behind a roadmap to become a product.