I recently came across a post from a solo developer who captured something I’ve also struggled with in the past:
I’m literally the only tech person here and I’m overwhelmed by decisions.
- Migrate the frontend to Next.js? Astro? TanStack Start?
- Backend to Nest.js? Or ditch Node for Go?
- Is MongoDB still fine? Or should I chase down PostgreSQL?
Isn’t it a horrible feeling?
Being a solo developer and having no one to bounce ideas off. You’re alone with fifty different opinions from the internet, and no way to know which one is right for your situation.
Every decision feels like a fork in the road with tons of rabbit holes. You’re full of self-doubt and you end up procrastinating instead of focusing on what you should be doing - building. Every decision you make, you second-guess:
- “Worried Cloudinary might get expensive if traffic spikes: should I plan on switching to Bunny CDN + S3”
- “I really like the ease of Netlify and Render, but is it worth learning something else? Is it future-proof?”
You waste time digging through online discussions confirming your opinions, while life moves on and new business requirements pile up. Not only that, but new tech gets released, and little by little, you feel like you’re getting crushed under a pile of decisions.
The way out
Imagine confidently making technical decisions, knowing it’s the right choice for your use case, and moving on without second-guessing yourself.
No more searching through forums for an opinion that matches yours just to feel a sense of calmness. No more wondering if you’re falling behind because you haven’t adopted the latest framework. You make the call, close the tab, and get back to your project - your project that works, and gets you paid.
Here’s the thing: Most of the time, the tech is fine as is. The reason you’re suffocating is because you’re unsure of what you’re actually trying to achieve. That uncertainty is what makes you over-engineer solutions and second-guess your decisions.
Sure, the fancy frameworks and tools from Meta and Google have great marketing. All the tech YouTubers are talking about them! However, if you know exactly what outcomes you are trying to achieve, and you scrutinize your technical decisions with these outcomes in mind, it becomes much easier to dismiss things you clearly don’t need and focus on the things you do.
Know your outcomes
Before you can evaluate any technical decision, you need to know what your software exists to do. Not the features - the outcomes. What are you enabling for your users?
- Letting busy people order groceries online
- Allowing gym goers access via an electronic card or mobile app
- Helping surfers check conditions before heading out
- <Insert the thing(s) your business does and customers pay for>
Write them down. Keep them visible. They’re the foundation for every decision.
The filter
When making the next decision, hold it up against your outcomes and ask:
1. Does this serve my outcomes?
Not “is this cool” or “is this best practice” - does it directly enable what I’m trying to achieve? If not, don’t add it, don’t rewrite it, don’t touch it.
Your users don’t care if you use Postgres or SQLite or MongoDB. Stick with what you have until it becomes a bottleneck for your company.
Is rewriting your app to have a cleaner architecture worth it? Only you can tell - are you losing customers over it? Are you experiencing weird bugs all the time? Then maybe. Do you find it personally ugly or just not that exciting? Don’t touch it.
2. Does this make things simpler or more complex?
Every tool you add can break, change pricing, get deprecated, or need configuration you’ll forget. Is the benefit worth that cost?
Always pick the simplest solution. Sometimes this means getting an off-the-shelf product instead of building it in-house. There is more up-front cost, but your time as a developer costs money too.
Sometimes the cleanest code is no code.
3. Am I solving a problem I actually have?
Not one you might have someday. Not one a blog post warned you about. A real problem, happening now.
Is your traffic high enough to warrant the added complexity of a CDN? Do you really need a data lake right now?
When in doubt: choose simpler. You can always add complexity later. Removing it is much harder. Start small, start unscalable, filter out the noise. Grow with your product.
Your one action
Before you spiral on another decision, do this:
Write down your top 1-3 outcomes. Not features. Not technical goals. What is your software actually trying to enable? Put the list somewhere visible.
The next time you’re drowning in options for a decision you can’t seem to make, go through the filter. Use your best judgement, make the decision, and move on.
When your decision is guided by outcomes, you can always justify making it.