Lately I’ve been having the same conversation again and again.
It’s usually with someone senior in a corporate role. They’ve spent years close to a problem, watching a process break the same way every quarter, or a customer segment get badly served. They have an idea for a SaaS product or an AI agent that would fix it. And they’re stuck on one question:
Do I have to quit my job to find out if this works?
My answer is no. Not at first. Starting a company is exciting, but you don’t have to go all in on day one. The goal of the early stage is to learn whether the idea deserves your full attention. You can do most of that learning while you still have a salary.
Here’s how I’d approach it.
The real goal: evidence before big life changes
Before you resign, sign a lease, or spend your savings, you want answers to three questions:
- Is the problem real and painful for a specific group of people?
- Will they pay for your way of solving it?
- Can you reach more of them without heroic effort every time?
Everything below is about answering those questions as cheaply and quickly as possible, with the least risk to your career and your finances. If you get strong answers, quitting becomes a calculated decision instead of a leap of faith. Some people even raise a seed round before they leave, because they walk in with paying customers instead of a slide deck.
Step 1: Start with conversations, not code
The most common mistake I see is building first. Senior professionals often know their industry so well that they skip validation. They’re sure the problem exists, so they go straight to the product.
The problem might well exist. But knowing it exists is different from knowing exactly who feels it most, what they’ve already tried, and what they would pay to make it go away.
Talk to people who have the problem. Ask about the last time it happened, what it cost them, and what they did about it. Don’t pitch. Listen for patterns. You’ll often find that the version of the problem people will pay for is narrower, and more specific, than the one you started with.
The advantage of still being employed is that you’re close to these people. Use it, respectfully and without crossing any lines with your employer.
Step 2: Define the smallest thing that proves the point
An MVP is about validation, not perfection. Its job is to test your riskiest assumption, not to be a smaller version of your dream product.
Ask yourself: What’s the one thing this product must do for someone to say, “I’d pay for this”? Build that. Leave out the settings page, the admin dashboard, the second persona, and the integrations “everyone will want.”
A useful test: if you can’t describe your MVP in two sentences, it’s probably not minimal yet.
Step 3: Get a paying customer before a finished product
The strongest signal you can get is someone paying you, even a small amount, before everything is polished. Early access fees, pilots, and pre-orders all count.
Free users tell you that people are curious. Paying users tell you that the problem is worth money. Those are very different pieces of information, and only the second one should change your life plans.
Step 4: Decide how it gets built
This is where most people with full-time jobs get stuck. There are three realistic options, and each has trade-offs.
Build it yourself, on nights and weekends
If you can build, this is the cheapest option and keeps you closest to the product. It’s also the slowest, and it competes with your job, your family, and your sleep. It works best when the MVP is genuinely small. I started several side projects while working full time, and the lesson from the ones that failed is in Six side projects that failed: the build was rarely the problem. Not asking “who pays, and why now?” early enough was.
Find a co-founder
A technical co-founder can move faster and share the risk. But a co-founder relationship is closer to a marriage than a contract. Rushing it because you need someone to write code is one of the more expensive mistakes you can make. If you go this way, work on something small together first.
Work with a partner who builds MVPs
A product studio or an experienced team can build your MVP while you keep your job and focus on customers. You pay for speed and experience, and you need to choose carefully. Look for people who have built and sold products themselves, not just shipped code, and who will push back on scope instead of building everything you ask for.
At UpSurge Ventures, the product studio we ran at the time, this was the process we used with founders in exactly this position:
- An intro call to understand the founder, the idea, and whether we were a good fit.
- A deeper discussion of the problem, the users, and the riskiest assumptions.
- A scoped plan, with what the MVP would and wouldn’t include.
- A kick-off, once the scope and terms were agreed.
- Iterative development, with the founder reviewing working software regularly instead of waiting for a big reveal.
- Feedback and revisions with real customers, so the first version was shaped by users, not just by us.
Whichever route you choose, the structure matters more than who’s building. Small scope, frequent working versions, and real customer feedback early.
Step 5: Protect your day job, and yourself
Building on the side only works if it doesn’t blow up your main job or put you in a difficult position legally.
- Read your employment contract. Check for clauses on outside work, moonlighting, and intellectual property. If in doubt, ask a lawyer. It’s a small cost compared to a dispute later.
- Don’t use company time, equipment, data, or customer relationships. Keep the two worlds clearly separate.
- Avoid competing with your employer. Even if it’s technically allowed, it rarely ends well.
- Be realistic about your energy. A few focused hours a week, consistently, beats an exhausted weekend sprint followed by a month of nothing.
Step 6: Know when it’s time to leave
You don’t need certainty to quit. But you should have some evidence. Signs that it might be time:
- People are paying, and some of them are asking for more.
- You’re turning away opportunities, or customers are waiting on you because of your limited time.
- You have enough runway, from savings, revenue, or funding, to give it a real shot for a defined period.
- You’ve thought honestly about what you’ll do if it doesn’t work, and you’re okay with that answer.
If none of these are true yet, that’s fine. It just means there’s more to learn while the salary keeps coming in.
The point of all this
None of this is about being timid. Building a company still takes courage. It’s about spending that courage at the right moment, after you’ve learned what you can learn cheaply.
The best founders I’ve worked with weren’t the ones who jumped first. They were the ones who learned fastest. And a lot of that learning can happen before the resignation letter.