When is a small AI tool worth building?

You probably have a few ideas already. A better way to compare offsite venues. A tool that checks whether a meeting request includes enough information. Something that pulls the right background together before a call.

The appeal is obvious. You know exactly where the annoying part of the work is, and you'd like it to go away.

The harder question is whether building something will help. A tool that takes an afternoon to create can be a great investment. It can also become another thing you have to check every Friday.

My starting point would be simple: build when there's a clear use for the result, the existing options leave a real gap, and the effort of running it makes sense. You don't need a spectacular idea. You do need a reason to keep using it after the excitement of building it wears off.

Start with what happens after the output

“It creates a report” tells you what the tool produces. It doesn't tell you whether the report is worth producing.

Who reads it? What do they decide or do differently? Does it replace something they already struggle with, or give them information they currently go without?

Take an offsite venue comparison. A useful version could turn proposals into a consistent view of room capacity, catering minimums, cancellation deadlines and costs that need confirming. You use that view to narrow the options and decide which questions to ask each venue.

A less useful version writes a polished summary of every venue's website. You still have to contact them for availability, find the missing charges and build the actual comparison yourself.

Both versions can look impressive. Only one has removed a meaningful chunk of the work.

Before building, finish this sentence:

When this gives me , I can without having to .

If the last blank contains most of the original job, the idea probably needs another pass.

Sometimes the benefit is work you weren't doing

Time saved is an obvious benefit. There are others.

Perhaps you'd like to prepare a short background note before every first meeting with a prospective partner. Doing the research manually for every call takes too long, so you reserve it for a few important meetings.

If AI can assemble a sourced first pass that takes a few minutes to check, more meetings may become worth preparing for. You haven't saved time against the old routine, because the old routine often involved no research at all. You've made better preparation affordable in terms of effort.

That still needs a test. Did the note help the executive ask a better question, spot a relevant connection or avoid repeating something already discussed? Or did it just add another document to their morning?

This is one of the more interesting opportunities for executive operations. There are useful checks, comparisons and bits of preparation that get skipped because doing them properly takes too much time. A small tool can change that calculation.

Don't label the new work “time saved.” Judge whether the improvement is worth the time it now takes.

You might need a small interface, without AI inside it

AI can help build a tool without needing to run every time someone uses it.

A meeting-cost calculator needs arithmetic. An overlap finder needs time zones and availability. A request form needs sensible questions and a clear way to submit answers. Adding a model to those jobs can introduce cost and uncertainty without improving the result.

AI is more relevant when the input needs interpreting: comparing differently written proposals, finding possible commitments in meeting notes, or turning a rough request into a draft project outline.

Even then, check whether your existing software already does enough. A reusable AI conversation may suit one person doing occasional work. A shared tool becomes more interesting when several people need the same questions, checks and output without remembering a long set of instructions.

Anthropic's guidance for building AI systems also recommends beginning with a simple approach and adding complexity where it improves the outcome. That's engineering guidance, but the principle is useful here: the app should earn its extra moving parts. Read the guidance↗.

Do the slightly boring calculation

Count the full version of the job: gathering information, running the tool, checking the result, correcting mistakes and putting the finished work where it belongs.

Here's an illustrative calculation, using made-up inputs:

Doing it the way you do it now40 min

Doing it with the tool, including review and corrections15 min

Recovered each week25 min

Building it, once180 min

8 weekly uses before the build has paid for itself Twelve, if keeping it running costs another ten minutes a week.

That break-even ignores subscriptions, and it assumes the task itself stays the same. Both are worth checking before you commit the afternoon.

Now imagine the project ends in six weeks. That changes the decision. A reusable prompt may be enough. Or the tool may still be worth building because it prevents an expensive error, but you'd need to justify it on that basis.

Time recovered also isn't automatically money saved. If nobody's paid hours change, the immediate benefit is available time. Decide what you'd use it for.

Make mistakes easy to catch

For a first project, choose something where you can recognize a good answer and inspect the important parts without redoing everything.

In the venue example, each extracted cancellation deadline could sit next to the relevant proposal page. A missing price should say “not provided.” Two conflicting prices should remain visible until someone confirms which applies.

That is more useful than a confident recommendation with no way to see how it was reached.

Consider the consequences too. A private draft comparison is easier to experiment with than a tool that accepts a contract or sends messages to candidates. Start with approved information and limited access. If the tool will handle sensitive records or act in company accounts, involve whoever is responsible for those systems before connecting it.

Also ask what happens when it fails. Will someone notice that a report didn't arrive? Can they complete the job manually? A small tool should have a simple way to stop using it without losing the work.

Try a useful slice before you build the rest

For the venue comparison, try a handful of proposals first. Include an awkward one with missing details and another where the attractive headline price excludes several charges. Use fictional or approved, appropriately redacted material while experimenting.

Then have the intended user work with the output. Watch what they still need to look up. Ask which part they would miss if you took it away.

The first version doesn't need a dashboard, account system or automatic connection to your inbox. Those features can wait until you've learned why someone needs them.

A temporary tool can be worthwhile too. Something built for a single leadership offsite doesn't have to become permanent software. Keep the useful output, record any decisions you need later, and retire the tool when its job is finished.

Know what would make you keep it

Before you spend another weekend improving the design, answer four questions:

Keep it if the benefit survives those questions. Simplify it if the useful part is smaller than the original idea. Drop it if the review and upkeep swallow the improvement.

There's plenty worth building in executive operations. The strongest place to start is a piece of work you understand well enough to know what a good result looks like, and a person who will be genuinely glad to have it.

Something here wrong or out of date? Tell us and we will correct it in the open.