The App Is Easier to Build. The Business Still Needs to Run.

A tool for yourself can stay small

Suppose you want to compare your grocery spending across three months. You have the files, you know what the categories mean, and you can look at the result and notice that something seems wrong.

An assistant that helps you make that comparison is useful. You may save the script. You may throw it away after getting your answer. Either outcome is fine. You wanted to understand your spending, and the tool served its purpose.

A subscription for that same task now has more to explain. It might still be worth paying for convenience, syncing, or a service you enjoy using. But “we built the screen already” becomes a weaker offer when making your own screen feels accessible.

I like this direction. Software should be able to fit a small need without turning that need into a product category. Some tools deserve to be tiny.

The promise changes when other people depend on it

Now imagine a small service company using a custom scheduling tool. The first version shows appointments, customer addresses, and the technician assigned to each job. That sounds manageable.

Then a customer calls to reschedule while a technician is looking at the old appointment. Someone cancels a visit that has already been invoiced. An employee leaves, and their access needs to end. The owner wants to know who changed a customer’s address.

None of those situations requires a large company. They arrive as soon as a few people share responsibility for the same work.

The tool now holds information that people act on. A wrong answer can send someone to the wrong house, lose a service record, or leave a customer waiting. The team needs to agree on which record is current and who can change it.

This is where the comparison with a disposable personal tool starts to break down. The first screen may be just as easy to generate. The consequences of trusting it are different.

Someone has to own the ordinary failures

When people compare building and buying, the demo tends to get most of the attention. Can we reproduce the features? How quickly can we put together the interface? How much is the subscription?

I would also ask about a less exciting morning: the import ran twice, a customer cannot sign in, and yesterday’s records look incomplete.

Who investigates? Can they tell what happened? Is there a backup, and has anyone checked that it can actually be restored? Who talks to the people whose work is blocked?

A vendor does not automatically handle these things well. Paying an invoice is no guarantee of competent support. But when a product does handle them well, that work belongs in the comparison. Replacing the interface does not replace the service around it.

Building your own can still be the right decision. It means accepting that responsibility and giving someone the time and authority to carry it.

A company credit card does not make a tool essential

I do not think “B2B” protects every subscription. A report generator that takes a file and returns a chart can face the same pressure as a personal app. If a team can reproduce the result, check it easily, and move on, the existing vendor needs a convincing reason to stay.

Even a product that holds important records can become frustrating enough to replace. Being difficult to leave is a poor substitute for being useful. Customers eventually make expensive changes when the current system costs them enough time or trust.

For a builder, I think the better question is what people would miss after leaving. Reliable records? An integration that saves hours every week? Help from someone who understands their operation? Those are specific things you can improve.

If the only answer is that the customer would need to recreate a handful of screens, I would take that seriously.

Try the workflow before replacing the system

For a business owner, cheaper development creates an opportunity to fix awkward work. It also makes it tempting to replace a system before understanding everything it does.

I would start with one workflow. Pick something bounded enough to inspect: preparing a daily schedule, collecting information before a visit, or turning an export into a useful report.

Write down what goes in, what should come out, and which existing system keeps the official record. Use copies of data while testing. Include a cancellation, a duplicate, and a missing field. Find out what a person does when the tool cannot finish.

Then decide whether the result deserves a larger role. A useful helper can stay a helper. It does not need to become the company’s database just because the prototype worked.

I covered the broader tradeoff in Custom Software or an Existing App. The important part is comparing the ongoing work alongside the initial build.