The Noble Path
It is a truth universally acknowledged that an indie hacker in possession of a widget must be in want of a business model...
Every tool is a startup now.
Every script is a SaaS product.
Every neat little hack you cobbled together on a Sunday afternoon to solve your own problem is, according to the prevailing wisdom, an "MVP" waiting for its first round of funding.
The entire machinery of online discourse around building and creating has been so thoroughly captured by entrepreneurial "logic" that we've lost the language to describe what it feels like to simply make a thing that helps someone, give it away, and move on with your life.
I've been feeling this for a while now, and I suspect a lot of folks who have the itch to build feel it too, even if they haven't articulated it. You make a browser extension that fixes a tiny annoyance. You write a tool that reformats data in a way your colleages find useful. You build a small calculator for a niche problem that ten people on Earth actually have.
And the immediate, reflexive, near-Pavlovian response from the internet is:
Have you thought about monetizing this?
Gifts aren't pre-revenue products
Marcel Mauss published The Gift in 1925, and nearly a century later, the tech world still hasn't caught up with his central insight. Mauss studied indigenous societies across the Pacific Northwest and Polynesia and found that gift-giving operated as a complete system with its own logic, its own power dynamics, its own hierarchies, its own concept of value. Gifts created social bonds. They established reciprocty. They built trust in ways that market transactions can't.
The open-source software movement understood this intuitively. When Richard Stallman wrote the GNU Manifesto in 1985, his argument was moral: software should exist freely in the world. The modern internet runs on tools that people built and gave away: Linux, Apache, Python, the cryptographic libraries that keep your bank details from floating around in plaintext. These are gifts in the Maussian sense, and they built the foundation for an industry worth trillions of dollars.
But the gift economy of software has been absorbed into the entrepreneurial economy. Open source became a "go-to-market strategy." Free tools became "lead magnets." And now we live in a world where building something useful and giving it away for free is treated as either naive or as a clever long-game bottom-up business tactic. There's no conceptual space left for the third option: that you did it because you wanted to.
What the monks knew about useful work
The Rule of Saint Benedict, written around 530 AD, organized monastic life around a principle that sounds almost radical in the context of modern productivity culture: ora et labora, pray and work. The monks built things. They copied manuscripts, brewed beer, cultivated gardens, developed new agricultural techniques. Some of this work was consequential. Much of it was small and local and meant for their immediate community. None of it was oriented toward scale.
Work was understood as a form of devotion, valuable in itself rather than as a means to accumulate wealth or status. The monks built in private, for people they could see and know, finding meaning in the craft itself.
To transplant it:
Someone on a forum builds a tiny utility that converts between obscure file formats. Someone else writes a Tampermonkey script that removes an annoying popup from a website they use daily, then shares it because why wouldn't you. A developer at a nonprofit writes a data-cleaning tool for a specific kind of messy spreadsheet that everyone in their field has to deal with, posts it on GitHub, and walks away. Someone else publishes a tiny color-contrast checker that only people doing accessibility audits would ever need. These are Benedictine acts. They're labor undertaken for its own sake and for the immediate good of a knowable community, and they produce a satisfaction that no amount of MRR can replicate.
Scale poisons everything it touches
The startup ecosystem, and the broader culture of "building" that has grown up around it, operates on an implicit assumption that value scales linearly with reach. A tool that helps ten people is good. A tool that helps a thousand people is better. A tool that helps a hundred thousand is exciting. A tool that helps ten million is a unicorn, and you should probably quit your job to work on it full-time.
This logic is tempting, and in certain contexts it's perfectly sound. If you've discovered a real solution to a widespread problem, it would be odd not to try to bring it to more people. But the framework becomes toxic when it's applied universally, when every small creation gets fed into the same evaluative grinder and comes out measured against the yardstick of potential scale.
Because most good things don't scale.
Most good things are stubbornly local.
The best bread I've ever eaten came from a bakery in an Australian country town that didn't have a website and its originator couldn't have told you his "total addressable market" if you'd asked.
When we apply scale logic to everything, we end up devaluing the closeness to a real problem and the direct feedback loop between making a thing and watching someone use it.
Fun is a valid engineering requirement
Freud was wrong about a great many things (charitably), but his concept of the pleasure principle has aged well in the context of creative work. He argued that people are wired to seek pleasure and avoid pain, and that much of what we call "civilization" is the process of learning to defer gratification in service of longer-term goals. The reality principle, he called it. Grow up, stop playing, get serious, build something real.
Modern productivity culture is the reality principle taken to an algorithmically appropriate extreme. Every hour must be optimized. Every project must serve a goal. Every creative act must be justified by its metrics and its contribution to some larger strategic objective. And this framework is so deeply embedded that even hobbyists feel guilty about building things for fun, as if fun were an insufficent justification for spending a Saturday afternoon writing code.
But fun is actually a good signal. When you're building a small tool because you find the problem interesting, or because the act of making it brings you real pleasure, you're operating in a mode that produces different (and, in my experience, better) results than when you're building to a spec or optimizing for a market. You make different design choices. You take different risks. You're willing to over-engineer a feature that delights three people and to under-engineer the parts that don't matter. The output has a character that venture-backed software, by structural necessity, can never have.
William Morris' Arts and Crafts movement was, at its core, an argument that industrialized production stripped work of its pleasure and products of their soul. Morris wanted to make beautiful things by hand, slowly, with care, in a way that honored both the maker and the user. He was fighting against the Victorian equivalent of "move fast and break things," and his economic program failed, but his aesthetic and moral intuitions hold up. There's something in a hand-built tool, physical or digital, that mass production can't touch.
When gifts become jobs you never applied for
The open-source world has been having its own reckoning with this tension for a decade now. High-profile maintainers burn out. Critical infrastructure projects turn out to be maintained by a single exhausted volunteer. Companies worth billions depend on libraries whose creators haven't been paid a cent. The discourse around "open-source sustainability" has generated an enormous volume of think pieces and not very many solutions.
But I wonder if part of the problem is that we're trying to solve the wrong equation. The burnout epidemic in open source goes beyond money (though money is part of it). It happens when something that started as a gift, something built for fun or out of real care, gets conscripted into an economy of obligation and expectation. You wrote a library because you needed it and thought others might too. Now ten thousand developers depend on it, and they file bug reports with the tone of customers who've been wronged, and suddenly your gift has become a job you never applied for and can't quit without feeling like you've betrayed people.
Better funding for open source would be nice, but the deeper issue is rebuilding the cultural permission to make things small and keep them small. To build a tool, share it, and explicitly say: this is a gift, not a product. I'll maintain it if I feel like it. I won't if I don't. You're welcome to fork it, improve it, ignore it, or throw it away.
Why the market can't have everything
Markets are excellent at allocating resources toward problems that affect large numbers of people who are willing and able to pay for solutions. Markets are terrible at addressing problems that are too small, too niche, too specific, too local to support a business model. If you have a problem shared by ten million affluent people, the market will solve it six times over with varying degrees of elegance // extraction. If you have a problem shared by two hundred researchers in a subdiscipline of marine biology, you're on your own.
This is the space where gift-economy building works. The long tail of human problems: the thousands of little frictions and annoyances and workflow inefficiencies that are too small for anyone to build a company around but too real for the people experiencing them to ignore. When someone builds a free tool to address one of these problems, they're serving a need that money was never going to serve.
And this work has positive externalities we consistently undercount. A free tool that saves a hundred people twenty minutes a week gives back more than three thousand hours of human time per year. A well-written tutorial that helps people avoid a common mistake reduces frustration across an entire community. A spreadsheet template that makes a confusing tax form navigable for freelancers is doing work that no government agency and no private company has bothered to do. A CLI script that batch-converts a weird legacy file format saves someone from losing an afternoon every month. None of this shows up in GDP figures or on growth charts. The value is real anyway.
The Noble Path
None of this is an argument against entrepreneurship or against charging money for software. eople should get paid for their work. Businesses that solve real problems at scale have value. I am neither a purist nor a luddite, and I'm certainly not interested in living a life of poverty and obscurity.
There is a Japanese concept, ikigai, that Western self-help influencers have repeatedly mangled and monetized into a mockery of a Venn diagram about finding your "purpose." But the original sense of the word is closer to "the thing that makes life worth living on a daily basis," and in the research conducted on centenarians in Okinawa, ikigai was rarely about grand professional achievement. It was about tending a garden. Talking to neighbors. Making small things that brought small joys. Waking up with something to do. The scale of the contribution didn't matter. What mattered was the directness of the connection between the effort and its effect.
I think what I'm arguing against is the monoculture. The idea that building-as-business is the only legitimate mode of making things, and that everything else is either a hobby (dismissive) or a pre-revenue startup (aspirational). I'm arguing for the recovery of a third category: building as gift, building as an expression of care for a specific community of people whose problems you understand because you're one of them.
If you've ever made something useful and felt a pang of guilt for not monetizing it, that guilt is a symptom of the monoculture. If you've ever hesitated to share a tool because it wasn't "polished enough" for a product launch, you've been contaminated by standards that don't apply to gifts. If you've ever described your own creative work as "a side project" with that apologetic minimizing doing all the heavy lifting, you've internalized a heirarchy of value that ranks market viability above human usefulness.
The Noble Path as I see it is to build a small, imperfect, deeply useful thing and give it away to the people who need it. Skip the landing page and the waitlist. A thing that works, offered freely, in the oldest and most human tradition of making things for each other.
The monks would understand.