Why the niches nobody builds for are the best place to build, and where DataPublisher fits by Richard Roberts, Founder, DataPublisher LLC · McKeesport, Pennsylvania
In October 2004, Chris Anderson wrote an article for Wired called "The Long Tail," and two years later he turned it into a book. The core observation was simple, and it has held up better than most business ideas from that era.
A physical bookstore has a limited number of shelves, so it stocks the books that sell. A few bestsellers carry the store. Everything else doesn't earn its shelf space, so it isn't there. An online store has no shelf-space problem. It can stock the bestsellers and the obscure titles that sell a handful of copies a year. Add up all those obscure titles and you get a market as large as the bestsellers, and sometimes larger. Anderson called that second part the tail.
I've been thinking about that curve for software for a long time, because software has the same shape. It also has a tail that, for the most part, nobody has built yet.
"The tail isn't empty because nobody needs the software. It's empty because nobody can afford to build it."
The shape of the software shelf
Picture every piece of business software as a bar on a chart, sorted by revenue.
At the head are the horizontal tools that everyone uses. Microsoft Office, Google Workspace, Adobe. Revenue in the billions, customers in every industry, and each one is built to be general enough for all of them.
In the body are the vertical products, the Shopifys and HubSpots and Salesforces. They go deeper into one kind of work, still serve large markets, and still earn hundreds of millions.
Then the tail. A veterinary clinic's intake and vaccine certificates. A homeschool co-op's report cards, permission slips and attendance awards. A boutique law firm's engagement letters. A property manager's lease renewals. A small construction company's change orders and lien waivers. A records office's retention notices. Thousands of these niches, each with a few hundred or a few thousand potential customers, each with its own vocabulary, its own forms, and its own compliance rules.
I wrote about this in Chapter 12 of the first volume of Building Intelligent Systems. The book's back-of-the-envelope version goes like this: something on the order of ten thousand narrow niches, each able to support several viable software businesses, each business reaching somewhere between a half-million and five million dollars a year. Those are estimates, not census data, and I'll come back to how much weight to put on them. But the direction is right. The tail is wide, and the individual bars are small.
Why the tail stayed empty
Anderson's argument was that the tail becomes profitable when two costs fall to nearly zero: the cost of distribution and the cost of production. Online retail killed the shelf-space constraint. Digital music, ebooks and print-on-demand cut the cost of making one more copy.
Software distribution got there long ago. Shipping one more copy of an app costs nothing. If you're in a niche of 400 customers, the internet will find them for you.
What never got cheap was the cost of making the first copy for a particular niche. To build real software for a veterinary clinic you need a data model, a template library, a workflow, a way to collect information from clients, a signature step, email delivery, an audit trail, and someone who understands what a rabies certificate must say. That's months of work by someone who knows both code and the domain, and almost nobody does. A developer without domain knowledge builds the wrong thing. A domain expert without a developer builds nothing.
So the economics fail at both ends. A niche with 400 customers can't support a software company that has to build everything from scratch. And a generic tool, however good, will always be a little wrong for any particular niche, because it was built for everyone.
What do people in the tail do instead? They do what people have always done. They build it in Word and Excel, by hand, every time. The co-op coordinator retypes the same report card for forty students. The real estate office fills out the same intake form for the hundredth time. The records manager knows exactly what the workflow should be and has no way to say so except in a meeting with someone who can code.
That's not a missing market. That's a market with no supply.
Where DataPublisher fits
DataPublisher for Word is a task pane add-in that merges structured data into Word templates, produces one personalized document per row, and then distributes those documents, collects responses, and archives the results. On its own that's a useful tool. But the reason it matters for the long tail is something underneath it.
The engine is the shared fixed cost.
Everything that's the same in every niche, DataPublisher already does. Merging data into documents. Email distribution through Microsoft Graph. DataRequest links that let a recipient respond, sign and upload files from a phone. Tracking. Archiving. Retention. The builder of a niche application doesn't write any of that. They don't pay for it again.
What's left is the part that is specific to the niche: the fields, the relationships, the templates, the workflow, the rules. That's exactly the part a domain expert already knows. In DataPublisher it's a Domain App Pack, a structured declaration of the domain. I wrote about this at length in Configuration Over Code. The short version is that the configuration is the application. You declare the domain, and the engine builds from the declaration. You aren't handing a spec to a developer, and you aren't hand-writing plumbing.
That changes the economics of the first copy. If the cost of building a niche app falls from "months of a developer's time" to "a domain expert describing what they already know," a niche of 400 customers can support it. A niche of 200 can too. That's how a tail gets filled.
Anderson's three rules, applied
Anderson boiled the long tail down to a few rules for anyone who wanted to run a business there. They map onto what we're building more closely than I expected when I started.
Make everything available. The first rule is to stock the whole tail, not just the hits. The DataPublisher marketplace already carries well over a hundred domain packs across a wide range of categories, and creating, uploading and forking packs is built in. Some of those will have many users and some will have a few dozen. That's fine. A shelf that costs nothing to keep a title on doesn't need every title to be a bestseller.
Cut the price, then cut it again. Software for a niche has to be priced for a niche. Individual is $19 a month, Professional is $39, Business is $79. Do the arithmetic the book does: 200 customers at the $39 tier is about $7,800 a month, and 1,000 at the same tier is $39,000. That's the "serve two hundred to a thousand customers well" range from Chapter 12. It isn't a unicorn, and it was never meant to be. It's a living, and for the person who builds it, in a place like McKeesport, it can be a very good one.
Help me find it. This is the rule the tail needs most, and the one that gets neglected. A thousand packs nobody can sort through are no better than none. This is where the Guild comes in. The Guild is how we train domain experts, like the retired records manager, the former school administrator, and the real estate agent who got tired of retyping, to build packs well, support them, and keep them current. Finding the right pack only works if the packs are curated and maintained by people who still live in that domain. A pack that was accurate in 2024 and untouched since is a liability, especially in anything regulated.
The part about people
There's another way to say all of this, and it's the reason I started the company.
The long tail of software is really the long tail of expertise. Every niche has people who understand it deeply: how it works, what the forms are, what goes wrong, what the regulators care about. For most of the history of software, that expertise had no route into a product. You had to learn to code, or hire someone who had, or give up and keep doing it by hand.
Our founding mission is to help create 100,000 new consulting businesses through document automation. That number only makes sense if you believe in the tail. You can't get to 100,000 by having 100,000 people compete in the same ten markets. You get there with ten thousand niches and a handful of builders in each, every one of them serving customers they understand better than any outsider could.
It's the same idea behind the recycling post: a career's worth of solved problems shouldn't end up in a landfill when the org chart changes. In the tail, that experience is the product.
What to be skeptical about
I'd be doing you a disservice if I told this as a pure success story. A few honest caveats.
The tail is real, but it's thin. Anderson's thesis drew serious pushback. Harvard Business School's Anita Elberse looked at actual sales data for music and video and argued in a 2008 Harvard Business Review piece that hits still dominate, and that the tail is long but each item in it sells very little. That's a fair warning. Most individual packs will be small, and some will earn almost nothing. The bet is not that every pack succeeds. The bet is that when the cost of making one drops low enough, a lot of small things are worth making, and the people who make the good ones in the right niches will do well.
The numbers in the book are scenarios. The book's ten-thousand-niches arithmetic and its worked example of a fictional developer building a veterinary product are there to show the shape of the opportunity. They aren't forecasts, and they aren't a promise. Your niche might be smaller than you think, or your customers might be harder to reach. Do the math for your own niche before you quit your job.
Maintenance is the real cost. Building a pack is the easy part. Keeping its templates and rules correct as regulations change, answering support questions, and fixing what breaks is what separates a business from a demo. The tail rewards the people who stick around.
Domain knowledge doesn't transfer on its own. The engine removes the code. It does not remove the need to know what a rabies certificate must say. The person who can describe the domain is still the scarce resource, and that's the point.
Where this leaves us
The head of the software market will keep being served by the companies that serve it now. The body belongs to the vertical SaaS companies with big sales teams. Neither of those needs us.
The tail is different. It's thousands of small groups of people doing skilled work with tools that were never built for them, running on Word documents and copy-and-paste. They don't need a better horizontal tool. They need software that speaks their language, and the people who speak their language need a way to build it that doesn't first require learning to code.
That's where DataPublisher sits. It isn't trying to be the next Salesforce. It's trying to be the shared engine under ten thousand small, specific applications, each built by someone who understands the work.
If you've built the same document a hundred times, you already have the hardest part. Start with that one.
Richard Roberts is the founder of DataPublisher LLC and the author of the Building Intelligent Systems series. This post is adapted from Volume 1, Chapter 12.