How do you turn a repetitive work problem into a small software product?

Solve it by hand, repeatedly, for a while. The manual version tells you whether the outcome is worth having, and it doubles as the specification, because every awkward case you hit while doing it manually is a requirement you would otherwise have discovered halfway through building. Only once you are tired of doing it by hand, and you have found somebody else who built their own workaround for the same thing, is there a product worth writing.

This is the unglamorous version of the advice. It is also the version that survives having a full time job, because it front loads the cheap work and delays the expensive work until the expensive work is justified.

Most advice starts in the wrong place for someone with a job

The standard sequence is pick a market, find a gap, build, launch. It assumes you have time to be wrong several times, and that the cost of a wrong guess is a few weeks. With a day job the cost of a wrong guess is most of a year, so the sequence has to change.

Starting from a problem you personally have removes the largest source of error, which is inventing a user and then discovering they do not exist. You already know the problem is real, because it happened to you on Tuesday. What you do not yet know is whether it is worth solving with software, and whether anybody else would change their behaviour to get the solution.

You are not looking for a good idea. You are looking for evidence that somebody has already paid a price to get this outcome.

That reframe matters because it changes what you go looking for. Ideas are cheap to generate and impossible to evaluate. Evidence of somebody working around a problem is rare, specific and easy to recognise.

Record the friction while it is happening

Memory of a frustrating task is unreliable in a specific way: you remember that it was annoying and forget what actually made it annoying. So write it down at the time, in six lines.

1. What triggered it. What had to happen for this work to arrive. A date, a request, a file appearing, somebody remembering.
2. What you were trying to produce. The outcome, not the activity. Not "clean up the spreadsheet" but "a list of active clients with correct emails".
3. What you actually did. The real sequence including the ugly parts. This is the part people sanitise, and the ugly parts are where the product is.
4. Where it went wrong. Which step failed, produced a wrong result, or needed redoing.
5. What you did instead. The workaround. If you pasted into a text editor to strip formatting, that is a workaround and it is data.
6. Who else touched it. Anybody who waited on you or handed you the input.

Do this for a few weeks. The entries that repeat are candidates. If nothing repeats, you have an irritation rather than a problem, and irritations do not sustain a product through the boring middle.

If you want a systematic version of this, our guide on running a seven day friction audit covers how to capture the data without the logging itself becoming a chore.

Solve it manually first, and treat that as the spec

Before writing code, produce the outcome by hand. Not a mockup of the outcome. The actual thing, delivered.

This is usually possible with a spreadsheet, a checklist, a document template, a saved search, a browser bookmarklet or thirty minutes of your own labour. It is slow and that is the point: slow is affordable at low volume, and it teaches you things that no amount of planning would.

Three things come out of the manual version, and all three are worth more than the time it costs.

You find out whether the outcome is actually wanted. A surprising number of ideas fail here. You do the work by hand, hand over the result, and nobody uses it. That is a cheap failure and it is the one you most want to have early.

You collect the exceptions. Doing something manually twenty times produces a list of cases that break the obvious rule. The file that arrives in a different format. The month where two entries need merging. The client whose name is spelled two ways. These are exactly the cases that turn a two week build into a two month build when you meet them for the first time in code.

You end up with a specification. The steps you repeated are the happy path. The exceptions are the decision rules. Together they are more precise than anything you would have written in advance, because they were derived from reality rather than imagined.

There is a related discipline worth borrowing here. Writing the process down properly, with its inputs, decision rules and edge cases, is the same artefact whether the thing that follows it is a person, a script or a model. Our guide on writing a specification precise enough for a machine covers the format.

How to talk to other people without getting useless answers

At some point you need to know whether the problem is yours alone. This is where most validation goes wrong, because the obvious question is the worst one.

Do not ask whether they would use it. That question invites a polite yes. It costs the respondent nothing, it commits them to nothing, and it produces a number you will later treat as evidence. Almost everybody says the idea sounds useful.

Ask about the past instead, because the past is checkable.

• When did this last happen to you?
• What did you do about it?
• How long did that take?
• What did you try before that?
• What would have had to be true for you to do it differently?

Then listen for one thing in particular: a workaround. If somebody describes a spreadsheet they maintain, a folder convention they invented, a macro they wrote, or a colleague they ask, you have found a person who has already spent effort on this outcome. That is worth more than ten people saying it sounds great.

