“I Wish There Was an App for This”: How to Turn a Business Problem Into Software

You've had the thought. Probably this week. Usually somewhere around the fourth time you've typed the same thing into the same box:

“I wish there was an app that just did this.”

That sentence is the most useful thing in this article, and it doesn't need translating into anything more professional. You don't need to know whether you're describing automation, an internal tool, a workflow, a dashboard or a SaaS product. Those are words for the people building it. What matters is that you noticed.

Here's how to get from there to something that exists — including the steps where you find out you don't need it built, which are the most valuable ones.

i build things i wish existed. this is the process, written down.

1. Name the problem, not the solution

The first instinct is to describe the app. Resist it for ten minutes, because the app in your head is a guess and the problem is a fact.

Write one sentence in this shape: Every time X happens, I have to Y, and it takes Z. No technology in it.

• “Every time someone books, I have to copy their details into three places, and it takes ten minutes.”
• “Every Friday I have to pull four reports and paste them into a spreadsheet, and it takes two hours.”
• “Every time a job finishes, I have to write the same certificate by hand, and it takes twenty minutes and I get it wrong sometimes.”

If you can't write that sentence, the problem isn't ready yet — and building something now would produce a tool that misses. If you can, you've done the hardest part, and you've written most of a specification without knowing it.

2. Work out who else has it

Just you? Then you want a tool. Everyone in your business? Then you want a tool that several people use, which is a different and slightly bigger thing. Your customers? That's different again, and it's the version that can make money rather than save it.

This answer changes almost everything downstream — accounts, permissions, how careful it has to be — so answer it honestly rather than ambitiously. “Just me, on a Friday” is a perfectly good answer and produces a much cheaper tool.

3. Describe the current workaround in detail

Don't skip this. It feels like admin and it's the most valuable thing you'll write.

Write down every step you actually do, including the stupid ones. Which tab you open first. Where the file lives. The naming convention you invented. The bit you always get wrong. The colour code in the spreadsheet that means “chase this one”.

Those workarounds aren't embarrassing — they're a specification written in the only language that never lies: what you actually do. Every good tool I've built came out of somebody's list of stupid steps.

4. Put a number on it

Minutes per time × times per month × 12. That's it.

Twenty minutes, twice a week, is about 35 hours a year. Two hours every Friday is closer to 100 — two and a half working weeks, gone, on copying and pasting.

Then add the errors. Not the time to fix them — the cost of them. A wrong figure on a quote. A missed appointment. The customer who was told the wrong thing. That's frequently bigger than the hours and almost nobody counts it.

Now you have a budget. If the answer is “this costs me about six hours a year”, stop here — you've just saved yourself a lot of money and the rest of this article isn't for you.

5. Check whether it already exists

Please do this properly, because it's free and it's the answer surprisingly often.

• Search for the problem in your own words, not in technology words
• Check whether software you already pay for does it on a different plan
• Check its settings, templates and automation features — there's usually a tab nobody has opened
• Ask someone in the same trade what they use
• Search for the problem plus “template” or “spreadsheet” before searching for “app”

Two-thirds of “I wish there was an app” moments end here, and that's a win, not a disappointment. The remaining third are the interesting ones — and by now you'll be able to say exactly why the existing thing doesn't work, which is worth more than the search was.

6. Work out which kind of answer it is

This is where the vocabulary finally becomes useful. There are five possible answers and only one is “build custom software”.

There's a sixth answer that belongs on the list: change the process. Sometimes the step causing all the pain exists because of a decision made four years ago that nobody has revisited. Removing it costs nothing. Always check.

If you want the longer version of this decision, it's here, and the fifteen most common automation candidates are here.

7. Define the smallest useful version

This single step decides whether the project succeeds, and it's the one people get wrong — including me, repeatedly, which is why I can be specific about it.

The smallest useful version is not a demo, and it's not “version one of the big thing”. It's the least you can build that you would genuinely use every week.

The test: would you use it, in its stripped-down state, this month? If you'd wait for the other features first, then the other features aren't extra — they're the actual product, and you've mis-scoped it.

A real example of getting this wrong. One of my own builds started in my head as a machine that would capture every interesting moment of a project — and I worked out, before writing it, that it was also a second full-time job. Any product that makes the customer do the remembering, the documenting and the packaging isn't helping them; it's assigning homework. I wrote that one up honestly.

The smaller version wasn't a compromise. It was the good version.

8. Put it in front of real people

Real people, real work, real data. Not a demo where everyone nods politely.

If it's for you, use it for two weeks before changing anything. If it's for your team, watch someone use it without helping them — painful, and the fastest way to find out what's actually wrong. If it's for customers, get two of them using it before you build it for all of them.

What you're looking for isn't praise. It's the moment somebody opens the old spreadsheet anyway. That tells you exactly what's missing, and no amount of asking would have got it out of them.

9. Improve it based on use, not on ideas

After a month of real use you'll have a list. It will look nothing like the list you'd have written at the start, and that's the entire argument for doing it in this order.

Fix what's actually in the way. Resist features that sound impressive. The tools that last are the ones that kept doing one job well while everything around them got more complicated.

What this looks like when it works

Two of mine, because it's easier to trust a process you can see the output of.

[Print Your Celebration](/builds/print-your-celebration) started as wanting the party to look like somebody planned it, without becoming a designer to get there. It's live at printyourcelebration.com.

[Baby Shower Game Maker](/builds/baby-shower-game-maker) is the same problem, narrowed to one moment. The insight that made it work is a scoping one: the artwork and layout stay fixed and only the date, wording and colours change. That's personalisation that can't make the piece ugly — and it's a much smaller thing to build than “a design tool”. It's live at babyshowergamemaker.com, with 28 theme collections.

And one that's still in progress, since pretending otherwise would be silly: [Zingg Homeschool OS](/builds/zingg-homeschool-os) came from watching homeschool families run a school across a dozen systems, with the parent acting as the integration layer between all of them. That's in development, not launched, and the workbench says so.

Different problems, same nine steps. None of them started with “I'd like to build an app.” All of them started with something being annoying enough to write down.

You don't need the right words

If you take one thing from this: the sentence “I wish there was an app that just did this” is a perfectly good brief. You don't need to know whether you want automation or an internal tool or a dashboard. Working that out is my job, and it takes about one conversation.

What you need is the problem, in your own words, with an honest number attached to how much it's costing you. Bring that, and the worst case is that I tell you it's a setting in software you already own — which is a good afternoon for you and no invoice from me.