How to Start a Tech Startup: The 90-Day Evidence-Based Launch Plan

The one-page startup thesis you must write first

The How to start a tech startup journey begins with choosing a problem for which a reachable buyer already spends money or effort. Use the six-part Black Tech Startup founder sequence for deeper instruction; this guide is the execution calendar that makes those decisions happen on time. It is not a substitute for the full sequence.

Fill in this eight-line thesis before meeting a developer:

1. Customer: “We sell to [specific role] at [specific type of organization].”
2. Pain: “When [trigger] happens, [task] costs [time, money or risk].”
3. Current alternative: “Today they use [spreadsheet, employee, competitor or workaround].”
4. Buyer: “The person with budget authority is [role], not necessarily the user.”
5. First outcome: “Our product will reduce or eliminate [measurable problem].”
6. Access: “We can talk with [number] real buyers in the next two weeks.”
7. Payment test: “We will ask for [paid pilot, purchase order or deposit under appropriate terms].”
8. Kill rule: “We will narrow or stop if [predefined evidence threshold] is missed.”

If you cannot identify the buyer, your next job is discovery—not code. The SBA's market research guidance explains why customer demand, competition, pricing and access belong in early business planning.

Days 1–14: customer discovery with behavior evidence

Recruit interviewees who actually own or perform the workflow. Ask about the last incident, how they resolved it, which software or staff they paid for, what broke and who approved spending. Avoid “Would you use an app that…?” because approval of a hypothetical idea is not a purchase.

Interview notes template: interview date; role; organization type; last occurrence; current cost or delay; budget owner; tool used; switching blocker; permission to recontact; exact supporting quote. Store only information you are authorized to collect. A useful early target could be 12–20 conversations across more than one organization, but adjust to market size and access. This is a learning target, not a guarantee of statistical validity.

At the end of day 14, summarize patterns without hiding contradictory evidence. If interviewees say the problem matters but none can identify an owner, budget or deadline, change the offer or investigate a different buyer segment. If several buyers will pay for a manual result, you may not need custom software yet.

Days 15–28: offer, pricing and the first economic model

Write an offer that names one result and one time horizon. Map the required steps from purchase to first result. Decide what you can manually deliver versus what genuinely requires software. Produce one price hypothesis, one pilot cost estimate and one explicit scope boundary.

Use a simple calculation:

Hypothetical example: a $500 pilot with $180 delivery labor, $40 cloud/AI usage and $30 support allowance produces $250 contribution before selling and overhead. If it takes the founder 25 unpaid hours, that contribution number is misleading until labor is properly valued. Build the full financial view using BTS startup unit economics.

Days 29–42: formation, ownership and minimum controls

Choose the entity, tax and ownership path in the jurisdiction where the company actually operates. Work with legal and tax professionals when co-founders, outside investors, intellectual property, cross-border business, regulated products or employment issues complicate the decision. Draft founder role and decision rules, vesting where applicable, an IP assignment process, a bank-account and bookkeeping plan, and a written spend-approval limit.

The IRS issues EINs at no charge and advises forming an LLC or corporation with the state before requesting the EIN. For names and brands, the USPTO recommends a meaningful trademark clearance search, not merely buying a matching domain. These are federal starting points; state rules, industry permits and contracts need their own checks.

Do not hand your entire business to a contractor's private account. Register the domain, cloud project, code repository, billing systems and core data infrastructure under company-controlled accounts with role-based access and recovery procedures. Get a written ownership and source-delivery agreement for code, designs, data and other commissioned work.

Days 43–63: build a narrow, testable product

Write the first workflow as a series of observable events: user enters a request, system validates it, a result is generated, a human can correct an exception, a record is saved, and the buyer receives a usable outcome. Include access controls, backups, data deletion/export and customer support from the start. The NIST Secure Software Development Framework offers practices that can scale down to a small team.

Test at least these paths before a paid pilot: correct input, incomplete input, duplicate request, unauthorized access, failed network, canceled payment when applicable, third-party API outage, wrong AI output, data export, user deletion request where applicable, and backup restoration. An AI product should have a documented way to refuse uncertain or unsafe actions rather than confidently invent results.

The Builder School covers the build process in approachable steps; the production web-app launch guide covers environments, logging and operational readiness.

Days 64–77: paid or otherwise credible pilot evidence

Before the pilot, agree on a measurable outcome and a completion definition. Example: “Within a two-week pilot, staff will process 30 legitimate cases, correctly identify exceptions and save 20 minutes per completed case without missing mandatory review.” This is a hypothetical acceptance criterion; the buyer should set real targets based on their operations.

Track the number of invited users, activated users, completed jobs, error corrections, support requests, time to value and actual payments or contractual commitments. A founder should not substitute signups for adoption or verbal excitement for revenue. At the end, ask whether the buyer would renew, expand, refer, or replace a current system—and what would block each action.

Days 78–90: decide whether to launch, narrow, or stop

Use an evidence gate, not a motivational slogan:

Document the decision, including negative evidence. Then choose one acquisition channel, set a weekly measurement rhythm, and make the first hires only against demonstrated bottlenecks. BTS's distribution playbook explains how to turn a tested offer into repeatable customer discovery.

The founder's weekly scoreboard

Track leading indicators and actual outcomes separately: qualified buyer interviews; buyer-introductions requested; real pilot proposals; commitments; activated accounts; completed jobs; error rate; revenue collected; direct delivery cost; net cash; and cash runway. Use consistent definitions and a weekly review date. A strong scoreboard should tell you which assumption failed before it tells you how impressive the vanity metrics look.

If you are building without a technical partner, continue to the dedicated nontechnical founder build-and-handoff guide. If you need to prepare for external funding, review the Capital Readiness Engine and funding strategy resources only after defining actual evidence and cash needs.

The 90-day exit checklist

• A named buyer and painful workflow are validated with real conversations.
• The first offer has clear scope, economics and a payment test.
• Ownership, taxes, company accounts and IP rights are organized.
• Core access, data, security and recovery requirements are tested.
• The pilot generates behavior and financial evidence, not just praise.
• A written launch, narrow or stop decision has an accountable owner.

A startup does not become real because ninety days have passed. It becomes more credible when an honest customer problem, a safe product and a business model survive direct tests.