Summary: Founders are told to look for a trillion-dollar market. When software gets cheap to build, the same trillion dollars can show up as a billion thousand-dollar markets: one small organization at a time, each with software that fits how it actually works. I’m building a CRM and invoicing system for IIW Foundation on picos to test that idea.
Anyone who has pitched a startup has heard some version of the question: is this a trillion-dollar market? The reasons for this question are sound. Software is expensive to build and expensive to keep running, so the only way to make the math work is to amortize that cost over millions of customers. Big markets justify big builds. Small markets don’t get software at all, or they get whatever the big build happens to offer them.
But, a trillion dollars is also a billion times a thousand dollars. That arithmetic has always been true, but it hasn’t mattered, because nobody could build software for a market worth a thousand dollars. I think that is changing. My thesis is that custom apps, built with AI’s help, will fracture trillion-dollar markets into a billion, thousand-dollar markets. Over the coming weeks, I plan to show how that happens by building one.
Who Adapts to Whom
The trillion-dollar model has a cost that doesn’t show up on anyone’s balance sheet. When a vendor builds one CRM for millions of businesses, it has to decide how a generic business works: what a customer is, what a deal is, which stages a sale moves through, what an invoice looks like. Those decisions are reasonable on average and wrong for almost everyone in particular. So the business adapts. It renames its own concepts to match the vendor’s fields, reorders its work to match the vendor’s workflow, and keeps a spreadsheet on the side for everything the tool can’t express.
Most small organizations end up somewhere in between. They try the SaaS tool, find it fits badly, and fall back to spreadsheets, email templates, and a payment processor stitched together by whoever happens to know how it all works. That’s roughly where IIW Foundation, the small nonprofit that runs the Internet Identity Workshop, is today. The work gets done, but the process lives in a few people’s heads and in files that slowly drift out of agreement with each other. Neither option is good. One makes the organization fit the software; the other gives up on software doing much at all.
There’s a reason SaaS won. Custom software used to mean hiring a developer to build it and then keeping that developer around forever, because the code rotted as soon as nobody tended it. A small organization couldn’t afford the first part and certainly couldn’t afford the second. Renting someone else’s opinionated software was the rational choice. The question is whether the cost structure that made it rational still holds.
Markets of One
In There’s a Personal App for That, I described reviving an old USB microscope by using Claude to build a Mac app for it in a morning. A few years ago that app would have taken me two weeks, and I wouldn’t have bothered. The point of the post wasn’t the microscope. It was that a whole backlog of software that never got written, because its audience was too small to justify the cost, has suddenly become approachable.
A small business is that kind of audience. It is a market of one, and the software it needs is worth something like a thousand dollars of effort to it, not a million. No vendor can serve that market profitably, but the business can now serve itself. With a coding agent doing much of the work, the build is no longer the obstacle; the obstacle is knowing your own process well enough to describe it. Every organization already has that knowledge. It’s just been trapped in spreadsheets and habits because there was no affordable way to turn it into software.
So I’m building a CRM and invoicing system for IIW Foundation. It isn’t a product and won’t be sold. It’s shaped entirely around how we find sponsors, talk to them, invoice them, and keep track of who has done what, using our words for things and following the steps in the order we actually take them. Where a commodity service does the job well, the system uses it: payments will still go through our payment processor, and the books will still live in our accounting software1. The rule I’m following is to rent the rails and own the process. The parts that are the same for everyone can stay rented; the parts that make the organization what it is should belong to it.
Somewhere for It to Live
Cheap code isn’t enough on its own. Most of what makes a business application expensive isn’t the business logic; it’s the plumbing around it: a database and its schema, user accounts and authorization, background jobs, and integrations that break when someone else changes an API. An agent can write all of that, but someone still has to run it and keep it working. Each of those pieces is a separate component with its own versions, its own security patches, and its own way of breaking, and every one of them is a place for rot to start.
I learned this the hard way. I once helped a friend build a dashboard for a large screen in the order-packing operation of his warehouse. We got it running, and the next day he called to say it wasn’t working. He had quit the terminal window the dashboard was running in, not realizing that doing so stopped the dashboard. Nothing in the code was broken. What broke was the unstated assumption that someone who knew how the software ran would always be around to run it, and that’s an assumption custom software for a small organization can’t make.
That’s why I’m building this on picos and Manifold. Each organization we work with, each person, and each event becomes a pico: a small, always-on actor with its own identity, its own state, and its own rules. Picos keep their own state and channels with policy decide who can do what, so there’s no separate database or authorization system to stand up. That doesn’t make maintenance go away; the engine and Manifold still have to be kept current, and the integrations with outside services will still break from time to time. But instead of a stack of separate components to track, there’s one platform to keep up, and the business logic lives in rulesets on top of it.
Manifold supplies the framework for a mesh of picos, giving the app a vocabulary of things and communities to build on rather than raw channels and relationships. As I wrote in Pico Engine 1.8 Is for Builders, the engine now describes itself well enough that an agent can extend a pico application, and also operate one. I expect to run most of the CRM by talking to it, with the agent drafting and proposing and a person confirming anything that touches money or leaves the building.
This app is also a test of the pico stack. Manifold was built for meshes of devices and things, and a CRM will find the places where it isn’t as general as I think it is. Some of what the app needs, like serving web views from picos and talking to outside services with modern authorization, belongs in the engine or in Manifold rather than in the app. Building something real will help me find those gaps.
I’m also aware that “I built it myself” proves very little. The pico engine is mine, so of course I can build an app on it. The real test is whether the thousand-dollar market stays a thousand-dollar market after the first build. Can IIW Foundation keep adapting the system as our process changes, adding a rule here and a ruleset there, without depending on me?
That doesn’t mean every business has to do the work itself. Plenty of small organizations will bring in a consultant to build the first version and come back from time to time to update it, the same way they already hire a bookkeeper or an accountant. The model still works because the business owns what the consultant builds: software that fits how the business works, not a seat in someone else’s product. If a coding agent and someone who understands the business can make those changes in an afternoon, the economics hold. If not, this is just a hobby with an invoice attached.
I don’t know yet which way that will come out, and I’d like to find out in the open. This is the first in a series of posts about building the system: the decisions we make, what picos and Manifold handle well, the gaps we find and close, and whether the result actually fits the way IIW Foundation works. If you’re interested in custom software for small organizations, or in what picos can do outside the Internet of Things, you can follow along as we go.
Software That Fits
This is about more than convenience. How an organization works is part of what it is. The way a small nonprofit treats the people who support it, or the way a shop handles its regulars, is where much of its character lives. When that process gets flattened into a vendor’s model of an average business, the organization loses some of its ability to be itself. It also hands its relationships, the record of who it knows and what they’ve done together, to a company whose interests are not its own.
In Identity Enables Autonomy, I argued that people need apps and data they control, and that those apps need to be able to move. The same holds for small organizations. A system built on picos lives in a mesh the organization owns, and it can move from one host to another without breaking. The data and the process belong to the business that created them, not to whoever rents it the software.
The trillion-dollar market will still be there, and some problems really do need software built once for everyone. But a lot of what we’ve been renting was never a good fit; it was just the only option we could afford. Every small business, nonprofit, club, and workshop could have software shaped to how it works instead of reshaping itself around someone else’s assumptions. We can keep adapting ourselves to tools built for everyone, or we can start building tools that fit us. The choice is ours.
Notes
Accounting software is an interesting example of a big, one-size-fits-all market that will likely survive. Long before software took over the world, accountants had standardized their processes and terminology, so most businesses (or at least their accountants) already conform to a common framework that general-purpose accounting software can accommodate.
Photo Credit: A pico fits software to its owner from ChatGPT (public domain)
