Building for Yourself First
Updated: 21 hours ago
On 25 August 1991, a student in Helsinki posted to the comp.os.minix newsgroup: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones." Linux is the standard example of software built to scratch the builder's own itch, and it deserves to be. But read the rest of the post. Linus Torvalds asked "what features most people would want", and he added a limitation in the postscript: it "probably never will support anything other than AT-harddisks, as that's all I have."
Both halves of the lesson are in that one message. Building for yourself gave him a working system, real requirements and the motivation to finish. His own machine also set the limits of what it supported, and he knew it. What made Linux grow beyond a hobby was the second half: he went looking for other people's needs almost immediately.
The advice "build for yourself first" is usually given as encouragement. This post treats it as a method. Building for yourself is discovery with perfect access to one user, and it has a predictable blind spot: the parts of your judgment that are really facts about you.
Why building for yourself works: it is discovery with perfect access
Many software projects fail in discovery, not in code: the team builds the wrong thing well. Building for yourself removes the hardest part of discovery, because you don't have to infer the problem from interviews. You live it. In practice that gives you three kinds of data that other projects pay heavily for.
Requirements from observed behaviour, not opinion. You know the workaround you use today, how often you use it and where it hurts. That's better evidence than anyone's answer to "would you use an app that…?"
Motivation tied to recurring pain. Projects slow down around the point where the easy parts are done. If the problem still costs you time every week, you have a reason to push through that a hypothetical user can't give you.
A feedback loop measured in minutes. You use the tool, notice what's wrong and fix it, without recruiting anyone or scheduling a test.
Eric Raymond put the first point as lesson 1 of The Cathedral and the Bazaar: "Every good work of software starts by scratching a developer's personal itch." Lesson 6 is the one people forget: "Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging." The itch starts the project. Other users improve it.
The test: can you name the last three times you hit the problem, with roughly when and what you did instead? If you can't, you have an idea, not an itch, and you lose the main advantage this approach offers.
Measure the itch before you scratch it
The cheapest discovery move is to log the problem before writing any code. For two weeks, every time the problem happens, write one line: the date, what you were trying to do, the workaround and how many minutes it took.
A running example (composite). A QA lead spends Monday mornings collecting flaky test results. She pulls the last week of CI runs, finds tests that failed and then passed on retry, pastes them into a spreadsheet, and messages the owning teams. Her two-week log shows the job takes about 70 minutes each Monday, and twice in those two weeks she missed a flaky test that a team later spent an afternoon chasing as a real bug.
That log turns "this is annoying" into a decision.
Question | From the log |
How often? | Weekly, plus ad hoc checks before releases |
How long each time? | About 70 minutes |
Yearly cost | 70 minutes × 46 working weeks ≈ 54 hours |
Cost of mistakes | Two missed flaky tests in two weeks, each costing another team hours |
Build budget | Two weekends, about 20 hours |
Payback | 20 hours ÷ 70 minutes ≈ 17 weeks of use, before counting the missed tests |
The log also shows what the tool really needs to do. Her workaround had four steps (pull runs, detect retries, group by owner, notify), and the log showed that grouping by owner took most of the time. That became version one. Notification could stay manual.
The test: keep the log for two weeks. If the yearly cost is smaller than the build budget and the problem causes no mistakes, use a better workaround and don't build. If the log shows one step taking most of the time, build that step first.
Where a sample of one misleads you
Two well-studied biases explain where building for yourself goes wrong.
The false consensus effect (Ross, Greene and House, 1977) is the tendency to see your own choices and judgments as relatively common and appropriate, and to see alternatives as unusual. Applied to a tool: you assume that how you think about the problem is how everyone thinks about it.
The curse of knowledge (Camerer, Loewenstein and Weber, 1989) is that better-informed people find it hard to imagine how things look to someone without their information, even when they are trying. Applied to a tool: you can't see what is confusing, because you already know the answer.
Neither bias is a reason not to build for yourself. Both point to three specific places where your judgment is likely to be a personal assumption rather than a requirement.
Your definitions. The words and categories you use become the data model. In the example, the QA lead defined "flaky" as "failed, then passed on retry, on the same commit". That rule is in the database schema. Another team defines flaky as "fails more than 2% of runs over 30 days", whether or not a retry passed. To that team, her tool's numbers are simply wrong.
Your environment. Your repository layout, CI system, operating system and accounts. Torvalds' AT hard disks are the classic case. In the example, the tool assumes test owners can be read from a CODEOWNERS file, which her team keeps up to date and others don't.
Your tolerance. You'll put up with rough edges, missing error messages and a manual setup step, because you know the workaround. A second user won't.
The first category matters most, because definitions are expensive to change once data has been collected under them. A rough UI can be fixed later. Data recorded under one definition of "flaky" can't simply be re-scored under another.
The test: list the nouns in your data model and the rules that compute anything (thresholds, categories, statuses). For each, ask: "Would a colleague with the same problem define this the same way?" Mark every one you're not sure of. Those are your untested assumptions.
Design for one, on purpose
Once you know which choices are personal, you can make them deliberately. A tool for one person doesn't need configuration screens, user accounts, permissions or a polished setup. Building those before anyone else uses it is the most common way a personal tool turns into an unfinished product.
A few things are still worth doing even for one user, because they keep the tool alive and keep the door open:
Keep the data safe and portable. Back it up, and store it in a format you could read without the tool (a database you can query, or CSV). The data is often worth more than the code.
Write down your definitions. One short file that says what "flaky" means, where owners come from and what the tool assumes about the environment. This costs ten minutes and becomes the list of things to make configurable if anyone else ever uses it.
Keep the personal assumptions in one place. Put paths, thresholds and names in one configuration file or module, not scattered through the code. That isn't building for others. It is making the eventual change a small one.
The test: if you stopped using the tool for three months, could you get it running again from your own notes in fifteen minutes? If not, write the notes now, while you still remember what the tool assumes.
Run the second-user test
The step from "it works for me" to "it works for people like me" is where most of the lessons are. Treat it as a test, not a launch.
Pick a small number of people who have the same problem. Jakob Nielsen's widely used model for usability testing estimates that five test users find about 85% of the usability problems in a design, and recommends 3 or 4 users per group when the users fall into distinct groups. For a personal tool, two or three people from your own context, plus one or two from a different team, is enough to see the pattern.
Then run it the same way each time:
Give them the tool and a real task, using their own data where possible, and say nothing. Write down every point where they stop, ask a question or do something you didn't expect.
Don't help until they are truly stuck. Every time you explain something, you've found a place where your knowledge was filling a gap in the tool.
Ask about past behaviour, not opinions. "How did you handle this last week?" tells you more than "Would you use this?", which most people answer politely. Rob Fitzpatrick's The Mom Test is a short guide to asking questions people can't answer just to be nice.
Then sort what you saw.
Stall point (example) | Cause | Category |
"Why is this test not flaky? It fails all the time." | Different definition of flaky | Definition: change the model or make the rule explicit |
Tool shows no owners for half the tests | Team doesn't maintain CODEOWNERS | Environment: needs a fallback owner source |
Couldn't find where to set the CI project | Setting only exists in a config file | Tolerance: add a setup step or a clear error |
Grouping crashed on a test name with a slash | Bug | Bug: fix it |
In the example, three of the four second users stalled on the definition of "flaky". That one finding mattered more than all the interface problems put together, and it never showed up in six weeks of the QA lead using the tool herself.
The test: after two or three sessions, count stalls by category. If most are bugs and tolerance issues, the tool generalises well and needs polish. If most are definition or environment issues, your tool encodes your team's way of working, and generalising it means changing the data model, not the interface.
Decide whether to generalise
Building for others is a different project with different costs: support, configuration, accounts, documentation and, if it becomes a product, everything in going from side project to SaaS. Decide on evidence, not on how proud you are of the tool.
What you see | What it suggests |
Second users try it once and go back to their old workaround | Keep it personal. It solves your version of the problem. |
They keep using it, but only after you set it up for them | Share as-is with people like you. Don't generalise yet. |
They come back unprompted in week three, and ask for it when it breaks | Real demand among people like you. Generalise the parts that stalled them. |
People outside your context ask for it without being shown | Worth treating as a product decision, with its own discovery |
The strongest signal is unprompted repeat use: someone using the tool in the third week without being reminded, and noticing when it's down. Compliments in the first session are the weakest signal. When the evidence is mixed, knowing when to pivot and when to persist covers how to make that call.
The test: three weeks after the second-user sessions, check without asking: are any of them still using it? Count the people, not the praise.
Learning projects: keep the problem small
Building something you'll actually use is also the best way to learn a new technology, because the concepts attach to a problem you care about. The risk is stacking unknowns: a new language, a new framework and a problem you don't fully understand yet, all at once. When the project stalls, you can't tell which one caused it.
Pick a problem you already understand well, ideally one you've already logged, so the new technology is the only unknown. The QA lead could rebuild her tool in a new framework precisely because the problem was fully specified by her log and her definitions file. If you are choosing the technology itself, choosing your first programming language covers that decision.
The test: before starting a learning project, write the problem down in five sentences. If you can't, you're learning two things at once.
What to do this week
Pick the problem you most often think "someone should build a tool for this" about. Start a log today: one line each time it happens, with the minutes it cost. If you've already built the tool, do the other half instead: write your definitions file, then list the nouns and rules in your data model and mark the ones a colleague might define differently. Then find one person with the same problem and watch them use it for twenty minutes without helping.
Final takeaway
Building for yourself is the best discovery there is for a sample of one: real requirements, real motivation and instant feedback. Its blind spot is predictable: your definitions, your environment and your tolerance for rough edges look like requirements when they are facts about you. Log the itch before you build, write down what your tool assumes, and let a few people with the same problem show you which assumptions were yours.
Sources
Torvalds, L., "What would you like to see most in minix?" (comp.os.minix, 25 August 1991): "just a hobby, won't be big and professional like gnu"; "I'd like to know what features most people would want"; "probably never will support anything other than AT-harddisks, as that's all I have". https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/SwRavCzVE7gJ
Raymond, E. S., The Cathedral and the Bazaar: lesson 1, "Every good work of software starts by scratching a developer's personal itch" (section "The Mail Must Get Through"), and lesson 6, "Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging" (section "The Importance of Having Users"). http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
Ross, L., Greene, D. and House, P., "The 'false consensus effect': An egocentric bias in social perception and attribution processes", Journal of Experimental Social Psychology 13(3), 279–301 (1977). https://doi.org/10.1016/0022-1031(77)90049-X
Camerer, C., Loewenstein, G. and Weber, M., "The Curse of Knowledge in Economic Settings: An Experimental Analysis", Journal of Political Economy 97(5), 1232–1254 (1989). https://doi.org/10.1086/261651
Nielsen, J., "Why You Only Need to Test with 5 Users" (Nielsen Norman Group, 18 March 2000): five users find about 85% of usability problems under the model's typical assumptions; test 3–4 users per group when user groups are distinct. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
Fitzpatrick, R., The Mom Test: How to talk to customers and learn if your business is a good idea when everyone is lying to you (2013).
