How do you build a startup while employed full time?

You don't need to quit your job to start a company — but you do need to be honest about what part-time commitment can and cannot accomplish. The right move is to use employment as a runway: de-risk your idea, find your first users, and build until the signal is undeniable before making the leap. The danger isn't moving too slowly — it's dismissing your own startup before it has a chance to grow.

The real risk: underestimating your own idea

Paul Graham's observation in 'Do Things That Don't Scale' is worth sitting with: even Bill Gates returned to Harvard for a semester after co-founding Microsoft, because he hadn't yet grasped what he was building. If the founder of one of the most valuable companies in history underestimated his own startup, you probably will too. This is the central psychological danger of the side-project phase — not that you'll run out of time, but that you'll unconsciously judge your fragile early-stage company against mature businesses and conclude it isn't worth the risk.

The antidote is to treat your startup as a serious experiment rather than a hobby, even before you've left your job. That means setting weekly goals, tracking real user behavior, and making honest assessments based on evidence rather than gut feelings shaped by exhaustion. The employment safety net is genuinely useful — but it can also become a reason to avoid the discomfort of real commitment.

Use your constraints as a focusing mechanism

Having only ten hours a week is brutal, but it forces a discipline that many full-time founders lack: you cannot afford to work on anything that doesn't directly test your core hypothesis. The scarcity itself becomes a tool. Paul Graham's point in 'Taste for Makers' about difficult constraints producing elegant solutions applies here — a tight budget forces an architect to cut flourishes and solve the actual problem. Limited time forces a founder to cut meetings, feature debates, and busywork, and get directly in front of users.

This means your evenings and weekends should go almost entirely toward customer development, not building. Talk to ten potential users before you write a single line of code or design a single screen. The feedback you collect in those early conversations is the highest-quality information you will ever get about your idea, and it costs nothing but time. Use your day job income to fund those experiments — modest spending on prototypes, landing pages, or ad tests — so you're not burning savings while you validate.

Do the unscalable work first — it fits your schedule

Ironically, the tactics that work best for early-stage startups are also the ones that fit a part-time schedule. Graham's 'Do Things That Don't Scale' describes how Airbnb's founders personally visited hosts, photographed listings, and engaged users one by one. That kind of manual, high-touch work doesn't require a 40-hour week — it requires showing up consistently and doing the next small thing.

If you're building a B2B product, you can spend lunch breaks doing discovery calls. If you're building a consumer product, you can recruit five beta users from your personal network this week and observe them directly. You don't need to scale yet — you need to get close enough to users that you understand their problem at a level most competitors never will. This is the work that defines whether your startup is worth quitting for, and it's genuinely compatible with a day job.

Write to learn what you actually know — and what you don't

One of the most underused tools for the employed founder is writing. Paul Graham argues that putting ideas into words — whether in essays, memos, or even structured notes — forces you to confront gaps in your own thinking that feel invisible in conversation. You may believe you understand your customer's problem, your competitive advantage, or your go-to-market approach, but writing it out in precise language will reveal exactly where your reasoning is fuzzy.

Spend thirty minutes each week writing a brief internal memo: what you learned, what you built, what changed about your model of the market. This practice does three things. First, it compounds your understanding faster than passive thinking. Second, it creates a record that will be invaluable when you talk to investors or co-founders later. Third, it forces you to decide whether what you're building is genuinely interesting or whether you're just keeping yourself busy. That clarity — which is hard to fake in writing — is worth more than any amount of weekend coding.

Know the specific trigger that tells you to quit

The most common mistake employed founders make is keeping the decision to quit open-ended: 'I'll quit when it feels right.' That framing guarantees delay, because it never feels right — there's always one more validation you want, one more month of savings you want to accumulate, one more risk you want to reduce. The better approach is to define in advance a concrete, falsifiable trigger.

Examples of real triggers: ten paying customers who found you without referrals from friends; a waiting list of 200 users built through a landing page you ran on $200 of ads; a single enterprise pilot contract worth more than one month of your salary. These are specific enough that you can't rationalize your way around them. Once you've hit the trigger, the delay becomes the risk — because the startups that win are usually the ones where the founder goes all-in before everything is certain, not after. The goal of the employed phase is not safety forever; it's to collect just enough signal that the leap is rational rather than reckless.

“Almost all startups are fragile initially. The big danger is that you'll dismiss your startup yourself.”

— Paul Graham, source

The one thing to do

Define one specific, measurable trigger — paying users, a waitlist, a pilot contract — that commits you to quitting the moment you hit it, so the employed phase has a real deadline.

Frequently asked questions

Is it ethical to work on a startup while employed?

Generally yes, as long as your employment contract doesn't include a broad IP assignment clause covering outside work, and your startup doesn't compete directly with your employer. Read your contract carefully and consult a lawyer if there's ambiguity — most standard agreements allow unrelated side projects.

How many hours per week do you realistically need to make progress?

Ten to fifteen focused hours per week is enough to do meaningful customer development and early validation — but not enough to build and ship a complex product quickly. Use that time exclusively for the highest-leverage activities: talking to users and testing your riskiest assumptions.

When is it too early to quit your job?

It's too early if you have no paying users, no demonstrated retention, and no specific evidence that people want what you're building badly enough to pay for or repeatedly use it. Passion and a good idea are not enough — wait for external validation, not internal conviction.

Should I find a co-founder before or after leaving my job?

Finding a strong co-founder before you leave can significantly de-risk the decision, since you'll have someone to share both the workload and the financial pressure. Be careful not to recruit out of convenience — a co-founder relationship is foundational, and the wrong one causes more damage than going solo.

Sources

More playbook answers · Growth Prophet home