Start with a problem, not a tool. List the tasks that eat your time or cause the most errors, pick the most tedious and repetitive one, and ask whether AI could take a first pass at it. The best starting point is boring and familiar, where a small improvement is easy to notice and hard to argue with.
Information current as at 5 July 2026
The reason AI feels overwhelming is that everyone talks about the tools and no one talks about the starting point. Tools are endless and change monthly. Your problems, on the other hand, are specific, familiar and few. Start from what already frustrates you, and the question of where to begin answers itself.
The most common false start is choosing a tool first and then hunting for something to use it on. That is backwards, and it leads to expensive subscriptions that solve nothing you actually needed solved. The better order is to name a real problem you already have, then ask whether AI is a sensible way to ease it. A problem gives you a way to judge success: you know whether the pain went away. A tool without a problem gives you nothing to measure against, so you end up impressed but no better off.
Spend a week noticing where your time actually goes. The best first tasks share a shape: they are repetitive, they are done often, they follow a rough pattern, and they do not need much judgement or carry much risk. Writing similar emails over and over, summarising long threads, pulling the same numbers into the same report, tidying messy data, drafting first versions of routine documents. If a task makes you sigh because you have done it a hundred times, it is a candidate. If it needs deep judgement or touches money and law, it is not the place to start.
If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.
People want their first AI project to be impressive, a customer-facing chatbot, something clever. Boring is smarter. A dull internal task is low-risk, easy to check, and its improvement is easy to see, an afternoon a week handed back. If it goes wrong, no customer notices. The flashy customer-facing idea, by contrast, is the one most likely to embarrass you if the tool gets it wrong in public. Prove the idea somewhere quiet and forgiving first, then decide whether to take it anywhere visible.
Once you have a candidate task, define it tightly. What exactly goes in, what should come out, and how will you know the output is good enough? Write that down in a sentence or two. Then try it for real on genuine work, not a tidy demo, keeping your current process running alongside so nothing depends on the experiment. Give it a couple of weeks, then judge it honestly against the outcome you named. That is a first project: one problem, one task, one clear test, and a way back if it does not work.
If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.
Whether you can name exactly what you want built, or you just know something is leaking, the next step is the same conversation.