Your First 90 Days

The first three months shape a startup more than any later stretch. You will not have a finished company by day 90, but you can have a validated problem, a product people use, early revenue and a clear view of whether to raise money. This chapter turns the rest of the guide into a plan you can follow, one month at a time.

How to Use This Plan

Treat the 90 days as three blocks, each built around a single question. The dates are a guide. If you validate the problem in two weeks, move on; if it takes six, that is fine too, as long as you do not jump ahead to building because building feels more comfortable.

Keep the weekly cadence from the previous chapter running throughout: plan on Monday, review on Friday, and talk to customers every week. The plan tells you what to work on; the cadence shows you whether it is working.

The Three Blocks

Days 1–30: Problem and Validation

This month's question: does a specific group of people have a painful problem they want solved now?

• Choose one customer. Describe them narrowly enough that you could find twenty of them by name. "Small businesses" is too broad; "independent physiotherapy clinics with two to ten staff" is workable. Paul Graham's advice in How to Get Startup Ideas (2012) is to build something a small number of people want a lot, a hole that is "narrow and deep, like a well," rather than something many people want a little. His example is Facebook, whose first site was only for Harvard students: a few thousand people who wanted it badly.
• Hold at least twenty conversations. Ask about their current workflow, what it costs them and what they have already tried. Ask what they did in the past, not what they might do in future.
• Look for evidence of pain. People who already pay for a workaround, spend hours on a manual process or have tried several tools are strong signals. Polite interest is not.
• Write a one-page problem statement: who the customer is, what the problem is, how they solve it today and why that falls short.
• Set up the basics. Form the company if needed, open a business bank account, turn on multi-factor authentication everywhere and agree founder equity in writing.

By day 30 you should be able to name the customer, describe the problem in their words, and point to several people who said they want a solution soon.

Days 31–60: First Version and First Users

This month's question: does your solution actually help those people?

• Define the smallest useful version: one core job, done well, for the customer you chose. Cut everything else.
• Build quickly. With current AI tools and platforms, a credible first version can take days or a few weeks. Move fast, but review anything that touches authentication, payments or personal data.
• Put it in front of real users, starting with the people from your first-month conversations. Onboard them personally, watch them use it and fix what confuses them. As Graham wrote in Do Things that Don't Scale (2013), "the most common unscalable thing founders have to do at the start is to recruit users manually." Y Combinator calls one version of this the "Collison installation," after Stripe's founders: when someone agreed to try Stripe, the Collisons asked for their laptop and set them up on the spot instead of sending a link.
• Choose your north-star metric. Decide what usage signals value for this customer, and measure it from the first user. Once you charge, revenue is usually the best thing to track; before that, active users.
• Ship weekly, based on what you see users do rather than a roadmap written before anyone touched the product.

By day 60 you should have a handful of users returning on their own, and a clear list of what keeps the rest from doing so.

Days 61–90: Revenue, Distribution and the Raise Decision

This month's question: will people pay, and how will more of them find you?

• Ask for money. Charge your active users, even a modest amount. Willingness to pay is the clearest validation you can get, and pricing conversations show you what customers value most.
• Test two or three distribution channels, such as direct outreach, content, communities, partnerships or a marketplace listing. Measure what each produces and drop what does not work.
• Write down your sales process: how a stranger becomes a user and a user becomes a customer. You cannot improve a process you cannot describe.
• Decide whether to raise. Raise if you have early evidence of demand and a specific use for the money that would speed up what is already working. Stay lean if revenue can fund the next stage, or if you cannot yet say what extra money would buy.
• Review honestly. Compare where you are with what you expected on day one, and decide whether to persist, adjust or pivot.

By day 90 you should have paying customers, at least one promising channel and a clear decision on funding.

A Compact Checklist

Days 1–30

• Narrow customer definition written down
• Twenty or more customer conversations held
• One-page problem statement written
• Company, bank account, MFA and founder agreement in place

Days 31–60

• Smallest useful version defined and built
• First users onboarded personally
• North-star metric chosen and tracked
• Improvements shipped every week

Days 61–90

• First paying customers
• Two or three channels tested and measured
• Sales process written down
• Decision made to raise or stay lean
• Persist, adjust or pivot review completed

Common Ways It Goes Wrong

A few patterns derail more first quarters than anything else.

• Building before validating. Because building is now fast, it is tempting to skip the first month, but a product built for an unvalidated problem is quick to make and slow to sell. In a 2026 CB Insights analysis of 431 failed venture-backed startups, poor product-market fit was cited in 43% of shutdowns.
• Serving everyone. A broad customer definition produces vague feedback and a product nobody loves.
• Avoiding the money conversation. Free users teach you a lot, but only paying customers tell you whether a business exists.
• Raising too early or for the wrong reasons. Money speeds up what is already working and rarely repairs what is not.
• Going quiet. Founders who stop talking to customers when things get busy lose the signal they most need.

Building With a Studio

Some founders do all of this alone or with a co-founder. Others work with a venture studio, which brings a ready team and a repeatable process to the early stages. AW3 Technology is one such studio, based in San Francisco, building AI, Web3 and SaaS companies with founders.

A studio tends to make sense in three situations: you know a customer and a problem deeply but have no in-house product and engineering team; you want a first version in front of users within days or weeks; or you would rather have branding, design, engineering, go-to-market and fundraising support in one place than assemble contractors. AW3 ships MVPs in one to thirty days, covers branding, design, engineering, Web3, AI and mobile in-house, helps with go-to-market and fundraising, and works through a four-phase engagement model.

A studio is probably the wrong fit if you are a technical founder who wants to build everything yourself, if you have not yet spent time with customers and hope someone else will find the problem for you, or if you cannot yet describe your idea in a sentence. A studio can speed up work on a good idea, but finding the idea is still your job.

If you think it might fit, tell us about your idea through the founder intake, or contact us directly.