The Smallest Fix That Works

Every Friday, the same twenty minutes: pull the week’s orders out of three different inboxes, retype them into a spreadsheet, and email the totals to a supplier. Nobody chose this process. It’s just the one that survived.

Multiply that by every habit a business has built around whatever worked at the time: the double-booked Saturday, three months running, because two calendars don’t talk to each other. The invoice that goes out wrong the same way every third job. The fifteen minutes spent digging up a customer’s last order before calling them back. None of it is a crisis. All of it adds up.

Fixing that kind of problem doesn’t start with buying a platform, and it doesn’t start with commissioning an app. It starts with a prompt.

Find the Task Worth Fixing

Not every annoyance deserves a project. The ones worth fixing share a few traits: they happen on a schedule, not once — every week, every new client, every quote. They involve moving the same information from one place to another by hand. Or they fail the same way more than once, not a different way each time.

Skip anything that’s already fast, or that only happens once in a while and costs little when it does — unless getting it wrong is expensive or dangerous enough that even a rare failure is worth preventing. Everything else on that list is worth the next step.

The Ladder: Prompt, Then Workflow, Then Tool

Fixing a task worth fixing follows a pattern, and most businesses can climb further up it than they think before spending real money.

1. Run It With AI, By Hand

Open Claude or ChatGPT and use it directly on the task: turn a set of job notes into an estimate draft, build the week’s purchasing list from what’s running low, draft a round of client follow-ups. Save the prompt that works, and read the output before anything goes out the door — every time, not just the first time. Testing this doesn’t require new software. A free account is usually enough to find out whether it’s worth pursuing further.

2. Make It Repeatable

A prompt that only works once is a trick. It only becomes a process once someone checks it against enough real cases that it stops surprising them — reliable because of that checking, not because it’s a prompt instead of an app. Write down what it needs as input, the instructions that produce a usable result, and a short check for catching what it gets wrong.

A tool like n8n can carry that further without anyone writing an app: pull the week’s orders from an inbox on a schedule, run them through the same prompt, and drop the result into a shared spreadsheet or send it as a text. Custom software doesn’t have to mean a full application. Often it means wiring a few existing pieces together, with the same checks built in, so a person doesn’t have to do the work by hand.

3. Build a Lightweight Tool, Only Once It Outgrows That

A workflow becomes a real, built tool when it outgrows what a prompt or an automation can hold: more than one person needs access to it, the records have to persist and be looked up later, copying information between systems becomes the actual bottleneck, or it needs integrations and reliability a workflow builder can’t guarantee on its own.

Built doesn’t automatically mean more reliable. A poorly maintained app can fail just as often as an unchecked prompt. It means reliability stops depending on one person keeping a workflow running by hand. Getting from that point to a working brief — a short prompt that turns the problem into something a developer can build from — is faster than writing a scope-of-work document from scratch.

YOU'RE HELPING A SMALL BUSINESS OWNER WRITE A BUILD BRIEF

You're helping a small business owner turn a real, everyday problem into a brief a developer can build from. Interview them one question at a time. Ask only one question per turn, wait for their answer, then ask the next. Keep every question short and in plain language. No jargon, no assumed technology.

Ask about, in this order:

1. The problem. What's the one task that eats the most time or causes the most mistakes right now? Get them to describe it as it actually happens today, in their own words, not the tool they think they need.
2. Who does it. Who performs this task today, how often, and on what: paper, a spreadsheet, a whiteboard, memory?
3. The trigger. What kicks this task off? A phone call, a walk-through, a new order, the end of the day?
4. The steps. Walk through it step by step, in order, exactly as it happens now.
5. What "done" looks like. How do they know the task is finished and done correctly?
6. What it touches. What other tools, accounts, or paperwork does this need to connect to or pull from: a POS system, QuickBooks, a spreadsheet, email, a specific vendor?
7. What it should never do. Anything this tool must not do, handle, or store: payment data it shouldn't touch, information that must stay private, a step that must always involve a person.
8. Who else uses it. Just the owner, or employees too? Any customers?
9. What "good enough" looks like for a first version. If only three things worked perfectly on day one, which three?

