Updated
Making AI useful beyond the people building it
Why useful AI products need to handle setup, review, and the work around the model
A small-business owner trying to collect overdue invoices has a fairly clear problem. They need to know who owes them money, which payments need attention, and what to say to those customers. AI could help with much of that work. Getting it to do so can still involve exporting records, explaining the process, checking the output, and moving everything back into the software the business uses.
All of that counts toward the time it takes to finish the job. If the owner has to work out the process each time, the benefit can be smaller than the capability suggests.
AI systems can search the web, find information in files, and work through computer interfaces when connected to the relevant tools. Developers have had access to combinations of these capabilities for some time, including through OpenAI’s agent-building tools released in March 2025. There’s useful work to build on. A person trying to solve an ordinary problem also needs a way to use those capabilities without taking on the work of designing the product themselves.
A chat window leaves a lot to the user
General-purpose assistants give people room to try things. You can use the same tool to draft a message, explore an idea, or work through a document. That flexibility is useful, especially when you’re still figuring out what you need.
It also means the user has to make quite a few decisions. They need to choose a task the system can handle, supply the right information, explain the constraints, and decide whether the answer is good enough to use. If the task involves another application, they also have to connect it or move the information themselves.
Someone who already understands the work can spot missing context and ask for another attempt. Someone less familiar with it may have trouble knowing what to check. A clear, confident response can make the task look finished while leaving those decisions unresolved.
Even with my background as a developer, I sometimes find these tools too broad. For some tasks, I’d rather use a product that already understands the process, asks for what it needs, and gives me a clear next step. I don’t always want to work out which instructions, files, or integrations will make the whole thing useful.
That becomes a product-design problem. The team building the tool needs to decide how much of the process it can handle and where the user’s judgment is still necessary. Leaving every choice open gives the user flexibility, though it can also leave them with most of the organizing work.
Why developers can get more out of unfinished tools
Developers are used to working with components that need to be connected. An API gives them a way into a system. A script can move information between applications. When something fails, they can inspect the result and change the implementation.
That makes early tools more useful to them. They can build around a missing feature or tolerate a rough setup because they expect to use it enough to recover the time spent. Some also enjoy making the system fit their own preferences.
I saw examples of this at Stripe Sessions. One engineer had built a system to track meals and automate work he disliked. Another was running ten Claude Code instances alongside a local language model. Those setups depended on knowing how to connect the tools, manage context, and repair failures. Someone looking for help with meals or routine work could reasonably decide the setup was too much.
This helps explain why two people can try the same technology and come away with different views of its value. A developer sees components they know how to use. A business owner may see several more decisions and another system to maintain.
Access to the model helps both of them. The amount of work required to get a dependable result still matters, especially for someone with no interest in building their own software.
The invoice workflow needs more than a good draft
For the owner collecting overdue invoices, a useful product would start with the accounting records. It would identify the invoices that need attention, prepare appropriate follow-ups, and make those drafts available for approval before sending them.
The product team has to understand how the business handles those invoices. It needs to decide which information to use, how the owner can correct a mistake, and what happens when the accounting connection fails. The owner should be able to see which records informed a message and what the system is about to send.
Those details affect whether the owner can trust the product with customer communication. If checking a draft means going back through the accounting system and reconstructing everything the tool did, the review may take away much of the time saved.
A demo can show the system producing a convincing follow-up from a clean example. A working product has to support the person whose records are incomplete, whose process differs from the example, or whose request the model misunderstood. It also needs to handle privacy, security, billing, and support. Each of those becomes part of the experience once someone depends on the tool.
Adding a chatbot can leave this work unresolved. The customer still needs to decide what to ask, locate the information, and transfer the answer into the next step. A chat interface can be useful within a process, but the team has to check whether it actually removes work from that process.
For the invoice example, that means following the task from identifying an overdue payment through reviewing and sending the message. Improving only the writing step may leave the owner doing nearly everything else.
Setup and review have to fit the value of the task
A company may accept a long implementation when the system will support work that happens throughout the day. A parent planning meals for the week needs a much smaller setup. The amount of effort that makes sense depends on how often the task happens and how much it costs to do today.
Maintenance belongs in that calculation too. Instructions need adjusting, integrations can fail, and changes in model behavior can affect a process that previously worked. A complicated personal system might be worthwhile for someone using it constantly. The same system could create more work for an occasional user.
Review adds another cost. The user needs enough information to check important decisions without repeating the whole task. Faster output helps only so much if it takes a long time to find and fix mistakes.
A useful product makes these parts understandable. The person should know what it helps them finish, what information it needs, and which actions require their approval. It should fit into the software and routines they already have where possible. When something goes wrong, they need a way to correct it and continue.
This is where I see room for more useful AI products. Better tools can give less technical people access to work they’d otherwise struggle to do. The product needs to make that work manageable and keep the important details available to the person responsible for the result.
A business owner should be able to use an invoice tool because it helps them follow up with customers. They shouldn’t have to learn about agents, retrieval systems, or model orchestration to keep it working. Handling that complexity is part of the job of the team building the product.