A Solo Founder's Project Risk Assessment Framework (No Spreadsheet Required)

You're about to spend 4 weeks building a new feature. Or 3 months on a new project. Or pivot your entire product. You've got a gut feeling it's the right move. When you're a solo founder, that gut feeling is doing the entire job of a product manager, a strategy team, and a risk officer — rolled into one. Sometimes it's right. Sometimes it's very, very wrong.

Project risk assessment for indie hackers is usually presented as overkill. RAID logs, risk matrices, likelihood-by-impact quadrants — the tools that large organizations use to de-risk seven-figure bets look laughable when you're deciding whether to spend your Saturday building an export feature. So most solo founders skip risk assessment entirely. They ride their gut, ship what feels right, and occasionally wake up three months later having built the wrong thing.

The honest middle ground isn't no framework — it's a framework that takes 10 minutes, fits on one page, and asks the five questions that actually matter when you're betting your own time and money. Here's the solo-founder risk assessment I use before committing to any project, major feature, or pivot. It's small enough to actually run, structured enough to catch the obvious failure modes, and honest enough to tell you when your gut is about to lead you off a cliff.

---

Why solo founders skip risk assessment

Before the framework, let's talk about why indie hackers avoid risk assessment in the first place. The reasons are valid — and the framework is designed to dodge them.

Enterprise risk frameworks are absurd at solo scale

Traditional risk management expects a risk register, a scoring matrix, mitigation plans for each identified risk, and periodic reviews. At Microsoft this makes sense. For a solo founder deciding whether to add OAuth integration, it's a week of setup for a decision that should take a coffee break. When the framework is obviously heavier than the decision, founders correctly reject the framework — but also skip the underlying thinking the framework was meant to capture.

Risk assessment feels pessimistic

Indie hackers build on optimism. A structured pre-mortem can feel like self-sabotage — you're trying to hype yourself up to ship, and here you are writing down all the ways it could fail. This is a real psychological obstacle, and "just be more disciplined" isn't useful advice. The framework has to feel generative, not depressing.

The "I'll learn by shipping" argument

Ship, iterate, learn. This is often right. The problem is that shipping-to-learn works for small bets (a weekend prototype, a tiny feature) and fails badly for large ones (a 3-month project, a full pivot). Without a framework to tell you which kind of bet you're making, "just ship" becomes the default for every decision — including the ones where the cost of being wrong is brutal.

You don't notice risks until you hit them

The biggest problem isn't that solo founders are bad at assessing risks. It's that without a prompt, they don't think about specific risks at all. You know vaguely that "things could go wrong." You don't notice that you're betting 3 months on a market you haven't validated, a technical approach you've never attempted, and a motivation that's already flagging. Those specific failures become specific surprises instead of specific preparations.

---

The five-question framework

Here's the entire assessment. Five questions, 10 minutes, one page. Run it before committing to any project, feature, or pivot that will take more than ~1 week of focused work.

Question 1: Market risk — Do I know who wants this?

Can you name, specifically, who this project is for? Not "small businesses" or "developers." Actual profiles with actual problems. "Solo developers running 3+ client projects simultaneously who currently juggle them in Trello." If you can't name the segment in one concrete sentence, the project has high market risk — you're about to build for an audience you haven't defined.

Follow-up: Have at least five real humans from that segment told you they have this problem? Not that they'd "probably use it." That they have the problem, actively, today. If the answer is zero or one, market risk is high.

Red flags:

• You can't describe the user in a single concrete sentence
• You've had zero or one conversation with someone from the target segment
• The user profile is "people like me" without evidence that "people like me" is actually a sizable market
• You're building for a pain you assume exists based on your own extrapolation

Green flags:

• You can describe the user, the problem, and the current workaround in one paragraph each
• You have 3+ conversations (not just surveys) with real users describing the problem unprompted
• You know what your users are using today and why it's inadequate

Question 2: Technical risk — Can I actually build this?

