Good project ideas rarely arrive as flashes of app-store inspiration. They hide inside recurring annoyances: the spreadsheet stretched past its limits, the weekly group-chat ritual, the small task repeated by hand every Friday. Mass-market products serve the most common needs of the most people, which leaves a long tail of personal, local problems unserved, and those problems belong to whoever actually has them.

This lesson traces the tradition behind building for oneself, from open source's personal itch through home-cooked apps and barefoot developers, then turns that tradition into a practical habit. Learners come away knowing how to spot friction at home and at work, read existing workarounds as evidence of real needs, and decide when an existing tool already does the job.

The personal itch

A personal itch is a recurring, specific annoyance in daily life or work that no mass-market product solves well. The term traces to Eric S. Raymond's 1997 essay "The Cathedral and the Bazaar," whose first lesson reads: "Every good work of software starts by scratching a developer's personal itch" [1]. Raymond was explaining why open-source software quality ran so high: people built what they themselves needed.

In 1997 the itch only counted if the person having it could already code. Vibe coding removes that condition, but the underlying logic holds. The builder who lives with a problem understands it completely: every edge case, every awkward detail, every moment it bites. That understanding is an unfair advantage no outside product team can match.

Home-cooked software

Home-cooked software is an app made for a tiny, known audience, the way a home meal is cooked for family rather than for restaurant customers. Robin Sloan coined the framing in February 2020 after building BoopSnoop, a video-messaging app for exactly 4 users, his family, once the corporate app they loved shut down: "I made a messaging app for, and with, my family. It is ruthlessly simple; we love it; no one else will ever use it" [2]. The idea extends Clay Shirky's 2004 notion of situated software, designed for a particular social situation and used by dozens of people rather than millions [3].

The cooking comparison carries the whole argument. People don't only learn to cook to become chefs; they cook to eat better, carry on traditions, and care for others. Building software for a household works the same way, and success is measured by how well the tool serves the people at the table, not by how many strangers download it.

Barefoot developers

Barefoot developers occupy the band between end users and professional programmers: people who are technically savvy and solve problems for themselves and their communities without wanting to become full-time engineers. Maggie Appleton introduced the term in her May 2024 talk "Home-Cooked Software and Barefoot Developers," naming it after China's 1960s barefoot doctors, who brought basic medical care to villages that trained physicians never reached [4]. Her examples are familiar figures: teachers with elaborate Notion setups, students with over-the-top dashboards, and finance staff with sprawling spreadsheets.

What historically stopped this group is what Appleton calls the command line wall, the steep jump in complexity between tools like Airtable and real software development. Her argument, offered with an explicit hedge, is that language models are dismantling that wall. The result is software that, in her words, "solves local problems for local people," built by the person closest to the problem.

The long tail of user needs

The long tail of user needs

The long tail of user needs explains why so many real problems have no product. Industrial software companies employ expensive engineers, so they build only what pays: the most common needs of the largest number of users. Everything else, the nearly infinite set of needs that only a few people share, falls into the long tail [5]. Kasey Klimes, drawing on his years working on Google Maps, supplies the canonical example: Google Maps will never display tidal patterns or historical borders, even when those matter enormously to a few dozen people [6].

Appleton's conclusion reframes the whole hunt for ideas: personal builders can create solutions no industrial company ever would, because the market value is too small and outsiders don't understand the niche well enough. The absence of a product isn't evidence that a need is fake. It's often evidence that the market structurally can't serve it.

Itches at work and play

Itches show up everywhere, not just in home life. Simon Willison documented 14 personal tools built in a single week with Claude Artifacts in October 2024, most taking under 5 minutes each: a QR-code decoder built mid-meeting, a phonetic-alphabet converter for volunteer radio duty, a URL-to-Markdown converter born from one mobile browser frustration [7]. He calls the genre on-demand software: build a tool at the moment of need, use it, and move on. Play counts too; Ethan Mollick's first Claude Code prompt produced a working 3D town-building game about 4 minutes later, with no further input from him [8].

Work may be the richest itch territory of all. Per Lenny's Newsletter, it's now more common than not for product teams to prototype ideas in tools like v0, Bolt, or Lovable before involving engineers [9]. The practical shift is in the threshold: an itch no longer needs to justify a project. It needs to justify 5 minutes.

Mining existing workarounds

A workaround is a buildable idea hiding in plain sight. The strained spreadsheet, the ever-growing notes file, and the weekly group-chat ritual all mark places where someone already designed a solution without calling it software. Workarounds stay invisible precisely because they function; nobody audits a system that limps along well enough. Appleton's barefoot developers are exactly the people already pushing tools like Notion and Airtable to their limits with elaborate constructions [10].

A strained spreadsheet is a validated requirement written in cell references. It proves the problem is real, proves the current fix is inadequate, and sketches the shape of what a better tool should do. Idea-hunting therefore works best as recognition rather than invention: the strongest candidates are the hacks already running.

Pro Tip! Listing the last 5 times a task prompted the thought "there should be a way to do this" usually surfaces more buildable ideas than any brainstorm.

Problems, not app ideas

Startup culture trained a generation to hunt for "app ideas," which are solutions in search of markets. Paul Graham's well-known corrective points the other way: rather than trying to think of startup ideas, look for problems, preferably ones the builder has firsthand [11]. An app idea starts from a solution and goes searching for a problem to justify it; an itch starts from a problem and lets the solution stay as small as it wants.

For vibe coding the bar drops even further, because the idea doesn't need to become a company at all [12]. A problem lived firsthand arrives with everything an idea needs: a real user, a clear definition of done, and instant feedback on whether the tool actually helps. A recent annoyance is a far more productive starting point than a blank canvas.

Does personal software count?

A common worry dismisses personal software as a toy version of the real thing. The instinct comes from professional norms, where quality means scale, polish, and maintenance discipline. Sloan's answer is that the comparison itself is wrong: "When you liberate programming from the requirement to be professional and scalable, it becomes a different activity altogether, just as cooking at home is really nothing like cooking in a commercial kitchen" [13]. His own app backs this up; BoopSnoop ran essentially unchanged for 5 years while serving its 4 users happily, suggesting that scale, not software itself, is what makes maintenance heavy.

The vision also carries research weight. Ink & Switch's malleable-software research argues that personal computing originally promised users a material they could shape, then delivered sealed, unchangeable appliances instead [14]. Personal software is held to a different bar than commercial products, and that different bar is precisely what makes it achievable for a first-time builder.

Check the shelf first

Before building anything, a careful builder checks the shelf. If an off-the-shelf product or a plain spreadsheet already solves the problem well, adopting it beats rebuilding it; buy-before-build is the pragmatist's rule for good reason. The itch test isn't a mandate to code everything, and "nothing here is worth building" is a perfectly legitimate outcome.

The shelf carries its own costs, though, and they belong in the decision. Subscriptions add up, data sits in someone else's cloud, and products die without warning; Sloan built BoopSnoop only after Tapstack, the app his family loved, shut down [15]. Appleton adds that platforms can change their terms at any time, leaving people to discover that what they built on top never really belonged to them [16]. The honest sequence runs in one direction: search the shelf first, weigh those costs, and build when the shelf comes up short.

Pro Tip! A 10-minute search for an existing tool is the cheapest step in any build.