The Indie Hacker's Task Prioritization Framework (P1–P4) | GritShip Blog | GritShip
PrioritizationIndie DevProductivity
The Indie Hacker's Task Prioritization Framework (P1–P4)
When everything feels urgent, nothing gets shipped. Here's a dead-simple P1–P4 priority system that tells you exactly what to build next — and what to ignore.
By Imtiaz··24 min read
You have 47 tasks in your backlog. 12 are labeled "high priority." When everything is high priority, nothing is. You stare at your board, pick the task that feels most interesting, and three hours later you've built a dark mode toggle instead of fixing the broken Stripe webhook. Sound familiar?
This is the core problem of task prioritization for indie hackers: you're the PM and the builder. There's no product manager to hand you a ranked list. No sprint planning meeting where a team debates what matters most. It's just you, a messy backlog, and the nagging feeling that you're building the wrong thing.
The consequences are real. Ship the wrong feature and you've lost a week you can't get back. Spend Friday afternoon on a P4 polish task while a P1 billing bug silently bleeds revenue over the weekend. Miss the signal in a customer email because you were heads-down on something that felt urgent but wasn't.
The solution isn't another productivity framework with a 2x2 matrix and a Greek name. It's four letters and two questions. That's it.
Why traditional prioritization fails indie hackers
Most prioritization frameworks were designed for product teams with data, meetings, and designated decision-makers. When you try to apply them as a solo founder, they collapse under their own weight. The same mismatch applies to the broader process — our covers the full minimal workflow this priority system plugs into.
Tired of bloated PM tools?
GritShip is project management for developers who'd rather ship than configure.
MoSCoW (Must, Should, Could, Won't) was built for teams negotiating scope in a room. It works great when 8 people need to agree on a release. When you're one person, every task feels like a "Must" because there's no one to push back. The categories are too subjective without group calibration — and group calibration requires a group you don't have.
ICE/RICE needs data you don't have
ICE (Impact, Confidence, Ease) and RICE (Reach, Impact, Confidence, Effort) ask you to score each task on multiple dimensions. That's fine if you have analytics, user research, and a product team debating the numbers. Most indie hackers have a Plausible dashboard with 200 daily visitors and a gut feeling. Assigning an "Impact score of 7 out of 10" to "add social login" is fiction dressed up as data. You'll spend 12 minutes per task filling out a scoring matrix, only to end up with numbers that reflect your biases, not reality.
Gut feeling optimizes for fun, not value
Without a system, you'll default to building what's interesting. Redesigning the landing page feels productive. Refactoring the auth flow is satisfying. Adding that slick animation is fun. Meanwhile, the billing bug that affects 3% of paying customers sits untouched because fixing payment edge cases isn't anyone's idea of a good time.
"I spent two weeks building a beautiful dashboard analytics page. I had 11 users. None of them asked for analytics. Three of them had asked me to fix the invite flow — which I hadn't touched."
The pattern is always the same: without explicit prioritization, indie hackers gravitate toward building what feels productive over what is productive. And the cost isn't just wasted time — it's opportunity cost. Every hour spent on a P4 task is an hour not spent fixing the payment bug that's silently leaking revenue.
You need a system that's fast enough to use in 10 seconds per task, rigid enough that you can't game it, and simple enough that you'll still be using it three months from now.
The P1–P4 system explained
The P1–P4 priority system works because it's fast, binary, and tied to deadlines. No spreadsheets. No scoring. Just four buckets with clear rules.
Here's the complete framework:
P1 — Critical: Fix today
Users can't use the product. Revenue is blocked. Data is at risk. P1 means everything else stops until this is resolved.
The test: "Are users unable to do the thing they're paying me for right now?"
Examples: Login is broken. Payments are failing. The app crashes on load. Data is being lost.
Deadline: Today. Not tomorrow. Today.
P2 — High: Build this week
Important for growth, retention, or revenue — but the product still functions without it. P2 work is what moves your business forward when nothing is on fire.
The test: "Will delaying this by a week meaningfully hurt growth or retention?"
Examples: Onboarding flow improvements that reduce churn. A feature your top 3 customers requested. A performance fix for a slow page.
Deadline: This week.
P3 — Medium: Next two weeks
Good improvements that make the product better but don't move a needle you're actively watching. P3 is the "would be nice" category with a time horizon.
The test: "Is this a genuine improvement, but not tied to a metric I check daily?"
Examples: Redesigning a settings page. Adding CSV export. Improving error messages. Writing a blog post about a new feature.
Deadline: Next two weeks. If it slips, that's fine.
P4 — Low: Capture, don't schedule
Ideas, experiments, nice-to-haves, someday-maybes. P4 exists so you have a place to put things without pretending you'll do them soon. The entire point of P4 is to not schedule it.
The test: "Would anyone notice or care if I never built this?"
Examples: Dark mode. Custom themes. A mobile app version. That clever feature you thought of in the shower.
Deadline: None. Review monthly. Delete liberally. A well-maintained P4 list has items rotating in and out — not accumulating forever.
💡 The power is in the deadlines
The difference between P1–P4 and a vague "high/medium/low" system is the built-in time horizon. "High priority" means nothing without a deadline. "Build this week" is a decision. Every task gets both a priority and a timeframe — which means you always know not just what matters, but when it matters.
The two-question filter
Here's the fastest way to assign a priority to any task. For every item that lands in your backlog, ask two questions:
ℹ️ The Two-Question Priority Filter
Question 1: "If I don't do this in the next 48 hours, what happens?"
Question 2: "Does this move a metric I care about?"
If the answer to Question 1 is "users are blocked" or "I lose revenue" — it's P1.
If the answer to Question 1 is "nothing breaks" but Question 2 is "yes" — it's P2.
If both answers are "not much" — it's P3 or P4.
If you're not sure whether it's P3 or P4, it's P4.
This filter takes about 10 seconds per task. No spreadsheet. No scoring rubric. Two questions, one decision.
The reason it works: Question 1 catches urgency. Question 2 catches importance. Together, they separate the "feels urgent" tasks (Slack notifications, minor UI complaints, feature requests from free users) from the "actually matters" tasks (broken payments, churning customers, growth bottlenecks).
Most indie hackers who try this discover something uncomfortable: 80% of their backlog is P3 and P4. The things that feel urgent — the GitHub issues, the feature requests, the "quick fixes" — almost never pass both questions. The real P1s and P2s are obvious once you stop and ask.
The two-question filter also reveals phantom urgency. That Slack message from a user saying "this is really important" might feel like a P1 — but when you ask "what happens in 48 hours?", the answer is often "nothing." Urgency is not the same as loudness.
Real examples: Prioritizing like a founder
Theory is easy. Let's walk through six tasks that might show up in a typical indie hacker's backlog and assign priorities with reasoning. For each one, I'll run the two-question filter so you can see exactly how fast the decision process is.
"Login is broken for Safari users" → P1
Safari is 20% of web traffic. A chunk of your users literally cannot log in. This is blocking core functionality for a significant percentage of your audience. Everything else stops. Fix it today.
Two-question check: What happens in 48 hours? → Users churn and you get angry tweets. Does it move a metric? → Yes, directly affects activation and retention. Verdict: P1.
"Stripe webhook failing for 2% of charges" → P1
2% sounds small until you realize that's 2% of your revenue silently disappearing. Customers are being charged but not getting access to what they paid for. This generates support tickets, refund requests, and churn. P1, fix it today.
Two-question check: What happens in 48 hours? → More failed charges accumulate, you owe refunds, and trust erodes. Does it move a metric? → Yes, MRR is literally decreasing. Verdict: P1.
"Add team billing (monthly → annual toggle)" → P2
Your three largest customers have asked for annual billing. This directly affects revenue expansion and retention of high-value accounts. It's not blocking anyone from using the product, but it's a clear growth lever. Build it this week.
Two-question check: What happens in 48 hours? → Nothing breaks, but you miss locking in annual commitments. Does it move a metric? → Yes, affects ARR and reduces churn risk. Verdict: P2.
"Redesign the pricing page" → P3
Your pricing page works. People can see plans, compare features, and subscribe. A redesign might improve conversion — but you don't have data suggesting the current page is a bottleneck. It's a real improvement, but it's not urgent and it's not tied to a metric you're actively watching. Next two weeks.
Two-question check: What happens in 48 hours? → Nothing. Does it move a metric? → Maybe, but you're guessing. Verdict: P3.
"Write a blog post about the new feature" → P3
Content marketing is valuable, but it's a slow-burn activity. One blog post won't move your metrics this week. It's a genuine improvement to your marketing surface area, but it can wait behind P1 and P2 work without any consequence. Next two weeks.
Two-question check: What happens in 48 hours? → Nothing. Does it move a metric? → Eventually, but not directly or quickly. Verdict: P3.
"Add dark mode" → P4
Dark mode is the indie hacker's siren song. Users request it constantly. It feels like an easy win. But dark mode doesn't reduce churn, increase activation, or fix a broken workflow. It's a preference, not a need. Capture it, don't schedule it. If you have literally zero P1, P2, or P3 items — sure, knock it out. But that almost never happens.
Two-question check: What happens in 48 hours? → Absolutely nothing. Does it move a metric? → No. Verdict: P4.
💡 Notice the pattern
P1 tasks always involve broken functionality or lost revenue. P2 tasks always connect to a specific growth or retention metric. P3 tasks are real improvements without urgency. P4 tasks are requests that feel important but don't move the business. If you're unsure, ask: "What metric does this move?" If you can't name one, it's P3 or P4.
The daily priority check
This takes 30 seconds. Do it at the start of every work session, before you open your code editor. Before you check Slack. Before you look at email. This is the first thing.
Step 1: Look at your board. Do you have a P1? Do that. Stop reading. Go fix it. Nothing else matters until P1 items are resolved.
Step 2: No P1? Look at your P2 list. Pick the top one. That's your focus for today. Don't agonize over which P2 — if you have three P2 items, any of them is the right choice. Picking fast matters more than picking perfectly.
Step 3: No P2? Pick the top P3. This is a good day — nothing is urgent, nothing is critical. Build something that makes the product better. Enjoy the breathing room — you've earned it by handling P1s and P2s promptly.
Step 4: Never touch P4 unless P1, P2, and P3 are all clear. If that happens, congratulations — you've either achieved product-market fit or you're not being honest with yourself about your backlog.
The entire point of this ritual is to eliminate the daily "what should I work on?" decision. The system already decided. Your job is to execute, not re-evaluate.
30 sec
Daily priority check
scan board, pick top task
0
Decisions to make
the system already decided
10 sec
Per-task triage
using the two-question filter
A common failure mode: you do the daily check, see a P2, then think "but I really want to work on that P3 feature." Stop. That impulse is exactly why the system exists. You already decided P2 comes first. Trust the system for a week, then evaluate the results. You'll ship more of what matters.
Another failure mode: checking your board, seeing no P1, and then skipping the P2 to do a "quick P3" that seems easy. Quick tasks expand. That "30-minute P3" becomes a 3-hour rabbit hole, and your P2 doesn't move. Stick to the order.
When to reprioritize
Your priorities aren't carved in stone. They're written in dry-erase marker. The world changes — a customer churns, a competitor ships a feature, you discover a bug you didn't know about. Here's when you should reassess:
After every customer conversation
If a paying customer tells you something is broken, that might be a new P1. If three customers ask for the same feature in the same week, that feature just jumped from P4 to P2. Customer conversations are the highest-signal input for prioritization — treat them accordingly. One paying customer reporting a problem outweighs ten free-tier users requesting a feature. For the full triage system around incoming asks, see our guide on how to prioritize feature requests as an indie hacker.
After every support ticket
Support tickets are prioritization data, not distractions. A ticket about "can't log in" is a P1 signal. A ticket about "wish I could export to PDF" is a P4 signal. Track which categories of tickets repeat — patterns in support requests are patterns in priority. If you get the same P3-level request five times in a month, it might be a P2 in disguise.
After every significant metric change
Your MRR dropped 5% this month. Your trial-to-paid conversion fell from 8% to 5%. Your NPS score tanked. These signals should trigger an immediate reprioritization. Look at your board: is there anything that addresses the root cause? If not, create a P2 task that does.
At the end of every week
During your weekly review, scan your P2 and P3 lists. Has anything changed? Did a P3 become more urgent because of something you learned? Did a P2 become irrelevant because you pivoted? Reprioritize based on what you know now, not what you assumed last week.
This weekly sweep is also when you promote or demote. A P3 that three users mentioned this week? Promote to P2. A P2 that you've been putting off for three weeks because it doesn't feel important? Be honest — demote it to P3. The act of reprioritizing is itself a signal. If you keep delaying a P2, your gut is telling you it's not actually a P2.
What shouldn't change
The task priorities change. The system doesn't. Don't add a P0. Don't create a P2.5. Don't invent a "P1 but not really" category. Four levels is the maximum your brain can hold without the system collapsing into the same "everything is high priority" mess you started with.
Every time you feel the urge to add granularity — "this is more important than a P2 but not quite a P1" — resist it. That impulse is your brain trying to avoid making a decision. Pick P1 or P2 and move on. The cost of occasionally getting a priority slightly wrong is far less than the cost of maintaining a 7-tier system you abandon in two weeks.
Tools that support P1–P4
The P1–P4 system works with any tool that lets you tag or categorize tasks. But some tools make it easier than others.
GritShip
Built with P1–P4 as a first-class feature. Each priority level has a distinct color (red, orange, yellow, gray), visible on every card in both board and list views. You can filter your board by priority level — which means your daily check is literally: filter to P1, see if anything's there, then filter to P2. Takes about 5 seconds. The keyboard shortcut 1 through 4 assigns priority instantly without opening a menu. Built for indie hackers who want speed without configuration.
Linear
Linear has built-in priority levels (Urgent, High, Medium, Low) that map cleanly to P1–P4. The priority filter and sort are fast and keyboard-accessible. Linear's triage feature also helps manage incoming tasks before they hit your main board. If you're already using Linear, you don't need to change anything — just align your mental model to the P1–P4 definitions above.
GitHub Issues
Use labels: P1-critical, P2-high, P3-medium, P4-low. Apply colors (red, orange, yellow, gray) and filter your issues view by label. It's not as fast as a dedicated tool, but it keeps your prioritization in the same place as your code. The downside: GitHub Issues doesn't have a quick keyboard shortcut for priority, so triage is slower than purpose-built tools.
Trello / Any kanban tool
Create a custom field or use card labels for priority. Trello's label colors work well for P1–P4 visual scanning. The tradeoff: filtering and sorting by priority isn't as fast as purpose-built tools, and Trello doesn't enforce priority-based workflows — you'll need discipline to check P1 before P2 manually.
ℹ️ The tool doesn't matter — the system does
You can run P1–P4 in a markdown file with emoji prefixes (🔴 P1, 🟠 P2, 🟡 P3, ⚪ P4). The tool is just a container. What matters is that you consistently apply the two-question filter and respect the priority order when choosing what to work on. The best tool is the one where changing a priority takes less than 2 seconds — any friction and you'll stop doing it.
Making prioritization stick
The hardest part of any prioritization system isn't learning it — it's maintaining it when things get chaotic. A frustrated customer emails you. A competitor launches a feature you've been thinking about. Your metrics dip for a week. In moments of pressure, the temptation is to abandon the system and go with your gut. That's exactly when the system matters most.
Here are three principles that keep the P1–P4 system from rotting.
Be ruthless about P4
Your P4 list will grow forever if you let it. Once a month, open your P4 list and delete anything that's been there for 60+ days. If it was important, it would have been promoted. If you feel resistance deleting something, ask: "Would I build this if I had nothing else to do?" If the answer is still no, it was never a real task — it was a fantasy masquerading as a to-do item.
Resist priority inflation
The gravitational pull is always toward higher priority. Every feature request from a vocal customer feels like P1. Every interesting idea feels like P2. Fight this actively. If more than 20% of your tasks are P1 or P2, you've inflated your priorities. In a healthy backlog, the distribution skews heavily toward P3 and P4 — because most things genuinely aren't urgent or critical.
A good rule of thumb for a healthy priority distribution:
P1: 0–2 items at any given time (ideally zero)
P2: 3–5 items
P3: 5–10 items
P4: Unlimited (this is where most ideas live)
If your board shows 8 P1 items, you don't have 8 critical problems — you have a calibration problem. Go back to the two-question filter and retest each one honestly.
Let P4 items die
The purpose of P4 isn't to queue work for later. It's to get ideas out of your head without committing to build them. Most P4 items should eventually be deleted, not completed. That's the system working as intended. A P4 item that gets promoted to P3 has earned its place. A P4 item that sits untouched for 3 months has given you its answer: it doesn't matter.
Think of P4 as a pressure valve. When a user emails you about a feature idea, you can honestly respond "great idea, I've added it to the backlog" — because you have. You've just put it in the category that means "I acknowledge this exists but I'm not committing to building it." That's not dishonesty. That's prioritization.
Start today, not tomorrow
You don't need to overhaul your workflow to start using P1–P4. You don't need a new tool, a blank board, or a free Saturday. Here's a 5-minute exercise you can do right now — seriously, right now, before you close this tab:
Open your backlog — whatever tool you use.
Pick 10 tasks at random.
For each one, ask the two questions: "What happens in 48 hours if I don't do this?" and "Does this move a metric I care about?"
Assign P1, P2, P3, or P4 based on the answers.
Sort them. P1 at the top, P4 at the bottom.
Tomorrow morning, look at your board. Do the highest-priority item first.
You'll probably find something surprising: you already knew what the P1s and P2s were. You just hadn't given yourself permission to ignore the rest. The P1–P4 system doesn't tell you anything you don't already know intuitively — it gives you a framework to act on what you know.
That's the entire system. No migration. No new tool. No configuration. Just two questions and four labels.
If you want a tool that makes this even faster — where P1–P4 is built into every task card with one-click priority assignment and instant filtering — GritShip was built for exactly this workflow. But the system works regardless of the tool. What matters is that you start.
The tasks on your backlog aren't going to prioritize themselves. And "high priority" isn't a priority — it's a wish. Give every task a number, trust the system, and build what actually matters.
Forty-seven tasks. Two questions. Four priorities. You've got this.
Now go look at your backlog. You know what to do.
Frequently asked questions
How do indie hackers decide what to build next?
The most effective indie hackers use a simple priority framework like P1–P4 to rank tasks by urgency and business impact. For every task, they ask two questions: 'What happens if I don't do this in 48 hours?' and 'Does this move a metric I care about?' Tasks that block users or revenue are P1 (fix today), tasks tied to growth metrics are P2 (this week), improvements without urgency are P3 (next two weeks), and ideas or nice-to-haves are P4 (capture but don't schedule). This eliminates the daily decision paralysis of staring at a long backlog.
What is the P1-P4 priority system?
P1–P4 is a four-level task prioritization framework designed for speed and clarity. P1 (Critical) means users can't use the product or revenue is blocked — fix it today. P2 (High) means it's important for growth or retention — build it this week. P3 (Medium) means it's a genuine improvement but not urgent — build it in the next two weeks. P4 (Low) means it's an idea or nice-to-have — capture it but don't schedule it. Each level has a built-in deadline, which eliminates the ambiguity of vague 'high/medium/low' labels.
How do you prioritize features as a solo founder?
As a solo founder, apply the two-question filter to every feature request: 'If I don't build this in 48 hours, what happens?' and 'Does this move a metric I care about?' Features that affect core functionality or revenue are P1. Features tied to specific growth or retention metrics are P2. Features that improve the product but aren't urgent are P3. Everything else is P4. This prevents the common trap of building what's fun or interesting instead of what's valuable, and it takes about 10 seconds per task.
Should indie hackers use story points?
No. Story points are a communication tool designed for teams to build shared understanding of effort. When you're the only person estimating and executing, you already have perfect information about how hard a task feels — you don't need a numerical proxy. Story points add overhead without providing value for solo developers. Instead, use the P1–P4 priority system to decide what to work on, and trust your intuition on how long things take.
How often should you reprioritize tasks?
Reprioritize after every customer conversation, after every support ticket pattern, and at the end of every week during your regular review. Customer feedback is the highest-signal input — if three paying customers ask for the same thing, that feature should jump up in priority. Weekly reviews catch items that became more or less urgent based on what you learned. The key rule: task priorities can change, but the four-level system itself should not. Don't add a P0 or P2.5.
What's the best way to handle feature requests from users?
Run every feature request through the two-question filter. Most feature requests are P3 or P4 — they're genuine improvements but not urgent or tied to a metric you're tracking. When multiple users request the same feature, it may warrant promotion to P2. When a feature request reveals broken functionality ('I can't do X'), that's a P1 in disguise. The biggest mistake is treating every request as high priority because a user asked loudly — volume of request does not equal business importance.
How do you say no to low-priority work?
You don't say no — you say 'not now' by putting it in P4. The P4 category exists specifically to capture ideas without committing to build them. Review your P4 list monthly and delete anything older than 60 days. If an item was truly important, it will resurface or get promoted organically. The mental trick: P4 isn't a rejection, it's a parking lot. This lets you acknowledge every idea without derailing your focus on P1 and P2 work that actually moves the business forward.