Test the work before building the product
AI makes it easier for a small team to explore a business idea before committing to a full product. You can work through research, early designs and prototypes without staffing every first attempt. The useful result is not a larger pile of output. It is a better decision about what to build.
After roughly 5,000 hours working and experimenting with AI, I see an opportunity to do more early work yourself, then bring in people where their expertise matters. You still need to understand the customer and recognize what you cannot safely assess.
Before choosing a model or writing code, name the job. Who does it today? What takes too long, costs too much or regularly goes wrong? What would a better result look like? If those answers are vague, a polished prototype can hide the uncertainty rather than resolve it.
Suppose you want to help a small distributor compare supplier quotes. Start by watching how someone compares a few of them. They may care less about finding the lowest price than about noticing a missing delivery date or a different pack size. Build a test around the problem you actually find.
Give AI a job you can check
For that task, the first version could be a table, not an app. Ask AI to extract the supplier, quantity, quoted price, currency, pricing basis, pack size and delivery date. Keep prices as quoted—per item or per box—without converting them. Require a page, row or passage for each value, then check that it supports the entry. Mark missing information as unknown.
Try a few documents whose answers you have already checked. Include awkward cases: two currencies, a missing delivery date, a price per box rather than per item. Keep the task to extracting and flagging differences; do not silently turn it into currency conversion or a purchasing decision.
Then let the person who normally does the work try it. Where do they correct it? What do they still have to look up? Those observations tell you what the next version needs more clearly than another list of features.
This is useful even if you are not technical. Choose a task you know well enough to catch a plausible mistake. Use only information you have permission to share, remove private details and keep consequential actions—sending messages, making payments, changing records—under human control.
Measure the whole task
A fast answer is not necessarily faster work. Count the time spent preparing the input, checking the result and fixing errors. Compare that total with how the task was done before. Also ask whether the result is better, or whether useful work has become possible that was previously impractical.
For the quote table, source links can be more valuable than fluent explanations: they help someone verify a field without rereading every document. A visible unknown is often more useful than a confident guess. Design the workflow so that checking it is easy.
Keep a small set of test cases and rerun them when you change the prompt, model or workflow. A change that fixes one example may break another. If a task keeps failing in the same place, narrow what you ask AI to do or leave that step to a person.
You do not need a home server or an elaborate system to run this test. Start with the tools you have. Add infrastructure when you can name the limitation it will solve, not because a more complicated setup looks like progress.
Build around what people keep using
A working prototype shows that something can be built, not that it should become a business. For an internal tool, look for repeat use and a measurable improvement in the work. If you intend to sell a product, a small paid trial tells you more than someone saying they would pay. Ask what people would use if your tool disappeared.
Work through the economics before scaling. Include model usage, checking, support and maintenance in the cost of each completed task. For internal work, is the improvement worth that cost? For a product, does the price cover it? Cheap generation can conceal expensive human cleanup. Profit leaves resources for the next idea.
Choosing worthwhile work mattered before AI. It still does. What has changed for me is how much of an idea I can examine before committing more people and money to it.
That is why I believe a builders’ decade is beginning. A small team can use AI to turn an assumption into something people can try. Start with one problem, make the result dependable, and let what people actually use tell you where to go next.
Read next