How to build a small fix in a day

Most small business fixes don't need weeks. They need one clear problem, the plainest tool that works, and someone willing to put it in front of real staff before it's finished.

If you can't finish in a day, you've probably scoped it too big. Cut it in half. Then cut it again.

Start with one sentence

Before you open any tool, write this down:

Every Friday, Rosa retypes the week's catering orders from email into a notebook. It takes about an hour and she sometimes misses one.

That's the problem. Who, what, how often, what goes wrong. If you can't write it in a sentence or two, you don't know the problem yet. Go back to the ranking and look again.

Next, write what "fixed" looks like:

Orders go into one shared sheet when they arrive. On Friday Rosa prints the prep list from it. No retyping.

If "fixed" is vague, you'll never know when to stop.

Pick the dullest tool that works

This is the step where people go wrong, because the fun tools are tempting. Work down this list and stop at the first one that does the job.

1. Pen and paper, a whiteboard, a printed form
2. A shared spreadsheet
3. A form (Google Forms, for instance) that feeds a spreadsheet
4. A tool that connects two things you already use (Zapier or Make, for example)
5. A simple custom page or script
6. Anything bigger. Rarely worth it.

Most small fixes land on number 2 or 3. Spreadsheet or custom tool? goes through how to decide.

A day, roughly

Every job is different, but this pace works.

Morning: build the ugly version. Two or three hours. Make it work for the main case and ignore everything else. No colors. No edge cases. If you'd be embarrassed to show it, that's about right.

Late morning: test with real data. Use yesterday's orders, last week's appointments, an actual customer list. Fake data hides the real mess. If a name has an apostrophe, or half the phone numbers are missing a digit, you want to find out now.

Before lunch: show the person who'll use it. Sit next to them. Say "try it." Don't explain first. Watch where they hesitate and don't help for ten seconds. The hesitation is a bug in your design, not a problem with them.

Afternoon: fix what they hit. There will be three or four things. Fix them. Ignore everything else that comes to mind.

End of day: write five lines on how to use it. Where it lives, what to do, who to ask. A one-page handoff comes later. Five lines now is enough to start.

Then leave it alone for a few days. Check in on day two or three, because that's when real use shows up.

What to cut when it won't fit

If it's afternoon and you're not close, cut. Don't push on.

• Drop the second, third, and fourth use cases. Build only the one in your sentence.
• Drop any new login or account. People forget passwords for tools they use twice a week.
• Drop the report, the dashboard, the chart. Nobody asked for it.
• Drop "while we're at it." That's how a day becomes a month.

You can add later. You can't easily un-add something people have started depending on.

What goes wrong

It works on the laptop and nowhere else. Check it on the phone your staff really use. Half the fixes that fail are on screens too small to use.

It needs a new habit and there's no reminder. If using the fix means remembering a step nobody remembered before, put the reminder where they'll see it. A sticky note by the register works.

You build for the exception. One in fifty orders is unusual. Build for the other forty-nine and handle the odd one by hand.

The builder is the only one who understands it. If you're the only person who could fix it, you built it wrong. Use tools your client can open and understand.

You skip the test with real staff. The thing you were sure was clear is confusing. Always test with someone who didn't build it.

When it's done

It's done when the person from your first sentence uses it without you in the room. Not when it's pretty, not when it handles every case. That's a decent day's work. Come back to teaching staff to use it before you walk out the door.