Steal This 3-Step Process for Evaluating New Technology as a Solo Dev
Save hours of wasted time with this proven decision framework
Hey there Solo Dev!
Who doesn’t like a shiny new object?
It feels good to take off that wrapping. To put the new thing to use. And then reality hits.
We realize it was a mistake.
We actually didn’t need that newest, most expensive 13’ iPad Pro with an M4 chip to watch Netflix in bed, and we didn’t need to rewrite it in Rust.
The Solo Dev’s Tech Dilemma
Any time you have to evaluate a technology as a Solo Dev there is ONE concern you must put before all others:
Time.
You might be juggling a full-time job, a family, exercise, hobbies and more.
And to make matters worse?
There’s no one to share the load.
You’re on your own when learning anything new. Fortunately, AI nowadays can really help shorten the learning curve, but it’s on you to figure out if the AI is bamboozling you, or if what is suggesting is the right approach.
The learning curve is all on you.
And the agents of FOMO are out to get you. That new framework? How could you ever finish your project without it? Or his new piece of software? You definitely need it.
Wrong.
Many aspiring Solo Devs use FOMO as a driving force behind their technology decisions.
And that’s not terrible way to go about it.
Do not just assume that newer = better. Instead, try to follow this 3-step process for evaluating new technology.
Step 1: measure the learning-to-value ratio
There’s a constant trade-off between time spent learning and immediate value.
Sometimes we might stick to what we know to deliver value ASAP, while other times we delay the value in order to learn something that will help us make something better later.
We need to define what we’re okay with on our own.
Let’s say a new frontend framework drops (as they unfortunately do often):
Learning curve: ~40 hours to proficiency
Time saved once implemented: 2 hours/week
Break-even point: 20 weeks
Verdict: Only worth it for long-term projects
And then there's the added curveball of maybe using this new technology for other projects in the future. It’s a give and take only you can decide, but one you should consider thoroughly before jumping on what’s new.
Step 2: determine if the project is proven
As solo devs, we can't afford to rebuild our projects every six months. Before committing to a technology, I assess its staying power with these indicators:
Version history: I check its release cadence and breaking changes frequency. Technologies that make major breaking changes every few months become maintenance nightmares for Solo Devs.
Backward compatibility commitment: I read through the maintainers' philosophy on breaking changes, and prioritize frameworks that choose stability over latest features.
Corporate or community foundation: I evaluate who's backing it. Is it maintained by a single developer who might lose interest? A corporation that might pivot strategy? Or a diverse foundation with multiple stakeholders?
The goal isn't to avoid all change. It's simply to ensure that when change comes, it doesn't destroy your project.
Step 3: run a time-boxed experiment
When you've measured the learning-to-value ratio and assessed the risk, it's time to build. But here's where most Solo Devs go wrong: they dive in headfirst.
You need to understand what you’re getting into. I use time-boxed experiments that limit both my emotional and time investment:
Define success criteria: what do you hope to see from the technology?
Start a timer of 4 hours
Create a mini-project or follow the tutorial of the framework in their documentation (which they hopefully have)
Document issues you encounter by writing them down
Make a final yes/no decision
Here’s an example putting it all together 👇
I had to make some choices for my current project last month.
Two of my primary concerns were the backend and database layers.
I was flip-flopping between trying things I was less familiar versus things I had more experience in, mainly:
C# or Python for the backend
Use Postgres for the backend or not
So I ran them through the 3-step process.
Backend
I am proficient at C# and have experience in Python that would need a refresher. For C# I have no learning trade-off before I can create value, for Python I had around 20-40 hours before I’d feel really comfortable.
Both languages are obviously proven, and due to my experience I didn’t feel the need to run a time-boxed experiment.
Ultimately, the hours to learn Python made me choose C#, as well as the fact that it’s the main language I use at my corporate job. This means that anything new I learn is also applicable there, creating more value for myself for the time invested.
Database
I had an idea that I wanted to get more familiar with Postgres.
I estimated I’d need around 20 hours to get where I wanted to go due to my SQL experience. Postgres is a proven project with a long history, and it fit well with my project.
I decided to time-box a learning session of 4 hours.
In those 4 hours I set up a database, ran queries and tested the way things are done. At the end of the session I had a small list of minor issues that were mainly caused by my inexperience, so I decided it would be a good fit for the project and started using it.
The hard truth most Solo Devs need to hear?
Sometimes the most productive technology decision is deciding not to adopt something new, no matter how shiny it looks.
See you next Saturday!
Until then, what technology have you been considering adopting? Try running it through this framework and see what you discover.