Most SaaS startup checklists are written for technical founders. They cover things like choosing a tech stack, setting up your development environment, and deciding between a monolith and microservices. Useful information. Wrong sequence for an operator who knows the problem they want to solve and needs to figure out what to do before writing a line of code.
This is a pre-build checklist specifically for operators. It covers the nine things to confirm before you start building — the decisions that determine whether you spend the next year building the right thing or the interesting thing. Most operators skip at least three of these because their domain expertise creates a false sense of certainty about things that still need to be confirmed.
What you need to confirm before writing any code
1. You know who the buyer is — specifically. Not "the industry" or "operations managers." A named title, a named budget type, and a named decision process. In many verticals, the person who suffers from the problem is not the same person who controls the budget to solve it. If you don't know who signs the purchase order, you don't know your buyer yet.
2. You have willingness-to-pay confirmation. Not "I would definitely use this." Not "this would solve a real problem." A specific person with budget authority who has expressed a commitment in some form — a letter of intent, a deposit on a pilot, a verbal commitment tied to a specific timeline. Without this, you're building on assumption. Domain expertise tells you the problem is real. It doesn't tell you whether your specific solution is worth $X per month to a buyer who has competing priorities.
3. You can name 10 potential customers and explain why each one would buy. This is the distribution proof. An operator founder typically has a contact list that functions as early distribution. But "I have connections in the industry" is not the same as "I have 10 specific people I can call who have the problem, have the budget, and trust me enough to be an early customer." Map it out. If you can only name five with confidence, the distribution math doesn't support the business you're trying to build.
4. You know the specific workflow, not the general problem. "The billing process in my industry is broken" is a problem statement. "The service change notification from dispatch doesn't reach the billing system in time to catch same-day additions" is a workflow problem. The second one has a product. The first one has a category. You need to be at the level of specificity where you can describe the workflow failure in three sentences, who sees it, when they see it, and what they do about it today.
5. You know what you're not building. The scope creep risk for vertical SaaS founders is building the full suite before the core product is proven. Every operator founder can see 15 features their product needs. The ones who ship fast and get to revenue are the ones who can articulate which three features deliver 80% of the value and build only those. What specifically are you not building in version one?
6. You have a technical path. If you're a non-technical founder, your technical plan needs to be specific: a named technical co-founder you've spoken to, a fractional CTO arrangement you've evaluated, or a venture studio like Alder that provides engineering. "I'll find someone" is not a plan. The technical path determines your build timeline, which determines how long your runway needs to last, which determines how much you need to raise before you have customers.
7. You know your compliance requirements before you start building. Many verticals have regulatory requirements that affect what the software can and can't do. Healthcare, fintech, legal, and construction all have compliance frameworks that determine data handling, user permissions, and audit trail requirements. Finding out about a compliance requirement after the product is built means rebuilding. Knowing it before you start means building it correctly the first time.
8. You have a committed first customer — not a fan. A committed first customer has agreed to a specific arrangement: a paid pilot, a letter of intent, or a verbal commitment to go live on a specific date. A fan is someone who says "this is exactly what we need" in a customer discovery call and then doesn't respond to your follow-up. The difference matters because the first customer's production environment is where you learn what you actually built wrong. You can't afford to spend six months waiting for a "definitely interested" buyer to become a paying one.
9. You've decided when to go full-time. Operators who try to keep one foot in their industry role while building a startup on nights and weekends almost never build fast enough to get to paying customers before they run out of motivation. The decision about when to go full-time is a personal and financial one. But it's a decision, not something to avoid making. If you don't have a date in mind, you don't have a plan — you have a side project.
When the checklist is done, what comes next
The MVP development process for an operator founder should start with a design sprint, not a codebase. Before writing code, spend two weeks mapping out the exact workflow you're solving, the screens your buyer will actually use, and the integrations that need to exist for the product to work in a real environment. The design sprint is where you find the assumptions you made in the pre-build phase that aren't actually true.
Product-market fit for a vertical SaaS company comes faster than most founders expect — because the operator founder already knows the market. What takes longer is the product fit: getting the specific workflow right, handling the edge cases that only appear in production, and building the integrations that the buyer assumed were included. Plan for the product iteration phase, not just the initial build.
The nine items on this checklist are not academic. They're the specific things we look for when an operator comes to Alder with an idea. An operator who can answer all nine with confidence is an operator who is ready to build. One who can answer six of nine confidently but is stuck on three knows exactly where to spend the next 30 days before starting the build.
If you can check off eight of nine and you're stuck on one, tell us which one. That's usually where the interesting conversation starts.