Stanford sits at the heart of Silicon Valley, and we students live and breathe the AI wave.
Yet my 68-year-old dad is lapping my classmates and me.
While we sit in class learning about AI, he’s been building with it. This summer he vibe coded and launched several applications, and within weeks they booked five figures in ARR. He’s also pioneering what I think is a new category of software: scout software.
Scout software is a small, fast product that runs on top of the enterprise software that a business already depends on. It is less robust1 than the platform underneath it, but it moves faster and serves one group of customers more directly than the platform can.
I’m borrowing the name from military scouts. Scouts move out ahead of the main force to see what’s there and report back. They are nimble but not full-featured. An army’s main body is robust; it is the engine of war, but it is slow and cumbersome to navigate.
The popular story says AI will kill enterprise software, because every company can now build its own. But the distinction between robust enterprise software and nimble scout software points to a different future: AI won’t flatten the stack. It will add layers to it.
Enterprise will maintain these robust engines. Salesforce will live on. But now, independent developers, customers, and even the companies which build the software of record can also build scout software to fill in utility gaps and help the main force navigate.
This isn’t necessarily new. Developers have built on other companies’ software for as long as there have been APIs, and Clay Shirky described “situated software,” software “designed in and for a particular social situation or context,” back in 2004. The philosophical edges of these categories are fuzzy. In some sense, marketplace apps and extensions can be scout software. But AI means new people building more capable software than before, for smaller markets, and with faster improvement loops.
My dad trained as an architect and ran his own firm. He then built a software business, sold it to BQE, and spent years in its C-suite helping it grow. His new product, COREboards, sits on top of BQE CORE, the platform that runs operations for architecture and engineering firms.
COREboards is scout software. He now ships more on his own than he could from the C-suite.
Everyone who tried it subscribed
Fourteen firms started a trial in the first month, and all fourteen converted to paid subscribers. Several months later, the customer base continues to grow, and to date there is still 100% trial-to-paid conversion and zero churn.
It’s a small starting cohort, but a funnel with no leaks (at either end!) is almost unheard of in SaaS.
Why has this worked so well? Because scout software has three structural advantages.
(1) Low onboarding friction and minimal CAC
Enterprise software has high customer acquisition costs. Scout software has almost none.
Because scout software is built on top of enterprise software that already exists, the onboarding friction is close to zero. The biggest hurdle in enterprise software is getting a firm to change how it works; adopting a new platform means gathering and migrating data, changing routines, and retraining staff, all while running the business.
For COREboards, my dad’s customers have already done the hard work of moving to BQE CORE. Their data is there, and their daily operations already run on that engine. My dad is just asking them to engage with that same data in a new, more useful way. That makes the decision to try it much easier.
If customers don’t like it, nothing is lost: both systems stay intact and run concurrently. Scout software just has to provide marginal additional value. And while customers may have to spend thousands to tens of thousands of dollars a year for the big engine built and maintained by hundreds of employees, my dad can charge a fraction of that and still be profitable as an independent developer.
(2) Rapid value addition to the customer
Feature requests come in the mornings, and my dad has them implemented by afternoon.
He’s built a harness that makes that responsiveness repeatable: customers can report bugs, request features, and ask questions. AI analyzes each submission, evaluates possible solutions, generates interface mockups, and lays out the pros and cons. My dad reviews them and makes the final decision. Once he approves a change, it can be implemented, tested, and delivered within minutes.
At a large enterprise software company, that feedback can take weeks or months to work its way through teams and competing priorities. My dad can move directly from understanding a customer’s problem to reviewing a solution. And because his scout software works from the data already in the platform, he can improve how customers work with that information without another data migration.
This helps explain such low (zero!) churn. Customers have a direct way to shape the product, and they see it become more useful as they use it.
(3) Status quo bias means minimal churn
Switching off your main enterprise system is very difficult, technically and psychologically. Scout software doesn’t threaten this. Status quo bias, the force that usually makes new software hard to grow, works for it instead. As long as users are sticky on their main system, they will be relatively sticky on the scout software.
This is doubly true because scout software can be very inexpensive relative to the main product. My dad’s software costs a typical firm far less than the primary software.
This means the pocketbook cost for customers is too small to ever need a budget fight. From the corporate point of view, a line item of a thousand bucks or so is like a $4.99 app subscription.
Where scouts struggle
Less robust has limits. A scout can produce a clumsy chart, but it cannot afford to send an incorrect invoice. Its obligations will rise with what it touches. This is all the more true if it can write changes back into the records underneath.
Scouts can also be squeezed from two sides.
From below, a firm’s operations manager can now build a tool too. But most architectural firms that use COREboards don’t have the time or desire to build what my dad has, especially since it’s so cheap.
From above, the main platform can eventually build anything a scout proves customers want…
Scouts report back
…but this is actually a symbiotic relationship. One of the values scout software offers the main enterprise software is the ability to find which features customers use and need. No more spending months building out the module to have customers not use it. Here, you can validate customer demand and lead to efficiencies in the enterprise software.
Military scouts exist to report back, and the smartest platforms will court their scout software. Some scouts may even be acquired and live in-house with the main company.
Platforms may seek to control this scout-enterprise relationship. For example, when Atari couldn’t control who made games for its console, weak titles flooded the market, and Nintendo revived the category in part by controlling who could publish.2 Can scouts cause similar problems? A bad game wastes an evening; a bad scout that writes to the books (if APIs allow) corrupts a firm’s records, and the firm may blame the enterprise platform. I expect platforms to gate write access and possibly certify scouts.
Are AI harnesses the next main body?
My dad isn’t the only one building scouts. I am too. Even this newsletter runs on a scout: a dashboard I built with Claude on top of Substack to help me manage my essay releases. As ChatGPT and Claude take over more of my work, they have become the one place where I try to do everything, and I’m realizing that the best interface for a tool I build is often an extension or plugin for these enterprise AI harnesses.
So I’m building scout software on top of ChatGPT and Claude. We may find that a ton of future software is plugins.
A fractal stack
Scout software now allows for a fractal, smaller version of enterprise software to be built on top of larger enterprise software.
And it could eventually be three-layered: large enterprise firms building engines, scout software developers filling in large cracks with some economies of scale, and then independent firm operators coding the smallest use cases to fill in those final business needs still unanswered or too bespoke to spread up the chain.
This is the structural point. Some customer needs are going to be scalable, and some aren’t. Multiple layers, each working at its own scale, meet the needs of every business and every consumer more efficiently than any one layer could.
This model appears philosophically sound—that is why I think scout software will be durable, and here to stay.
If you have built something on top of the software your industry runs on, I’d like to hear what it is.
By saying scout software is “less robust,” I mean that it is less stable, not that it does less. Within its narrow job, it can do more than the platform.
Thanks to Stanford GSB professor Jesper Sørensen for this example and for other feedback on this essay.