Starting a company is not one task. It is a chain of decisions about a customer, a problem, an offer, delivery, money, legal obligations, and proof. AI can help you structure those decisions and expose what is missing. It cannot tell you that demand exists, choose the right legal form, clear a business name, or promise that your forecast is realistic.
The intended reader is a first-time founder, freelancer, or small team preparing a real business and its first public website. The outcome is a launch brief that another person can inspect and challenge. It is not legal, tax, accounting, investment, or licensing advice. Registration and compliance depend on the activity and jurisdiction. Source review: 24 August 2026.
Do not start with the website
A generated website can make an untested idea look finished. That is dangerous because visual polish feels like progress while the commercial questions remain unanswered.
Before design begins, you should be able to state:
- who has the problem,
- what happens today without your offer,
- what outcome you will provide,
- what you will not provide,
- what evidence supports the problem,
- how a customer can test the offer,
- what delivery actually requires,
- which legal or professional questions remain open.
The U.S. Small Business Administration’s business-plan guidance treats the plan as a way to think through how the business will be structured, run, and grown. Its launch guidance separates location, structure, naming, registration, tax identifiers, permits, banking, and insurance. Those are useful categories, but the applicable answers still come from your own jurisdiction and advisers.
In the European Union, Your Europe explicitly warns that legal forms, taxes, capital requirements, registration, permits, and licences vary by country. That is the right operating boundary for AI: it may turn official requirements into questions and a checklist, but it must not silently generalize one country’s procedure to another.
Build two tracks in parallel
Keep commercial discovery and formal setup as separate tracks. They inform each other, but they do not prove each other.
Commercial track: customer evidence, offer, delivery test, pricing hypotheses, acquisition path, capacity, and reasons to stop.
Formal track: legal form, ownership, name checks, registration, tax and accounting setup, permits, contracts, insurance, data protection, and employment obligations where relevant.
Registering an entity does not validate the offer. A successful customer interview does not settle liability, tax, or licensing. Your launch brief should show the state of both tracks without turning either into a green checkmark too early.
Step 1: write a founder facts pack
Give the AI a compact facts pack instead of a motivational prompt. Keep claims and assumptions visibly different.
Company idea: [one sentence]
Target customer: [specific role or type of organization]
Observed problem: [what I directly saw or heard]
Evidence I have: [interviews, requests, workflow observation, prior invoices]
Assumptions I have not tested: [list]
Offer I could deliver manually: [scope]
Excluded work: [what is outside the offer]
My current capacity and constraints: [time, skills, cash, geography]
Jurisdiction: [country/region]
Decisions reserved for professionals: [legal, tax, regulated work]
Do not paste private customer records, confidential employer material, identity documents, bank statements, credentials, or unredacted contracts into a consumer AI tool. Use role labels and summarized evidence. The same boundary applies to client work later: do not paste client secrets into AI.
Ask the model to produce an evidence table with four columns: claim, supporting evidence, contrary evidence, and next test. If it fills an evidence cell with a plausible story, delete it. A blank cell is useful information.
Step 2: define the smallest credible offer
An offer is not a category such as “AI consulting” or “web design.” It is a bounded result for a recognizable customer under stated conditions.
Use this structure:
For [specific customer], we will [deliverable or outcome]
within [time or operating window], using [customer inputs],
excluding [boundaries]. The customer can judge completion by [acceptance test].
For example, “automation for small businesses” is not testable. “Map one existing invoice-approval workflow, identify its failure points, and deliver a reviewed implementation brief without connecting production accounts” is testable. It names the work, the boundary, and how completion can be judged. It does not promise savings that have not been measured.
AI is useful for finding ambiguity in this sentence. Ask it to highlight every word that could hide scope, such as “complete,” “integrated,” “secure,” or “optimized.” You still decide the final commitment. If the offer later becomes a proposal, use proposal drafting while you retain pricing responsibility and keep a scope-change log.
Step 3: collect demand evidence without manufacturing it
Create a dated evidence register. Each row should identify the source, what was observed, how direct it is, what alternative explanation exists, and what decision it affects.
Useful evidence includes:
- a customer describing a current workflow in concrete steps,
- an existing budget or invoice for an alternative solution,
- a request to pilot or buy under defined terms,
- repeated manual work you can observe,
- a failed attempt and the reason it failed,
- a prospect declining and explaining why.
Weak evidence includes compliments, social engagement, model-generated market summaries without traceable sources, and survey answers to hypothetical pricing questions. They can suggest where to look, but they are not purchase behavior.
Ask AI to challenge the evidence, not validate the idea:
Review this evidence register as a skeptical operator.
Do not estimate market size or invent customer motives.
For each claim, identify:
1. what the evidence actually supports,
2. what it does not support,
3. the strongest alternative explanation,
4. the cheapest ethical test that could change the decision.
Return "insufficient evidence" where appropriate.
Step 4: run a small delivery test
The first test should exercise the riskiest part of delivering value, not merely the easiest part to demonstrate. A landing page click can test interest in a message. It does not prove that you can deliver the service, that the customer will pay, or that the result will work in production.
Write the test before running it:
- hypothesis,
- participant or customer segment,
- promised scope,
- price or explicit no-price condition,
- success and failure criteria,
- data you will collect,
- privacy and consent boundary,
- maximum time and money,
- stop condition,
- decision date.
Label forecasts as scenarios. If you do not know the conversion rate, do not ask AI to provide an “industry average” and put it into a cash plan. Use a range of explicit assumptions and show what changes the result. Pricing research should inform questions, not dictate your price.
Step 5: prepare the formal-decision packet
Now turn the business facts into questions for official sources and qualified professionals. Do not ask, “Which company type should I choose?” Ask for a comparison packet that a human can verify.
Using only the official sources I provide, build a comparison table for
the legal forms available in [jurisdiction]. Include liability, ownership,
governance, filing, accounting, tax-registration, permit, and employer
questions. Quote no rule from memory. Mark every unanswered item for a
lawyer, accountant, registry, tax authority, or licensing body.
For an Estonian example, the e-Business Register is the official national portal for legal-person records and electronic establishment. Use its current portal and help material for the actual process. Elsewhere, use the corresponding national registry and tax authority. Do not copy an Estonian checklist into another country.
Names require separate checks. Search the relevant company register, domain availability, and trademark databases. A model’s suggestion is not clearance. For EU marks and participating offices, EUIPO provides official search tools including TMview. Similar words, classes, territories, and unregistered rights can still require professional analysis.
Your packet should end with named owners and dates, for example:
- accountant: tax registration and bookkeeping setup,
- lawyer or authorized service: ownership, terms, regulated activity, and contracts,
- registry: name and establishment procedure,
- insurer or broker: activity-specific coverage,
- founder: commercial assumptions and delivery capacity.
Step 6: calculate whether you can deliver
Build a capacity model from your own numbers:
- hours available per week,
- delivery hours per customer,
- review and correction time,
- sales and administration time,
- direct costs,
- payment timing,
- refunds, rework, and support assumptions,
- cash already committed,
- a runway scenario that does not count unsigned revenue.
Keep the model auditable. Each input should have a source, date, owner, and confidence label. AI may calculate scenarios after you supply the formulas and inputs. It should not decide which costs can be ignored or convert a hopeful pipeline into revenue.
If the plan needs you to work more hours than exist, cut scope or change the model. Do not let generated prose hide the capacity failure. The weekly operating discipline in solo week ops with AI limits applies before the first customer, not only after launch.
Step 7: produce the website handoff brief
Only now prepare the input for design. The first website is not the company. It is a public interface for a specific offer and a trust test.
Your handoff brief should contain:
- Primary visitor: one role, situation, and level of awareness.
- Primary decision: the next action the page should make understandable.
- Verified claims: only claims supported by the evidence register.
- Prohibited claims: savings, outcomes, customers, certifications, or availability you cannot prove.
- Offer and exclusions: the exact service boundary.
- Proof available now: process, artifact, founder experience, or customer evidence you have permission to publish.
- Required pages: usually home, service, about, contact, privacy, and applicable legal information.
- Content constraints: languages, tone, accessibility, images, and owner for updates.
- Technical constraints: static or dynamic needs, forms, analytics, hosting, domain, and budget.
- Launch test: what a real visitor must understand or complete.
Do not generate testimonials, client logos, team biographies, certifications, statistics, or case-study outcomes to make the page feel complete. Empty proof is a business task, not a copywriting opportunity. Portfolio evidence must remain evidence, not hype.
A decision-ready launch brief
Your final document should fit on a few pages and link to its evidence, not bury uncertainty in a long pitch deck. A reviewer should be able to answer:
- What is known?
- What is assumed?
- What is being tested next?
- What would stop the project?
- Who owns each formal decision?
- Which public claims are already supportable?
- What exactly should the first website communicate?
The strongest next step is rarely “generate the whole company.” It is one bounded test, one formal-decision packet, and one website brief that refuses to pretend the uncertain parts are finished.
