Being a solo developer watching your project drag on longer than expected, you've probably wondered what's actually going on. I see the frustration in posts from devs online, and I think it's something a lot of us go through at some point in our careers.
Although it may feel like you bit off more than you can chew, it's not always a single point of failure that's causing your projects to stall and spike your anxiety levels.
Here are some things that you may be doing, intentionally or not, that might be contributing to development taking so long:
1. Pulling time estimates out of thin air
Have you ever looked at a seemingly simple project and thought: two months, maybe three? A year later, you're still working on it.
The problem isn't necessarily that you're slow. Absolute time estimates are pure fiction when you're building something you are not a domain expert in - and even then, unknown unknowns1 will constantly surprise you.
It may very well be that your work velocity is fine, but your estimate was too optimistic. However, once you set over-optimistic estimates, you stress about hitting your made-up deadline. Then you don't even ship what you have because it doesn't match your initial vision.
Try this
If possible, stop with the hard deadlines. Track relative progress instead. Did you move forward this week compared to last week? How does the effort and complexity of this feature compare to that other feature? This gives you relative estimates. These will probably still be off (unknown unknowns, remember?), but they'll be way less off than magical absolute deadlines.
For tracking project progress, I like using Kanban. You move cards from TODO to Doing to Done. You can estimate how cards relate to one another (task A seems like more effort than task B), but you don't slap fabricated deadlines on them.
2. Choosing your tech stack based on popularity and trends
What works for a team of 50, 100, and 1000+ developers at a VC-funded startup won't necessarily work for you; but you'll be sure to hear about it at every meetup, conference, and online forum.
This is especially true within the "fullstack JavaScript" ecosystem, where a hot new framework emerges every couple of months. Something I've heard before: "by the time I'm done, a new version of all my tech stack will be released."
When you use a tech stack just because it's trendy, you quickly find out that what works for others does not necessarily work for you. You end up fighting against the tech stack and feeling anxious because you're not productive with the tools that random online posters claim make them print money and singlehandedly saved their marriage.
Try this
Pick tools that make you productive. This does involve investing time to find your perfect toolset, but it will pay itself off many times over the years. Being a solo dev usually means you have a lot of flexibility in picking the tooling that you want. You probably don't let others tell you what size of shoes to wear, so do the same for your tech stack. To continue the shoe analogy: walk around in your tech stack for a bit, and see if it fits.
For me, the stack for most web projects is Elixir, Phoenix, and SQLite. It's stable, it lets me move fast, and since SQLite is embedded, I don't need to maintain a separate database server. This stack is optimized for dev happiness, saving money, and reducing headaches - for me.
3. Obsessing over scalability
Being a solo builder means you've got to be prepared for everything, including overnight success and enormous traffic spikes. That's what we love to imagine: "What if the thing I'm building becomes so successful that it collapses, and I'm unable to restore it?"
This fear is sometimes even stronger than the fear of not having a single user! To deal with it, we tend to over-engineer the simple things... you know, just in case.
What's your realistic expected traffic? Hundreds of users don't need infrastructure that handles millions. You probably don't need to clone Google's infrastructure setup, even though their marketing team would be delighted if you did. The time you spend tinkering with Redis, sharding your database, setting up microservices, and multi-region deployments could be spent on developing things that your users care about today.
Try this
Build for your actual needs, not your fantasy launch day. You can scale when you need to. In most cases, it's easier and cheaper to start simple and make it scale later.
I have one VPS at Hetzner running Dokku. All my projects live there. The stack I use is light and performant enough that I don't need the complexity of AWS, and I save on hosting. If traffic ever becomes a problem, I switch to a beefier VPS.
4. Focusing on too many tangents
Sometimes you're learning a new technology as you work on your project, or you decide that it's worth developing something in-house instead of using an off-the-shelf solution. You will naturally be slower and less efficient. This is fine and expected, but it is important to be realistic about what it means in terms of progressing the core functionality of the product you're working on.
To use a bit of gaming terminology, the more side quests you take on, the slower you progress on the main quest.
Try this
Be mindful about your tangents. If you decide to use a project as an opportunity to use that new programming language you just learned, don't also use a database you're not already comfortable with, a new deployment method, etc.
I write down and clearly tag my project's side quests so that it becomes immediately obvious when I'm starting to focus on the wrong thing. It's usually not difficult to get back on track, but first you have to realize you've strayed off course.
5. Finding new things to add before shipping
This one kills projects. You're nearly done but you keep finding cool new things to add. You've told your friends about what you're building and they've got some interesting suggestions that you want to implement. Also, things look a bit barebones; surely you've got to perfect all the tiny details before the big launch, right? By doing this, you're essentially perpetually moving the finish line. Shipping a minimal product tomorrow is better than never shipping a perfect product.
Try this
After the initial research and requirements gathering, write down the exact features your MVP2 will include. Everything else goes in a "nice to have" list that you ignore until after you ship. Forget about the new features you just dreamed up, even if they seem more exciting to implement. Ship it now, perfect it later. Small, consistent improvements beat stressing over a perfect, big release.
I like to keep the 80-203 rule in mind. With a minimum amount of work, you can ship a thing that users can already start using and give you feedback on; getting feedback early means you can focus on the stuff that actually matters to your users.
6. Neglecting your health
Being in the zone4 is awesome, and at times you don't dare move out of your chair because you're afraid of breaking that flow. However, your body needs maintenance, and it rewards you for it. How many times have you found a solution to a mind-boggling problem while not actively solving it? On a walk or in the shower; you weren't focused on the task at all! It might feel counter-productive at first, but you can actually perform better by not working for a couple of minutes (taking a break).
There's research on this! A 2022 paper found that taking micro-breaks boosts vigor (your "energy") and reduces fatigue (your "tiredness"). Another study from 2022 reports that active micro-breaks every 30 minutes reduce discomfort in office workers with no productivity loss.
Try this
Take small breaks every 30 minutes. Sometimes you're too busy; that's fine, but try not to skip 2 breaks in a row. Drink lots of water. Adjust your workspace ergonomically to minimize the risk of injury. Change your posture (e.g., from sitting to standing) often. Get enough sleep. The small stuff compounds and helps you feel more energized. More energy means you can work on the project without feeling like you got hit by a bus. It's a marathon, not a sprint (get it?).
Although a bit clunky, I use my phone's timers to work in pomodoro-like focus sessions. I also use it to remind myself to drink water. If working from home, I also try to air out my workspace, and during breaks, I get on the floor and do some simple bodyweight exercises.
Final thoughts
Solo devs tend to work harder when they should work smarter. You're not a crappy developer for not shipping fast enough. You're probably just fighting yourself by incorrectly defining what "fast enough" means, not investing time to figure out which tools you excel with, focusing on too many tangents, and by not allowing your body and mind to recover.
Footnotes
-
Unknown unknowns are variables that we cannot expect because we don't know what they are yet. ↩
-
Minimum viable product. A barebones product with just enough features that you can give it to your users and start gathering feedback. ↩
-
Also known as the Pareto principle. It can be simplified as roughly 80% of outcomes result from roughly 20% of causes. In other words, 80% of your product comes from 20% of your effort. ↩
-
Being in the zone means being fully focused on a specific task. ↩
Top comments (0)