The uncomfortable part
If your team does the same task three different ways, an app will not choose one. It will get built to support all three, at cost, and then break in a fourth way nobody mentioned.
Code is cheap now, which makes this worse. You can describe an app to ChatGPT, Claude, or Gemini and have something that looks like an app running by lunch. It has never been easier to build the wrong thing quickly. We wrote about that in Code Got Cheap. Judgment Didn’t. The bottleneck moved from typing to deciding.
Four questions to ask before you build anything
1. Can you describe the process on one page?
Who does what, in what order, with what information, and what happens at the end. If you can’t, nobody can build it, because nobody knows what “it” is.
2. Does your team already follow it?
A process that lives in one person’s head isn’t a process. It’s a dependency. If people improvise, fix that first. Software will lock in the chaos.
3. Is this workflow what makes you money, or just how you run the business?
If it’s how you differentiate, custom can be worth it. If it’s standard, like invoicing, scheduling, or basic project tracking, someone else has almost certainly built it, and you can buy it.
4. Does an existing tool cover most of it?
If yes, adapt your process to the tool. You’ll spend less and get updates you didn’t have to build.
How to read your answers
- No to 1 or 2: you have a process problem. Do that first. It’s cheaper than any build and it makes every later decision clearer.
- Yes to 1 and 2, yes to 4: buy the tool. Move on with your week.
- Yes to 1, 2, and 3, no to 4: now you have a real case for custom software. You know what you’re building and why.
Notice the order. The build decision is the last one, not the first.
Two hypotheticals
These are invented, but you’ll recognize them.
The onboarding maze. A services firm wants an app to automate client onboarding. Ask how onboarding works and you get three answers, one per account manager. Each is a little different: different forms, different order, different follow-up. The app request is really a request for someone to decide how onboarding should work. Once they do, a shared checklist and one template may be all they need.
The report that’s always late. A team wants software to produce a weekly report. The real issue is that three people keep the source data in three places, in three formats. A tool that builds the report won’t make them agree. Agreeing on one place for the data will, and the report might then take ten minutes in a spreadsheet.
In both cases the request was for software. The need was a decision.
What “fixing the process” actually looks like
It’s less dramatic than it sounds.
- Map it. Write down the steps as they really happen, not as they should.
- Find where work waits. Handoffs, approvals, and re-typing are usually the culprits.
- Pick one way. Standardize on the version that works best and drop the rest.
- Test it cheaply. A shared spreadsheet or an off-the-shelf tool is enough to find out whether the new process holds.
- Then decide. If the process is sound and the tools genuinely can’t support it, you’ve earned the right to build.
Why we start with a diagnostic
Every engagement here starts with a fixed-fee diagnostic, and most diagnostics run two to four weeks. The point is to scope the actual problem before quoting for the work. We tell clients upfront if the problem doesn’t justify the cost. We frequently find that someone came in thinking they needed a rebuild when what they needed was a better process, or the reverse.
That isn’t good for our bookings in the short term. It’s good for you, and we’d rather have the client who trusts us in a year.
What to do next
Write your process on one page this week. If you can’t, that is your answer, and it’s a useful one.
If you can, and you still think you need something built, book a strategy call. We’ll go through the four questions with you and tell you what we’d do, including “buy the tool.” You can also read how we approach technology strategy.
Not sure whether you need software or a better process? Let’s talk.
