Enterprise risk frameworks don't fit solo work. Here's a 5-question risk assessment for indie hackers — run it in 10 minutes before you commit to a project, a feature, or a pivot, and you'll ship with confidence instead of hope.
Tired of bloated PM tools?
GritShip is project management for developers who'd rather ship than configure.
Try GritShip free →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.
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.
80%
of indie projects
fail or are abandoned within 12 months
~40%
of failures
are fixable with basic pre-project triage
10 min
Target assessment time
for any solo project decision
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.
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.
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.
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.
"I spent 11 weeks building a product. In the first week, if anyone had asked me 'what are the top three ways this could fail?' I could have listed them. I just never asked. And two of the three are what actually killed it."
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.
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:
Green flags:
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:
Green flags:
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:
Green flags:
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:
Green flags:
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:
Green flags:
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 decision thresholds
20–25 (Low overall risk): Proceed. The project passes basic triage. Ship it.
15–19 (Medium risk): Proceed with explicit mitigation for the weakest questions. Don't skip the mitigation — address the lowest-scoring areas before committing.
10–14 (High risk): Don't commit yet. Spend 1–2 weeks improving the weakest scores before deciding. Usually this means more user conversations (market), a technical prototype (technical), or reducing scope (time).
Below 10 (Severe risk): Don't start. The specific combination of issues you have is the profile of projects that fail 80%+ of the time. Work on something else or radically re-scope this one.
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.
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.
Walked through honestly, the five questions catch the most common failure patterns for solo projects. Here's what each surfaces:
Almost always caught by Question 1. You'd be surprised how often indie hackers can't name their target user without hedging. That hedge is the signal — when you catch yourself saying "this could be useful for anyone who…" you've failed Question 1 and you haven't realized it.
Caught by Questions 2 and 3. Most overshoots come from unscoped technical components combined with optimistic time estimates. Running these two questions forces you to name the scariest part of the build and commit to a realistic calendar.
Caught by Question 4. Most indie projects don't have catastrophic financial risk, but the ones that do — early paid ads, hardware commitments, expensive service contracts — are the ones that silently drain runway before the product is validated.
Caught by Question 5. Motivation risk is the single most under-weighted factor in indie project planning. Founders assume motivation is binary and permanent. It's not. It fluctuates, and for some project types it fluctuates predictably downward.
A combination of Questions 1 and 5. Sometimes a project is real, the market is real, but your specific conditions (time, energy, current projects) mean it's the wrong bet for you right now. The framework catches this by assessing you, not just the idea.
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.
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.
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.
💡 The quarterly project audit
Once a quarter, run the five questions against every active project you have. This takes 30 minutes for 3 projects. It's the highest-ROI time investment a solo founder can make. You'll find at least one project that should have been killed 6 weeks ago and wasn't because the gradual nature of risk accumulation never triggered a decision point.
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.
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.
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.
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.
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 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.