Starting an AI Startup: Validate the Problem Before You Build

Starting an AI startup means finding a customer problem worth solving, then testing whether a small AI-assisted solution improves the work enough that someone will use it. Start with evidence from real people before investing in a polished product. Tools like fenbs keep the assumptions, decisions, and lessons outside any one chat, so your next experiment starts from what you learned.

A convincing demonstration answers “can this produce an interesting result?” A useful business experiment answers “does this help this customer finish this job?” Those questions need different evidence. You can use AI throughout the research, but customers must supply the reality that your model cannot invent.

What should you validate before choosing a model?

1. Choose one customer group and one recurring job they struggle to complete.
2. Watch or discuss a recent example, including the workaround they already use.
3. Write the riskiest assumption as a question that a small test can answer.
4. Offer a narrow solution, observe real use, and compare the outcome with the existing method.
5. Decide whether to continue, change the experiment, or stop, using the evidence you agreed to collect.

For example, “AI for property managers” is too broad to test. “Help a property manager turn a maintenance request into a checked contractor brief” names a person, an input, and an output. You can now ask how often that work happens, who checks it, and what an incorrect brief would cost in rework.

The SBA market research guide↗ (opens in a new tab) distinguishes existing research from direct customer research. Use public information to understand the setting, then speak to people who perform the actual job. A large market does not establish demand for your particular solution.

How can AI help you research a customer problem?

Ask an assistant to draft an interview outline, identify unclear terms, and organize notes you are permitted to share. Ask about a recent event: what triggered the work, what happened next, where it stalled, and how the person knew it was finished. Avoid leading with your proposed feature or asking whether an imaginary product sounds useful.

After each conversation, separate observations from interpretations. “The manager copied the address into three systems” is an observation. “They need an AI assistant” is your interpretation. Have the assistant attach a source note to each proposed theme and list evidence that points the other way.

An AI-generated customer profile can suggest questions, but it is not a customer interview. Do not count simulated enthusiasm as demand. Our guide to using AI at work covers the broader habit of giving assistants a bounded job and checking what they return. The AI at work hub collects other practical workflows.

What is the smallest useful solution you can test?

Test the uncertain part before building an entire service. A manually delivered result, a clickable demonstration, or a draft prepared with a general AI app may be enough. Tell participants what the test does, where people are involved, and what it cannot yet handle.

For the maintenance example, a person could review every generated contractor brief before the customer sees it. The experiment might test whether the manager can approve a draft with less editing than their existing template. It need not include automated dispatch, billing, or a conversation with every contractor.

Include difficult examples alongside easy ones: missing addresses, unclear requests, duplicate reports, or conflicting instructions. Set an explicit stopping point when a required fact is missing. Record both the model output and the human correction; a smooth final result can hide a large amount of unpaid review work.

What evidence should determine whether you continue?

Agree on your decision rule before looking at the result. Choose a customer outcome, a quality check, and a sign of commitment appropriate to the experiment. A compliment is weaker evidence than someone returning with another real job or making time to evaluate the next version.

• Outcome: did the customer complete the job, and what still required manual work?
• Quality: which factual mistakes, omissions, and exceptions appeared?
• Effort: how much checking, correction, and support did the result require?
• Commitment: did the customer take the agreed next step after trying it?
• Economics: could the service cover model usage, delivery, review, and support effort?

Compare like with like. Use a similar task under the existing method, and note differences in complexity. If the sample is small, describe it as early evidence rather than a reliable forecast. Keep disappointing results visible; deleting them makes the next discussion look more certain than it should.

What needs checking before a customer pilot?

List the data the pilot needs, who may provide it, where it goes, and how it will be removed when no longer needed. Use fabricated examples first when real records are unnecessary. Check the terms and settings of the tools you select rather than assuming every account handles business data the same way.

The NIST AI Risk Management Framework↗ (opens in a new tab) provides a voluntary foundation for considering risk during AI design, use, and evaluation. For your pilot, turn that concern into practical questions: who reviews an answer, how can someone correct it, and what happens when the service fails?

Do not promise autonomous work just because a prototype can draft it. The guide to AI employees helps distinguish software assistance from a person’s accountability. Make the review boundary clear to the customer and to anyone helping deliver the pilot.

How do you preserve the reasoning between experiments?

Give each experiment a short record: question, assumption, method, source evidence, result, human decision, and next step. Keep the raw research in its appropriate storage location and link to it. Save the lesson in language that changes future behavior, such as “test address completeness before asking for contractor feedback.”

An AI brain is useful here because the work outlasts individual conversations. With fenbs Decisions and rules, a person’s choice and its reason remain available to the next connected assistant.

How to do this with fenbs

1. Create a free account and add a project for the customer problem you are testing.
2. Add a task for the next experiment. Write its assumption, evidence to collect, review boundary, and stopping condition in the plan.
3. Record approved choices in Decisions and rules, and keep unresolved choices open. Add research links and verified context notes without copying sensitive customer records.
4. Connect a supported assistant through Integrations. Ask it to read the project context before proposing the next test.
5. After the test, record the result and lesson, then save Where we left off with the next action and any decision waiting on a person.

fenbs is free for one person, no credit card. It does not recruit interview participants, run your product, or prove market demand; if you only need a one-time interview outline, a document may be enough. Use it when several experiments and assistants need the same checked record of what you know.