If you're looking for my old blog, it's been moved. Go to old blog →

Handling side projects as a developer

Published

help me by sharing on twitter

Hey there!

Today I want to talk about handling side projects as a developer.
Us developers have the benefit of being able to literally build stuff, and while that’s awesome, it just doesn’t always help us.

I think it’s pretty usual for any developer to have started working on a bunch of ideas and then throw them in the trash. I myself have done that countless times.
I want to talk about the “strategies” that I have been using to try and get something actually done. There are a few points I want to talk:

Don’t start coding like crazy

That’s what we usually do.
Now, before I start coding something (unless I’m ridiculously excited), I give it 12 hours. If in 12 hours I still want to code that, that’s a positive sign.
What used to happen - at least to me - is that I would think of something, code like crazy and give up. Giving it a few hours gives me confidence it’s something I’m likely to build to the end.

Try to think of everything the MVP is going to need.

Instead of just writing code with no clear intentions, I now write all the features I can think of for an MVP in a piece of paper.
Sure, I might change a thing or two while developing but that usually helps me have a rough idea of how much time I’m going to take and helps me not deviate from the basic features needed.
If I think of a new feature while coding, I'll also weight if it's something that would be awesome on an MVP or if it can sit on the backlog for awhile.
If you keep adding features endlessly, you never launch.

Do not reinvent the wheel

Unless you are trying to learn things or if what you're building requires totally new things, try not to reinvent the wheel.
If there’s a well-maintained package for something you want to develop, use that instead. You can always contribute to that project or if you need something much more robust and specific, you can develop your own later down the road.

Be consistent.

One of the major things that made me drop projects in the past is the ups and downs. I'd get excited, code for several hours, then not code for a few days, then code for 12 hours straight and at the end I'd drop it. Reserving some time to it daily helped me tremendously.
These days I define something like "dedicate 3 hours a day to X", and when I say dedicate I mean actually sit down and focus totally on that.
Some days I get to work a little bit more, some days less, but I'm always consistent on working on them.
Another thing I do is, if working on a project every day is too hard (or if you have more than one), I'll define some days to work on them. I'd rather consistently work 3 days a week than occasionally work on them.

Invest in copywriting and a landing page.

I’d say the copywriting is even more important than the design.
That’s something I didn’t know anything about and there are some really good resources out there.
I recommend Marketing Examples on twitter and there are a few additional resources I’m going to leave at the end.

Share.

Share what you’ve been learning on communities like Indie Hackers, Reddit and Twitter. More often than not someone who’s done something similar to what you’re working on will chime in and give you some tips. It’s also great to get any type of feedback.

Good Marketing Examples.

Marketing for Engineers.

Thanks for reading and if possible give the twitter thread some love

Keep track of my articles, tutorials and courses and receive valuable information directly in your inbox.

Thanks for subscribing!