Lavanya Mishra | MVP Specialist | Indie Hacker
@coolindiehacker.bsky.social
Shipping Chrome extensions & micro-SaaS.
Your MVP in 14 days. 2/3 slots filled – DM for the last one.
Your MVP in 14 days. 2/3 slots filled – DM for the last one.
The study mode asks several follow up questions that forces me to think the specifics about the topics and gives a much better list.
November 22, 2025 at 1:39 PM
The study mode asks several follow up questions that forces me to think the specifics about the topics and gives a much better list.
What’s one rule you follow when writing error messages in your apps?
November 21, 2025 at 12:21 PM
What’s one rule you follow when writing error messages in your apps?
If you want fewer angry users, fewer support tickets, and a smoother UX…
Fix your error messages.
It’s one of the highest ROI changes you can make.
Fix your error messages.
It’s one of the highest ROI changes you can make.
November 21, 2025 at 12:21 PM
If you want fewer angry users, fewer support tickets, and a smoother UX…
Fix your error messages.
It’s one of the highest ROI changes you can make.
Fix your error messages.
It’s one of the highest ROI changes you can make.
Error messages shouldn’t explain the problem.
They should guide the user out of it.
They should guide the user out of it.
November 21, 2025 at 12:21 PM
Error messages shouldn’t explain the problem.
They should guide the user out of it.
They should guide the user out of it.
One more thing:
Always tell the user what to do next.
“Your workspace couldn’t be created due to privilege issues”
vs
“Your workspace couldn’t be created. Ask your admin for permission.”
The second one actually helps them.
Always tell the user what to do next.
“Your workspace couldn’t be created due to privilege issues”
vs
“Your workspace couldn’t be created. Ask your admin for permission.”
The second one actually helps them.
November 21, 2025 at 12:21 PM
One more thing:
Always tell the user what to do next.
“Your workspace couldn’t be created due to privilege issues”
vs
“Your workspace couldn’t be created. Ask your admin for permission.”
The second one actually helps them.
Always tell the user what to do next.
“Your workspace couldn’t be created due to privilege issues”
vs
“Your workspace couldn’t be created. Ask your admin for permission.”
The second one actually helps them.
And please… stop adding emojis to error messages.
If a user already feels blocked, “😡” or “😢” only makes it worse.
That’s how you turn frustration into rage-quit energy.
If a user already feels blocked, “😡” or “😢” only makes it worse.
That’s how you turn frustration into rage-quit energy.
November 21, 2025 at 12:21 PM
And please… stop adding emojis to error messages.
If a user already feels blocked, “😡” or “😢” only makes it worse.
That’s how you turn frustration into rage-quit energy.
If a user already feels blocked, “😡” or “😢” only makes it worse.
That’s how you turn frustration into rage-quit energy.
Another rule:
Don’t expose status codes to users.
It might help you debug, but it also leaks unnecessary info to anyone trying to mess with your app.
Don’t expose status codes to users.
It might help you debug, but it also leaks unnecessary info to anyone trying to mess with your app.
November 21, 2025 at 12:21 PM
Another rule:
Don’t expose status codes to users.
It might help you debug, but it also leaks unnecessary info to anyone trying to mess with your app.
Don’t expose status codes to users.
It might help you debug, but it also leaks unnecessary info to anyone trying to mess with your app.
So write for them.
Not for your teammates.
Not for your logs.
A clear message beats a technical one every time.
Check out my Substack for more breakdowns like this: coolindiehacker.substack.com
Not for your teammates.
Not for your logs.
A clear message beats a technical one every time.
Check out my Substack for more breakdowns like this: coolindiehacker.substack.com
Lavanya Mishra | Substack
MVP Specialist | Indie Hacker | Shipping Chrome extensions & micro-SaaS. Your MVP in 14 days. 2/3 slots filled – DM for the last one. Click to read Lavanya Mishra, a Substack publication. Launched 2 m...
coolindiehacker.substack.com
November 21, 2025 at 12:21 PM
So write for them.
Not for your teammates.
Not for your logs.
A clear message beats a technical one every time.
Check out my Substack for more breakdowns like this: coolindiehacker.substack.com
Not for your teammates.
Not for your logs.
A clear message beats a technical one every time.
Check out my Substack for more breakdowns like this: coolindiehacker.substack.com
Most devs write errors for other devs.
That’s the first mistake.
Users don’t care about “DB CRUD operation failed due to invalid API key.”
They care about one thing:
Did it work or not?
That’s the first mistake.
Users don’t care about “DB CRUD operation failed due to invalid API key.”
They care about one thing:
Did it work or not?
November 21, 2025 at 12:21 PM
Most devs write errors for other devs.
That’s the first mistake.
Users don’t care about “DB CRUD operation failed due to invalid API key.”
They care about one thing:
Did it work or not?
That’s the first mistake.
Users don’t care about “DB CRUD operation failed due to invalid API key.”
They care about one thing:
Did it work or not?
How do you handle dependencies?
Disciplined pruning or copy-pasting npm commands on autopilot?
Disciplined pruning or copy-pasting npm commands on autopilot?
November 21, 2025 at 9:14 AM
How do you handle dependencies?
Disciplined pruning or copy-pasting npm commands on autopilot?
Disciplined pruning or copy-pasting npm commands on autopilot?
Two things happen when you stay disciplined:
• New devs instantly understand the project.
• You stop second-guessing what’s safe to remove.
• New devs instantly understand the project.
• You stop second-guessing what’s safe to remove.
November 21, 2025 at 9:14 AM
Two things happen when you stay disciplined:
• New devs instantly understand the project.
• You stop second-guessing what’s safe to remove.
• New devs instantly understand the project.
• You stop second-guessing what’s safe to remove.
Here’s the simple fix:
Delete dependencies the moment they’re no longer needed.
Just cut.
Delete dependencies the moment they’re no longer needed.
Just cut.
November 21, 2025 at 9:14 AM
Here’s the simple fix:
Delete dependencies the moment they’re no longer needed.
Just cut.
Delete dependencies the moment they’re no longer needed.
Just cut.
Early-stage startups are the worst for this.
Product–market fit keeps shifting.
Dependencies pile up.
Your node_modules grows into a black hole that could eat your laptop.
Product–market fit keeps shifting.
Dependencies pile up.
Your node_modules grows into a black hole that could eat your laptop.
November 21, 2025 at 9:14 AM
Early-stage startups are the worst for this.
Product–market fit keeps shifting.
Dependencies pile up.
Your node_modules grows into a black hole that could eat your laptop.
Product–market fit keeps shifting.
Dependencies pile up.
Your node_modules grows into a black hole that could eat your laptop.
Because here’s how most projects really go:
1. You need a feature.
2. You install a library.
3. The feature becomes irrelevant after user research.
4. You install another library for the new requirement.
5. Repeat until chaos.
1. You need a feature.
2. You install a library.
3. The feature becomes irrelevant after user research.
4. You install another library for the new requirement.
5. Repeat until chaos.
November 21, 2025 at 9:14 AM
Because here’s how most projects really go:
1. You need a feature.
2. You install a library.
3. The feature becomes irrelevant after user research.
4. You install another library for the new requirement.
5. Repeat until chaos.
1. You need a feature.
2. You install a library.
3. The feature becomes irrelevant after user research.
4. You install another library for the new requirement.
5. Repeat until chaos.
Installing packages is easy.
Managing them with discipline is not.
That’s why I follow one rule in every project:
Only keep the dependencies you actually need.
Check out my Substack: coolindiehacker.substack.com
Managing them with discipline is not.
That’s why I follow one rule in every project:
Only keep the dependencies you actually need.
Check out my Substack: coolindiehacker.substack.com
Lavanya Mishra | Substack
MVP Specialist | Indie Hacker | Shipping Chrome extensions & micro-SaaS. Your MVP in 14 days. 2/3 slots filled – DM for the last one. Click to read Lavanya Mishra, a Substack publication. Launched 2 m...
coolindiehacker.substack.com
November 21, 2025 at 9:14 AM
Installing packages is easy.
Managing them with discipline is not.
That’s why I follow one rule in every project:
Only keep the dependencies you actually need.
Check out my Substack: coolindiehacker.substack.com
Managing them with discipline is not.
That’s why I follow one rule in every project:
Only keep the dependencies you actually need.
Check out my Substack: coolindiehacker.substack.com
Frontend or API doesn’t matter.
Dependencies run the show.
And they quietly destroy your project if you stop paying attention.
Dependencies run the show.
And they quietly destroy your project if you stop paying attention.
November 21, 2025 at 9:14 AM
Frontend or API doesn’t matter.
Dependencies run the show.
And they quietly destroy your project if you stop paying attention.
Dependencies run the show.
And they quietly destroy your project if you stop paying attention.
What about you?
Are you shipping fast and cutting ruthlessly or still hiding behind “one more feature”?
Are you shipping fast and cutting ruthlessly or still hiding behind “one more feature”?
November 21, 2025 at 8:17 AM
What about you?
Are you shipping fast and cutting ruthlessly or still hiding behind “one more feature”?
Are you shipping fast and cutting ruthlessly or still hiding behind “one more feature”?
Keep it simple.
Hard problems don’t always need hard solutions.
Lean feature sets win.
Hard problems don’t always need hard solutions.
Lean feature sets win.
November 21, 2025 at 8:17 AM
Keep it simple.
Hard problems don’t always need hard solutions.
Lean feature sets win.
Hard problems don’t always need hard solutions.
Lean feature sets win.
2. Have a fixed release cycle.
Weekly. Biweekly. Doesn’t matter.
Shipping on a schedule forces clarity and kills pointless features.
Weekly. Biweekly. Doesn’t matter.
Shipping on a schedule forces clarity and kills pointless features.
November 21, 2025 at 8:17 AM
2. Have a fixed release cycle.
Weekly. Biweekly. Doesn’t matter.
Shipping on a schedule forces clarity and kills pointless features.
Weekly. Biweekly. Doesn’t matter.
Shipping on a schedule forces clarity and kills pointless features.
Talking to users is like tracing a drawing.
The masterpiece exists.
They’re the tracing paper helping you reveal what actually matters.
The masterpiece exists.
They’re the tracing paper helping you reveal what actually matters.
November 21, 2025 at 8:17 AM
Talking to users is like tracing a drawing.
The masterpiece exists.
They’re the tracing paper helping you reveal what actually matters.
The masterpiece exists.
They’re the tracing paper helping you reveal what actually matters.
How to avoid bloat:
1. Start talking to users.
You’ll realize the problem you think you’re solving isn’t always the real problem.
1. Start talking to users.
You’ll realize the problem you think you’re solving isn’t always the real problem.
November 21, 2025 at 8:17 AM
How to avoid bloat:
1. Start talking to users.
You’ll realize the problem you think you’re solving isn’t always the real problem.
1. Start talking to users.
You’ll realize the problem you think you’re solving isn’t always the real problem.
Your version of “perfect” and the user’s version of “perfect” aren’t even close.
Ship early.
Let reality punch your assumptions.
Ship early.
Let reality punch your assumptions.
November 21, 2025 at 8:17 AM
Your version of “perfect” and the user’s version of “perfect” aren’t even close.
Ship early.
Let reality punch your assumptions.
Ship early.
Let reality punch your assumptions.