Name the buyer
Write down the exact person who experiences the problem, pays for a solution, and can approve a pilot. If those are three different people, plan how the decision travels between them.
Don't stop here
Hand-picked guides our readers explore right after this one.
Master the 8-step framework for writing prompts that get results
Read the guideExpert guide to Claude prompts with XML tags, artifacts, and complex reasoning
Read the guideCreate stunning images with ChatGPT DALL-E integration, viral photo trends, and professional visuals
Read the guideFounder field guide · Checked August 13, 2026
The first job is not to train a model or build a polished chatbot. It is to find a painful, repeated workflow, prove that a specific buyer will pay for a better outcome, and learn where AI can perform safely enough to earn trust.
Michael Okeje
Founder research and AI workflow analysis · Last updated August 13, 2026
I would not begin with “What can the latest model do?” That question produces impressive prototypes and vague businesses. I would begin with: “Which person is repeatedly spending time on a task they would gladly pay to complete faster or more accurately, and what evidence will prove that the new workflow is better?” The answer determines your product shape, data requirements, sales motion, and cost ceiling.
This is also where many AI startup plans become too broad. “AI for healthcare,” “AI for small business,” and “an AI employee” are markets or slogans, not first products. A useful first wedge sounds more like “a reviewed insurance-claim intake summary for independent agencies” or “a research brief that turns a procurement team's approved sources into a comparison memo.” The narrower promise gives you something a customer can accept or reject.
Use these steps in order. Each one should produce evidence that changes the next decision.
Write down the exact person who experiences the problem, pays for a solution, and can approve a pilot. If those are three different people, plan how the decision travels between them.
Watch the work happen. Record inputs, handoffs, systems, exceptions, time spent, rework, and the point where a human must exercise judgment. A transcript of an interview is not the same as observing the task.
Estimate volume, time, error cost, delay cost, and revenue or risk attached to the workflow. You need a baseline before you can say the AI product creates value.
Offer one outcome, such as a reviewed claims summary or a qualified research brief, rather than a platform with ten features. Ask for a paid pilot or a concrete commitment tied to access and feedback.
Decide in advance what would disprove the idea: low willingness to pay, unacceptable accuracy, missing data, long review time, an incumbent feature, or an acquisition cost you cannot support.
The SBA describes traditional plans as detailed and lean plans as focused on the most important elements. For an early AI startup, a one-page plan is useful because it exposes assumptions before you spend months building. I would include the following, with a sentence or number in every box:
Who pays? What job are they doing now? How often does it happen? What does the current workaround cost in time, money, delay, or risk?
What single output or action will be better? What inputs are required? Which parts remain human-reviewed? What does “good enough” mean in observable terms?
How will the first 20 qualified users hear about you? Name the community, partner, outbound list, integration, or existing service channel. “SEO” is not a complete first-customer plan.
State expected revenue per customer and cost per completed workflow, including model calls, retries, storage, review, support, payment fees, and acquisition.
List privacy, security, copyright, bias, reliability, and misuse risks. State what the system cannot do, what needs approval, and how to stop or reverse it.
Write the next test and the threshold that passes or fails it. For example: three teams provide historical cases, the system reaches 90% field accuracy, and two teams agree to a paid pilot.
The same customer problem can produce a service, a software product, an API, or a data product. Do not choose the most fashionable shape. Choose the shape that lets you deliver a reliable outcome and learn quickly.
Best when: You understand the customer's work and can deliver the outcome before the software is complete.
Watch for: The product may remain a labor-heavy agency with weak margins.
Compare the modelBest when: A repeatable process can be packaged for many similar teams.
Watch for: Integrations, onboarding, support, and model costs are easy to underestimate.
Compare the modelBest when: A technical buyer needs a capability inside an existing application.
Watch for: Usage can be spiky, switching costs can be low, and infrastructure becomes the product.
Best when: Teams need trusted labels, tests, monitoring, or domain-specific evidence.
Watch for: Data rights, quality controls, and procurement can slow the sales cycle.
Model spend is visible, so it attracts attention. It is not always the largest cost. An AI product can lose money through support, failed jobs, retrieval, storage, review, sales engineering, refunds, and the work required to handle unusual inputs. Build a cost sheet around one completed customer outcome:
| Cost line | Question to answer | Why it changes the plan |
|---|---|---|
| Model and tool calls | How many calls, retries, and tool actions complete one task? | Usage can grow faster than customers if loops are not bounded. |
| Human review | What percentage needs approval or correction, and how long does it take? | A “90% automated” workflow can still have poor margins if the remaining 10% is difficult. |
| Data and infrastructure | What must be stored, indexed, encrypted, monitored, or exported? | Retention and compliance requirements can dominate a simple prototype. |
| Acquisition and support | What does it cost to win and onboard a customer? | Low gross margin cannot carry a high-touch sales motion indefinitely. |
Stripe's guidance describes recurring, tiered, usage-based, and hybrid billing as legitimate choices. The practical lesson is to make the pricing unit legible to the buyer and connected to the value they receive. A startup can change its plan later; it cannot easily regain trust after an invoice surprises customers.
NIST's AI Risk Management Framework and Generative AI Profile are useful references even for a small company. You do not need an enterprise bureaucracy, but you do need to know what data enters the system, what the model may infer, who can act on an output, and how an incident is handled. OpenAI's practical agent guide similarly recommends guardrails and human intervention when an agent exceeds a failure threshold or attempts a high-risk action.
Give the system the least access needed for the current job. Separate reading information from changing records, sending messages, approving payments, or deleting data.
Keep real, representative examples with expected outcomes. Test normal cases, ambiguous cases, adversarial inputs, and the edge cases that create expensive mistakes.
Make escalation visible and easy. A human should know why a task was handed over, what the system attempted, and what evidence it used.
Do not claim the system is accurate, autonomous, or secure in the abstract. State the tested scope, review policy, retention practice, and known limitations.
Here is the sequence I would use for a founder building a document-heavy workflow product for a small professional-services team.
I would pause on a general-purpose chatbot with no proprietary context, an autonomous system that can take irreversible actions, a product whose only differentiation is a prompt, and a dashboard that reports model output without a decision attached. These ideas can become useful later, but they do not create a clear first learning loop.
I would also be cautious about regulated, high-stakes workflows until the team has the expertise, controls, insurance, and review process to support them. The fact that a model can produce a plausible answer is not evidence that a company should delegate the decision. Start where the outcome is valuable, the mistake is detectable, and the user can recover.
Before raising money or adding features, score the idea from 1 to 5 on pain, frequency, willingness to pay, data access, output verifiability, distribution, gross margin, and reversibility of failure. A high technical score with low customer pain is not a startup. A modest model with a painful workflow, clear buyer, reliable review, and repeatable distribution can be.
Once the idea passes, use our AI agent business models guide to choose how it should make money, then connect the operating plan to the broader AI for Business hub. For technical architecture, the AI agent build guide covers tools, evaluations, and handoff patterns.
No. Most early AI startups should begin with an existing model or API and compete on a specific workflow, proprietary context, integrations, evaluation, distribution, or service quality. Training a model becomes rational only when you have a defensible data advantage, a clear performance requirement, and enough demand to support the substantial infrastructure and research cost.
The best first customer is a reachable person who already feels the problem, can describe the current workaround, and can authorize a paid pilot. A narrow team with a high-frequency workflow is usually more useful than a broad market such as 'all small businesses.' Look for a buyer who can give you real examples, approve access to the relevant data, and tell you what an acceptable error costs.
There is no honest universal number. A narrow service-assisted prototype can be built with modest software and model spend, while a regulated or high-volume product can require substantial security, engineering, review, and infrastructure investment. Budget by workflow volume, model calls, storage, observability, human review, support, and customer acquisition rather than by a single headline figure.
Start with the value and cost of the completed workflow, then test a pricing unit customers can understand. Common options include per seat, per completed task, usage credits, a platform fee plus usage, or a managed service fee. Include a margin for retries, evaluation, support, and exceptional inputs. Do not promise unlimited usage until you know your cost distribution.
A useful plan states the customer and painful workflow, current workaround, proposed product, evidence of demand, competitive alternatives, distribution path, pricing hypothesis, cost model, risks, milestones, and the tests that would change your mind. The U.S. Small Business Administration recognizes both detailed traditional plans and lean plans; choose the format that helps you make the next decision.
The common mistake is starting with a model capability instead of a painful, measurable workflow. A demo can look magical while the real product fails because data is unavailable, outputs cannot be verified, the customer will not change behavior, or the cost of review exceeds the savings. Begin with the user's job, baseline, and acceptance test.