Is the core technical approach something you've either done before or could reasonably scope in 30 minutes of research? If yes, technical risk is low. If the project requires skills or infrastructure you don't have and haven't validated, technical risk is high.

The subtle trap: solo founders often dramatically underestimate technical complexity for things outside their main stack. "I'll just add AI" sounds like one line until you're six weeks into vector store tuning. "I'll just add real-time collaboration" sounds tractable until you're debugging operational transforms at 2am.

Red flags:

• The core technical challenge involves something you've never done
• The scariest part of the project is unscoped or hand-waved in your plan
• You're depending on a third-party service whose reliability you haven't validated
• "I'll figure it out" appears anywhere in your plan for a critical component

Green flags:

• You've built something similar before, or similar enough that the uncertainty is in the last 20%
• You can describe the architecture in a paragraph without gaps
• The hardest technical component has a proof-of-concept timeline in your plan (not just a feature timeline)

Question 3: Time risk — What's my realistic runway?

How long will this actually take, and how long can you actually give it? Solo founders reliably underestimate timelines — partly because we estimate in ideal hours and live in real hours, and partly because optimism is what gets us out of bed. The test: estimate the project, then multiply by 2.5. Can you still commit that much time?

Runway here isn't just calendar time — it's focused time. If you have a day job and can realistically spend 8 focused hours per week on the project, a "3-month project" is actually ~100 hours. A complex SaaS build is 400+ focused hours. Math before motivation.

Red flags:

• Your estimate is based on "if nothing goes wrong"
• You haven't accounted for debugging, polish, or the last-20%-takes-80% effect
• The project's total focused-hours requirement is longer than your realistic focused-hours availability
• You're assuming you'll have more time in the future without a specific reason to believe it

Green flags:

• You've broken the project into phases and estimated each phase independently
• You've added a 2–2.5x buffer on your initial estimate
• Your focused-hours-per-week estimate is based on your last 4–8 weeks of actual logged hours, not your aspirational weeks

Question 4: Money risk — What does being wrong cost?

How much money does this project cost to build, run, and maintain? Include direct costs (hosting, services, tools, potential contractors) and opportunity cost (what else could you be doing with the time). If the project fails at the end, how much money is unrecoverable?

For most indie projects, direct financial risk is low — hosting is cheap, services scale with usage, your time is the dominant cost. But some projects have asymmetric financial risk: a paid ad campaign, a committed contract with a service provider, a hardware purchase. Identify these explicitly.

Red flags:

• You're committing to a 12-month contract before validating the product
• Running costs at zero users are more than a noticeable percentage of your personal runway
• You're planning to fund the project by not charging for something adjacent (losing revenue you currently have)
• Paid ad spend is part of your plan before you've validated organic resonance

Green flags:

• Running costs scale with revenue — if there are no users, it costs almost nothing
• You have 6+ months of personal runway independent of this project's success
• No single expense, if wasted, would meaningfully change your financial situation

Question 5: Motivation risk — Will I finish?

This is the question most frameworks ignore, and for solo founders it's often the most important one. Be honest: will you still be excited about this project in 3 months? In 6? Not "will it still be a good idea" — will you, specifically, still have the energy and interest to push it forward?

Motivation risk has specific predictors. Have you finished projects of similar scope before? Have you maintained a project past the initial build phase? Is the project adjacent to work you already do, or is it a total context switch? Is it tied to a personal problem you actually experience, or an abstract market opportunity?

Red flags:

• You've never finished a project of this scope
• The project is entirely outside the domain of your day-to-day interests
• Your motivation is primarily "I should" or "this would be impressive" rather than genuine curiosity or urgency
• You're planning to work on this in addition to existing projects that already show signs of motivation drift

Green flags:

• You solve the underlying problem for yourself and would keep using the product even if no one else did
• You've finished projects of this scope before
• The project's subject matter is one you happily spend free time thinking about
• You've already prototyped part of it and the curiosity increased, not decreased

---

Scoring and decisions

