Every business owner I talk to eventually asks me the same question: what should we actually build first? And almost every one of them has a half-formed idea already in their head, and it's almost always the wrong idea. It's the flashy one — a chatbot on the website, an agent that handles customer support end to end, something that sounds like it belongs in a demo video. I get why. That's what shows up in your feed. But the projects that actually pay off for a small business, especially the first one, rarely look impressive from the outside. They look boring. That's sort of the point.
After walking a lot of owners through this decision, I've landed on three filters that matter more than anything else, and they matter together, not separately. First: does this eat a large, recurring chunk of somebody's time right now? Second: if the AI gets it wrong, is the damage small and recoverable, or does it touch money, legal exposure, or a customer relationship you can't afford to bruise? Third: can you actually measure whether it worked, with a number you can point to, not a vibe? A project that's high-value but unmeasurable will die in an argument six months from now about whether it's 'really helping.' A project that's measurable but low-stakes and low-time-cost isn't worth the setup effort. You want all three at once, and there are usually more candidates than you'd think once you start looking with this lens instead of the 'what's cool' lens.
Start with where the hours actually go. Not where you assume they go — where they go. Most small businesses have some recurring task that eats real time every single week: drafting the same kind of email over and over, summarizing call notes, matching invoices to purchase orders, writing first-draft responses to routine customer questions, pulling together a status update from five different sources. These tasks share a quality: they're tedious enough that nobody enjoys doing them, but structured enough that a first draft from a model gets you most of the way there. That combination — high frequency, moderate structure, low enjoyment — is exactly what you're hunting for.
Now run it through the risk filter, and this is where the agents-versus-workflows distinction actually earns its keep instead of being a curriculum abstraction. A fully autonomous agent that decides things and acts on its own — sends the email, updates the record, tells the customer yes or no — carries real risk on day one, because you haven't yet built the judgment to know when it's wrong. A workflow where the model drafts and a human reviews before anything goes out carries almost none, because the worst case is you edit or delete a draft, exactly like you'd edit an email a junior employee wrote. For a first project, pick the version with a human still in the loop at the point where a mistake would actually cost you something. You can automate the review step away later, once you've watched it perform for a while and trust it.
The measurement question is the one people skip, and it's the one that determines whether you ever get a second project approved. Before you build anything, write down what 'better' looks like in a number: hours per week freed up, average response time cut in half, error rate on some check dropped from one in ten to one in fifty. Then actually track the before number for a week or two before you touch any AI, because your memory of 'how long this used to take' is unreliable and you'll want the real baseline later when someone asks if this was worth it. Without that baseline, six months from now you'll have a vague sense that things feel better, which is not something you can put in front of a partner, a spouse, or your own future skeptical self when deciding whether to invest further.
On model and cost, the first project is not the place to reach for the most expensive, most capable option available. Simple, well-scoped drafting and summarization tasks — which is what most good first projects are — get handled well by cheaper, faster models, and the cost difference compounds fast once you're running something daily. Save the expensive, heavyweight reasoning for problems that are genuinely hard: multi-step analysis, ambiguous judgment calls, anything where a cheaper model visibly struggles. Testing this yourself takes an afternoon, not a consultant. Run the same real task through a couple of options and see if the cheap one is actually good enough — it usually is, for the boring stuff, and 'boring stuff' is exactly what your first project should be.
On data, the rule is: use what you already have lying around, don't go build a new pipeline to feed it. If your first project needs you to first construct a clean database, tag a thousand documents, or stand up new infrastructure just to get started, you've picked the wrong first project — that's a phase-two problem at best. Your existing email threads, past support tickets, your FAQ doc, your pricing sheet, last year's proposals — that's usable data sitting right there. A good first project points a model at documents you already have and asks it to draft, summarize, or search, not one that requires you to build a data operation before you've proven the concept is worth the effort at all.
Here's roughly how this played out for a client running a small logistics brokerage. Their instinct was a customer-facing bot to quote shipping rates automatically — high visibility, high risk, and a nightmare to measure cleanly because a wrong quote costs real money and damages trust immediately. We backed up and picked something duller instead: drafting the routine 'checking in on your shipment status' and 'here's your updated ETA' emails that someone was writing by hand fifteen to twenty times a day, using data already sitting in their tracking system. A person still hit send. Nothing customer-facing changed unless a human approved it. We measured minutes-per-email before and after. It dropped from about six minutes to under one, on hundreds of emails a month, and there was a real number to show for it four weeks in. That gave them the confidence, and the case, to expand into the harder stuff later.
The projects I'd steer almost anyone away from as a first attempt: anything that talks to customers with no human checkpoint, anything that touches money or contracts directly, and anything where you can't articulate in one sentence what 'success' looks like as a number. None of those are off-limits forever. They're just second-project and third-project material, once you've built some internal track record and some intuition for where these tools are reliable and where they're not. There's no prize for skipping the boring first step, and the cost of getting an ambitious first project wrong — in trust, in money, in your own appetite to keep going — is much higher than the cost of a slow, careful start.
So the actual recommendation: pick the single most tedious, recurring, document-heavy task in your business that someone complains about weekly, keep a human reviewing the output until you trust it, use whatever model is cheapest that still does the job well, point it at data you already have sitting around, and write down your baseline number before you start. Run it for a month. Look at the number again. That's the whole framework. It's not exciting to describe, but it's the version of this that actually works, and it's what almost every successful first project I've seen has in common.
That's the whole point of what I've been writing about across this series — not the flashiest use of AI, but the one that actually moves a number in your business without putting anything important at risk. If you want to talk through what your specific first project should be, or you've picked one and want a second opinion before you build it, that's what I do. I write about this at 013labs.com.