After the ninth answer, stop asking questions. Write a one-page brief with these sections:

- Problem (two to three sentences, in the owner's own words)
- Who Uses It
- The Workflow (numbered steps)
- Must Connect To
- Must Never Do
- First Version Scope (the three things that must work)
- Open Questions (anything still unclear that a developer should ask before starting)

Write the brief in plain language. No technical jargon, no assumed technology choices. It should be something the owner can hand to a developer, or to another AI tool, and have that person or tool understand exactly what to build.

A Prompt That Became a Business

A local restaurant used to handle social media the way most small businesses still do: three separate tools, one person doing the job of designer, copywriter, and scheduler at once. A Tuesday special had to go out on Instagram, Facebook, and the email list before dinner service, looking like the same restaurant each time.

A single social post took around twenty minutes: build the image in Canva, download it, upload it to Buffer, and write the caption by hand. An email, built the same way, could take up to an hour. Getting it done, across three tools, was slow. Getting it done consistently was worse — the process broke down as often as it worked, because the person posting got stuck being the designer instead of just posting.

That’s rungs one and two, in order. First, a saved prompt drafted a caption from a photo and a few details. Then that became a defined process anyone on staff could run the same way: pick a post type, fill in a short form, get back a branded photo with the caption already written, review it, and hit publish. Running two brands through those same four steps made the pattern obvious enough to build into something more. That something is MessageKit, a product I built, now used by other restaurants and small brands, not just an internal tool anymore.

The cost comparison holds up because it’s the same list both times. That subscriber list ran $330 a month through Square, the restaurant’s point-of-sale system’s email tool, or roughly $500 a month through Klaviyo, with comparable features, before counting a separate tool for scheduling social posts. MessageKit does the same job, on that same list, across social, email, and text, for $79 a month. Posting still routes through a connected Buffer account rather than a direct connection to Facebook and Instagram, because Meta requires an app review most small tools haven’t gone through — but the restaurant was already using Buffer, its free tier covers three channels, and it added no real cost or setup friction here.

The operational change: once a brand and its content modules are set up — a real, upfront investment, not an instant switch — a social post goes from idea to published in under five minutes, down from around twenty. Assembling an email from existing content modules takes under ten, down from as much as an hour. A text message, under five. And it’s still early — a beta in every sense that matters, not a finished tool with every rough edge sanded off.

Who Owns It?

Whether the fix ends up as a saved prompt, an automated workflow, or a built tool, settle one thing before it runs anything the business depends on: who owns it. Accounts, logins, and API keys should belong to the business, not to whoever built it. Whoever builds it should hand over plain documentation of what each step does and why, not just a working result. Back up the data behind it somewhere that doesn’t depend on one person’s laptop. And there should be a plain answer to an uncomfortable question: if the person who built this can’t be reached next year, who opens it up and keeps it running? A workflow only its builder understands isn’t a fix. It’s a new single point of failure with better branding.

Try Something Small Before Spending Big Money

Pick one task from that first list. Time how long it currently takes, or count how often it goes wrong, for a week or two — a real number, not an impression. Then run it through rung one: a prompt, using sample or made-up information, not a real customer’s data, not yet. Compare the two results side by side. Not just speed. Whether the output is something a person would actually be willing to send out. Only once that comparison holds up is it worth spending money on rung two or three.

What a Second Opinion Actually Gets You

The right call is rarely the same for two businesses doing the same job. A second opinion on a fix like this should end in one of four places: buy an existing platform, because the volume or the compliance work justifies it. Build something lightweight, because the job is specific enough to this business that nothing off the shelf fits. Combine a couple of tools with a small workflow between them. Or leave the process alone, because it isn’t actually costing enough yet to be worth fixing. Each of those is a real answer, and each comes with the reasoning behind it, not just a recommendation.

That’s the conversation worth having before a year of subscription fees, or a development budget, gets spent finding out the hard way.