For each of the five questions, score yourself 1–5 where 1 = high risk (many red flags, few green flags) and 5 = low risk (many green flags, few red flags). Total your score out of 25.

The scoring isn't precise — it's forcing. You can't fake a 25 by wishing. You'll score yourself honestly because you're the only one seeing the score. If you end up at 12 and feel disappointed, that's the point. The assessment caught something your gut was going to let you ignore.

The lowest-score rule

A score of 1 on any single question should override an otherwise-high total. If your market risk is 5, technical risk is 5, time risk is 5, money risk is 5, but motivation risk is 1 — you'll abandon it. Don't start.

The same is true in reverse: a catastrophically low single score can tank an otherwise solid project. A great product that requires technology you can't build, or targets a market you can't reach, or costs money you can't spend — fails. Assess the floor, not just the average.

---

What the framework catches

Walked through honestly, the five questions catch the most common failure patterns for solo projects. Here's what each surfaces:

---

Ongoing risk hygiene

The pre-project assessment is the main act. But solo projects accumulate risk over time, and the five questions deserve a lightweight revisit every month or so. This isn't a full re-assessment — it's a 5-minute check.

Monthly quick-check

Once a month, for any active project, spend 5 minutes on: Has anything significantly changed in any of the five risk areas? Did a competitor ship something that changed your market? Did a dependency's pricing change your money risk? Has your motivation drifted?

If anything has materially changed, consider re-running the full assessment. Most months, nothing has — and the 5-minute check confirms you're still aligned.

Kill switch triggers

Write down, when you start the project, what would cause you to kill it. Something like: "If after 3 months I don't have 10 paying customers, I'll kill this." Or: "If the core technical approach doesn't work by week 4, I'll pivot." Pre-committing to kill conditions is what prevents the "sunk cost, can't stop now" trap. The same logic anchors the kill criteria in our guide on managing multiple projects as a solo developer — writing kill conditions at the start of a project is much easier than writing them when you're emotionally attached and three months in.

Kill switches feel pessimistic when you write them and become lifesaving when you hit them. Writing them at the start is much easier than writing them when you're emotionally attached and three months in.

---

Tools for the solo-founder risk workflow

You don't need a risk management tool. You need a place to write down your five answers and revisit them. A few options work well.

A markdown file in the project repo

The simplest tool: a RISK.md at the root of every project with the five questions, your scores, your kill switches, and your monthly check-in notes. Lives next to the code. Git-tracked. Zero cost.

A dedicated page in your project workspace

If you use a PM tool, one pinned page per project with the risk assessment works well. GritShip supports this pattern — create a workspace per project, pin a risk-assessment doc at the top, and revisit during your monthly review. The advantage over a markdown file is that it's co-located with your actual work, not hidden in the codebase.

A single spreadsheet across all projects

For solo founders running multiple projects, a single sheet with one row per project and columns for each of the five scores gives you a portfolio-level view. Sort by total score and the lowest-risk projects float to the top — useful for the quarterly audit.

A 1-page template

Whatever tool you use, keep the template ruthlessly to one page. The moment it grows beyond that, it stops being something you actually fill out. One page, five questions, scores, and kill switches. No more.

---

The underlying logic

The five-question framework works because it captures the four types of risk that actually matter to solo founders (market, technical, time, money) plus the one factor that's usually ignored (motivation). It's deliberately small — five questions, 10 minutes, one page — because a heavyweight framework won't get used and an unused framework is worse than no framework.

Most solo project failures aren't random. They cluster around the same predictable risks: built for a market that didn't exist, underestimated technical complexity, ran out of time or energy, got emotionally attached to a sunk cost. Running the five questions forces a 10-minute check against these known failure patterns. You'll catch 60–70% of the fixable issues this way — the other 30–40% require contact with reality to discover, and no framework can catch those.

The 10-minute cost is paid in exchange for three things: avoiding the worst projects entirely (highest ROI), entering medium-risk projects with eyes open and mitigations planned (medium ROI), and having written kill switches that let you exit a failing project cleanly instead of grinding it out in guilt (underrated ROI).

