Detailed Methodology: Executing the Feasibility Tools

Deep Dive: Revenue Model Simulation

The Revenue Simulator is your sandbox for testing how you'll make money -- and what could go wrong before a single dollar changes hands.

Revenue modeling is where founders most frequently fall into the "Excel Fantasy" trap described in Chapter 2. The antidote is driver-based modeling: building your projections from the bottom up, starting with the specific inputs you can measure and control, rather than top-down assumptions about market capture. As David Skok of Matrix Partners has emphasized, the best SaaS financial models are "bottoms-up" -- they start with individual customer acquisition channels and conversion rates, not with total addressable market percentages.

The methodology here draws on the work of Ash Maurya (Running Lean), who advocates for treating financial projections as hypotheses to be tested, not forecasts to be believed. Your revenue model is a living document. It should change every time you get new data from a pricing experiment, a customer interview, or a marketing test. If your model hasn't been updated in the last 30 days, it's already stale.

Inputs and Drivers

Good models need the right inputs. The quality of your projections is entirely determined by the quality of your assumptions. Each input below should have a source -- either a benchmark from your industry, a data point from your validation experiments, or an explicit assumption marked as "to be tested." If you cannot source an input, that's a signal you need to run an experiment before proceeding.

Building the Revenue Funnel Model

The most reliable revenue model is a funnel model that traces the journey from first touch to paying customer. Here's the methodology, step by step:

Hybrid Revenue Modeling

If you charge subscriptions plus usage (the "hybrid" model discussed in Chapter 3), you need to track both components separately. This is increasingly important as more SaaS companies add usage-based pricing layers. The challenge is that usage revenue is inherently less predictable than subscription revenue, which makes forecasting harder -- but the upside is that usage revenue scales with customer success, creating natural alignment.

What-If Analysis: Stress-Testing Your Revenue Model

A revenue model is only as useful as the scenarios you run against it. The goal isn't to predict the future -- it's to understand which variables your business is most sensitive to. Run these specific scenarios and document the results:

Use the Financial Model tool to run these scenarios automatically. The tool includes built-in sensitivity analysis that shows you which variables have the largest impact on your bottom line.

Deep Dive: Cost Structure Forecasting

AI Cost Modeling Methodology

For AI-native products, cost modeling requires a fundamentally different approach than traditional SaaS. Your cost of goods sold (COGS) is not just hosting and bandwidth -- it includes inference costs that can vary 100x depending on query complexity. Here's the step-by-step methodology for accurately forecasting AI costs:

Each component needs separate tracking and optimization:

Practitioner tip: Log every AI interaction's token count and cost during your prototype phase. After 1,000 interactions, you'll have real data to build your cost model on -- far more reliable than estimates. Use the MVP Cost Forecaster tool to input these real numbers and project costs at scale.

The Step-Function Cost Methodology

As discussed in Chapter 4, costs don't scale linearly -- they jump at thresholds. The methodology for identifying and planning for these jumps:

1. Map your capacity thresholds. For each operational area (engineering, support, infrastructure, compliance), identify the customer count at which you'll need to step up. Example: "At 200 active customers, we need a second support person."
2. Calculate the cost of each step. Each threshold has a fixed cost increase. A new hire adds $120K-200K in fully loaded annual cost. A database upgrade might add $500-2,000/month. SOC2 certification is $20K-50K one-time plus $10K-25K annual renewal.
3. Plot the step function. Create a chart showing total monthly costs at 0, 100, 250, 500, 1,000, and 5,000 customers. This reveals the "danger zones" where a small increase in customers triggers a large increase in costs.
4. Build triggers into your model. Your financial projection should automatically increase costs when customer count crosses each threshold. This prevents the "everything is fine until it suddenly isn't" problem.

Deep Dive: Unit Economics Methodology

Customer Acquisition Cost: The Paid CAC Method

The most reliable CAC methodology uses Paid CAC -- the cost of customers acquired through paid channels only. Here's why and how:

Blended CAC (total marketing spend / total new customers) is misleading because it includes organic and referral customers who cost nearly nothing to acquire. When you want to model growth, you need to know the cost of the marginal customer -- the next one you'll acquire by spending more money. That's your paid CAC.

Customer Lifetime Value: The Cohort Method

The most accurate LTV calculation uses cohort analysis -- tracking actual revenue from groups of customers who signed up in the same month. Here's the methodology:

1. Define your cohorts. Group customers by signup month (e.g., "January 2026 cohort," "February 2026 cohort").
2. Track monthly revenue per cohort. For each cohort, measure total revenue in month 1, month 2, month 3, etc. This gives you a retention curve showing how revenue decays over time.
3. Calculate cumulative revenue per customer. Divide total cohort revenue at each month by the number of customers in the original cohort. This shows you how much revenue a typical customer generates over time.
4. Apply a time cap. Cap your LTV calculation at 36 months for early-stage projections. Beyond 36 months, too many variables change (pricing, product, market) to make reliable predictions.
5. Subtract COGS. Remember: LTV is gross profit, not revenue. Subtract your per-customer cost of goods sold from the cohort revenue to get true LTV.

Deep Dive: Technical Feasibility Assessment

The Technical Smoke Test Battery

Before committing to a full build, run these concrete technical tests. Each test is designed to surface a specific category of risk. The methodology draws on the "Spike" concept from Agile development -- short, time-boxed investigations designed to reduce uncertainty about technical feasibility.

The "Bus Factor" Audit

The "bus factor" measures how many people would need to be hit by a bus before a project is in serious trouble. For most startups, the answer is "one" -- and that's a critical risk. Here's how to systematically assess and mitigate this:

Technology Stack Decision Framework

At the feasibility stage, your technology choices should be driven by three principles, ranked in order of priority:

1. Speed to market: Choose technologies your team already knows. A mediocre technology used expertly beats a perfect technology used poorly. The time to learn a new framework is not the feasibility stage.
2. Operational cost: Prefer managed services (AWS RDS over self-managed PostgreSQL, Vercel over self-managed Kubernetes) during the early stages. The premium you pay for managed services is cheap insurance against operational complexity. Use the MVP Cost Forecaster to compare managed vs. self-managed costs.
3. Future flexibility: Avoid lock-in where possible, but don't over-engineer. You can migrate databases later if needed. You can switch cloud providers later if needed. Don't let fear of lock-in slow you down today.

What You Walk Away With

• Revenue Simulation Methodology: Driver-based modeling with sensitivity analysis and scenario testing. You know which variables to track and how to stress-test your projections.
• Cost Forecasting Framework: AI-specific cost stack with step-function modeling and optimization strategies. You can predict when costs will jump and plan for it.
• Unit Economics Engine: Cohort-based LTV and Paid CAC methodologies with worked examples. You know the difference between blended and paid CAC and why it matters.
• Technical Smoke Tests: A concrete battery of tests to validate feasibility before committing to a full build. You know which tests to run, how to interpret the results, and what constitutes a red flag.
• Risk Reduction Playbook: Bus factor audit, technology stack decision framework, and operational readiness checklist. You've identified and begun mitigating the biggest execution risks.