Listen also for the opposite. If the honest answer is that they left it undone and nothing bad happened, the problem is real but low value, and low value problems make bad products regardless of how common they are.

Build the version that finishes one job

The first version should solve one complete problem from start to finish for one clear kind of user. Complete is the load bearing word.

Half solving three problems feels more ambitious and delivers nothing, because a half solved job leaves the person doing it manually anyway, and they receive no benefit at all. A fully solved narrow job changes what they do on a Tuesday, which is the only thing that produces a returning user.

Some practical constraints that keep the first version finishable:

• One input format. Support the one you actually met. Add others when somebody asks twice.
• No accounts if you can avoid them. Accounts add password resets, data storage, deletion requests and a support burden before you have a single user.
• Stop at the boundary of judgement. Do the mechanical part and hand back control. The moment a tool tries to make the decision the user came to make, it needs to be right nearly always, and that is a much harder product.
• Fail loudly. A tool that silently produces a slightly wrong result destroys trust faster than one that refuses to run.

Watch what people do, not what they say

Once something is usable, opinions stop being interesting and behaviour starts. The questions worth answering are all behavioural.

Notice that most of these can be observed without analytics. For a small tool, three people you can talk to will teach you more than a dashboard, because you can ask them why.

When to keep going, and when to stop

Continuing is the default and it should not be. Stopping deliberately is a skill, and for someone building around a job it is the skill that decides whether the next attempt happens at all.

Keep going when the problem keeps occurring, people complete the workflow, somebody asks for access again, and you can name the next improvement without inventing it.

Stop, or pause, when any of these hold:

• Interest exists in conversation but nobody has used it twice.
• The workflow turns out to be different for every user, which means you have a consulting problem wearing a product costume.
• The problem happens rarely enough that people tolerate it.
• Each user generates questions only you can answer. Support cost is the specific thing that kills solo products, because unlike hosting it does not get cheaper per user.
• Getting the benefit requires people to change something they have no reason to change.

Pausing is not failure and the work is not wasted. The manual process still exists, the exception list is still true, and both are reusable the next time the same shape of problem appears.

A worked example from our own tools

Everything on this site came out of this sequence, and the results are uneven in a way that is worth being honest about.

Grid Maker exists because laying an alignment grid over a canvas was a thing we did repeatedly and manually, by drawing rectangles and duplicating them. The manual version was tedious enough to be worth automating and simple enough to finish. It does one thing, exports it, and stops. It is now the most visited page on the site, which was not predicted and is a useful reminder that the smallest tool is often the most used.

The Premiere Pro Scroll Amplifier came from a narrower irritation, a timeline that jumps to maximum zoom on one notch of the scroll wheel. The manual workaround was a mouse driver setting, which is also why the accompanying article explains that setting rather than only selling the tool. If the workaround is genuinely sufficient for some people, saying so is more useful than pretending otherwise.

DreamTools AE is the counter example. It is a larger idea, it is not finished, and it is marked as coming soon on this site with no purchase option, because shipping a payment page for something incomplete would be the wrong order. That is what a scope reduction looks like in public.

The pattern across all of them: the tools that got finished were the ones where the manual version was small and the outcome was obviously worth having. The one that is still open is the one where neither of those was true at the start.

Where this approach does not apply

Some honest boundaries.

This is a method for small, single purpose tools built by one person or a very small team. It does not describe how to build something that needs a network of users before it is useful at all, because the manual version of a marketplace is not a smaller marketplace, it is nothing.

It also assumes you can legally build on what you learned at work. Employment agreements vary enormously on intellectual property, and the safe move is to read yours and get proper advice rather than to assume. Nothing here is legal advice.

Finally, being the user is a strength for finding the problem and a weakness for judging the market. You will systematically overestimate how much other people care, because you have the problem more often than average. That is exactly what the workaround question is there to correct.

Where to start this week

Pick the task that annoyed you most this month and produce the outcome by hand once, writing down the six lines above as you go. Do not open a code editor. Do not register a domain.

Then do it a second time next week and compare the two notes. The steps that stayed the same are your happy path. The steps that changed are the reason this is worth building rather than remembering.

How this was put together: this is the sequence we use ourselves, described honestly including the parts that did not work out. It is not a study, there is no sample of founders behind it, and we have deliberately quoted no success rates or timelines because we have not measured any that would be meaningful at this scale. Where the article says a signal is strong or weak, that is a judgement drawn from building the tools on this site rather than from research.