If you've never run a structured risk assessment on a solo project, try it on the current one. Write down your five scores in a text file. Even if you don't change anything, you'll know something you didn't know before — the specific risks you're carrying and which ones are the weakest link. That awareness, alone, makes you a better solo founder than 90% of indie hackers who ship on vibes.

Ten minutes. Five questions. One page. Before you commit.

---

Frequently asked questions

What's the best project risk assessment tool for indie hackers?

The best tool is one you'll actually use — which for most solo founders means a simple one-page template, not a dedicated risk management app. Options that work well: a RISK.md file at the project root, a pinned document in your project workspace (GritShip, Linear, Notion), or a single spreadsheet tracking all projects with one row per project. Enterprise risk tools (RAID logs, risk registers) are typically too heavy for indie scale and end up unused. What matters most is running the five core questions (market, technical, time, money, motivation) consistently, not the specific tool holding the answers.

How do solo founders assess project risk?

A lightweight 5-question framework works better than enterprise risk matrices at solo scale. The five questions: (1) Market risk — do I know who specifically wants this? (2) Technical risk — can I actually build this? (3) Time risk — what's my realistic runway? (4) Money risk — what does being wrong cost? (5) Motivation risk — will I still be excited in 6 months? Score each 1–5, total out of 25, and use the total plus any single-question 1s as the basis for a proceed/mitigate/don't-start decision. The entire assessment should take ~10 minutes.

What are the biggest risks for indie hackers starting new projects?

In descending order of how often they kill projects: motivation risk (founder loses interest before shipping), market risk (product built for a user that doesn't exist), time risk (project takes 2–3x longer than estimated and runway runs out), technical risk (unscoped complex components derail the build), and money risk (over-commitment to paid infrastructure or ads before validation). Motivation risk is the most under-weighted — founders assume their enthusiasm will persist indefinitely, and it frequently doesn't.

Should indie hackers do a pre-mortem before starting a project?

Yes, but a lightweight one. A full traditional pre-mortem (hour-long session, detailed failure scenarios, mitigation plans) is overkill at solo scale. A 10-minute five-question assessment catches the same high-frequency failure patterns with much less overhead. The key moves: name the user specifically, identify the scariest technical component, multiply your time estimate by 2.5x, quantify financial exposure, and assess your realistic motivation trajectory. Write down kill switch triggers at the start so you have pre-committed exit criteria if things go wrong.

How do you know when to kill a project as a solo founder?

Write kill-switch triggers when you start, not when things are going badly. Good triggers are specific and time-bound: 'If I don't have 10 paying customers after 3 months, I'll kill this' or 'If the core technical approach doesn't work by week 4, I'll pivot.' When a trigger fires, kill the project — don't renegotiate with yourself. Monthly check-ins on the five risk questions also surface stalled projects before they become emotionally un-killable. Most indie projects should be killed earlier than they are; sunk cost bias is a real and predictable enemy.

Why do most indie projects fail?

Most failures are fixable-in-hindsight mistakes: building for a market that doesn't exist (Question 1), underestimating technical complexity (Question 2), running out of time or focused hours (Question 3), and losing motivation before shipping (Question 5). Running even a 10-minute structured assessment before starting catches ~60–70% of these by forcing founders to name what they're hand-waving. The remaining 30–40% require real-world contact to surface and can only be handled through short feedback loops and pre-committed kill switches, not better up-front planning.

How often should solo founders revisit their project risk assessment?

A 5-minute monthly check-in on active projects and a full 30-minute quarterly audit across all projects. Monthly check-ins ask 'has anything significantly changed in the five risk areas?' and usually produce no action. Quarterly audits re-run the full five-question assessment against every active project and often surface at least one project that should have been killed or paused weeks earlier. Risk accumulates gradually; without scheduled revisits, you won't notice until the project has already failed.