For some reason, developers are starting to wear the number of unfinished side projects as a badge of honor: the more the better. They get the idea, buy the domain name, throw down some lines of code, and a few weeks later, they get excited about a new idea and leave the other one to rot.
Why do you think that is? I know why I used to do it: I used to think with my code, instead of properly planning my projects.
Whenever I had a new idea, I would start turning my thoughts into code without hesitation. But that’s not the right way to do it, is it? By the time a new shiny idea arrived, I was elbow deep in code, dealing with my business logic.
And so I had to decide: New project from scratch vs. continue dealing with a problem I don’t know how to solve? The decision was easy, and the outcome the expected: I was incapable of finishing a single side project.
So, let’s take a look at what it means to tackle a side project correctly and what else needs to happen besides actually coding the damn thing.
Control the Urge the Start Coding and Make a Plan Instead
Whenever a new idea hits, you have to keep yourself from coding. Not for long, but there are a few tasks you need to take care of before you get to that part.
Coding is the “fun” part, I know, but coding without a plan is the worst thing you can do for your project.
To create a plan:
- Decide on what you’re building.
- Make a list of features. It doesn’t have to be detailed, but at least a bullet list of points you want to cover.
- Out of that list, decide on the bare minimum that needs to be implemented and which ones would be “nice to have,” so you have an MVP (Minimum Viable Product) scope.
- Think about the architecture of the product. Will this live in the cloud? Will it be a mobile app? Will it be able to function once you release it into production this way?
These are all questions you have to ask yourself. There is no coding involved, so don’t get confused. I’m not asking you to do anything other than to open a text document or a Trello board, or whatever you want to do and start asking yourself these questions.
By answering them, you’re already miles ahead of the rest who’re already writing code. Trust me on that one, you’re making a plan.
A plan will give you a finished scope, a pre-defined list of things you have to work on. This is major because it’ll tell you when you’re done. If instead, you started coding without thinking about what you’re implementing, you’d start adding features on the go and, potentially, you’d never see the end of it. That is known as “scope creep,” when you start adding extra scope before you’re done with your current one, and it’s one of the main reasons why software projects die.
So, make a plan. Heck, make several plans: one for the MVP, one for version one, one for version two, and so on. But whatever you plan, try to stick to it as much as possible. Only once you’re done with your current plan, start thinking about the next one.
Think About the Stability of Your Code
We’re all tempted to start throwing code around that “just works” because we want to move forward.
That’s not entirely bad, as long as you remember that this code needs to be reviewed and tested shortly after.
My go-to advice here would be to code thinking about stability from the get-go. But if speed is a problem and you need to get the first working version of your product ready, then, by all means, avoid all quality standards for the time being. But don’t forget about the forever, just enough for you to get that first version out (usually a pre-MVP version known as a Proof of Concept).
You should later come back to the code and properly go through it with a more detailed eye. Looking for things such as:
- Stability problems. Did you take into account every edge case for your logic when building this PoC version? Are you sure your code is stable enough to keep on adding more features?
- Code smells such as code duplication and lack of proper coding standards could hurt your progress in the future.
The point of this step is to make sure you have a solid base for the future. Adding patches on top of patches without a proper foundation is like building an office building without a blueprint on top of moving sand. That building is not going to be finished. And neither is your project.
Eventually, you’ll find problems that are too big to patch and that would require you to refactor a big chunk of your code. And that will be when that new project that you’ve been thinking about starts looking like a great idea.
Spend some time and stabilize your foundation, add unit tests, integration tests if you have multiple systems. Try to automate as much as possible from the build process. This will all contribute to you focusing on what really matters: getting the project done.
Scaling Should Not Be a Future Problem
How many users do you expect to have? How much data do you want to work with?
Answer these questions (or similar ones) at the start of a new project, and if you don’t have enough experience with previous ones, it is not only hard but near impossible.
At least it is if you want to answer them accurately. But that’s not what I’m saying here. The point of asking yourself these questions at this stage is not to properly estimate the traffic or the workload your product will have, but to plan for your ideal scenario.
There is a big difference between building a product that only works on your machine and building something that can be used by a few hundred people. And don’t get me started if you’re aiming to reach a lot more clients. If you build something that works for ten users because you never stopped to think about this point, the minute 100 users find your product, they won’t be able to test it. The thing will be slow; it’ll be unresponsive; it’ll crash on them. You’ll lose the users you were trying to gain simply because you didn’t stop for a second to think about your architecture before writing your code.
The project was doomed from the get-go, and you didn’t even know it.
Coming up with the architecture of your project is not easy, especially so if you don’t have prior experience. But again, the point here is not to come up with the ultimate architecture, one that will be able to work for every situation. Instead, my point is that you should review the ideal scenario where your product is successful and ask yourself: will they be able to use it if I build it like this?
Maybe you’re building a web app, and you’re going with a monolithic approach. Chances are that you’ll have to switch to a microservices-based architecture, eventually. The jump from monolith to microservice will require a huge refactor. Instead, you could’ve foreseen this and created just a few microservices, enough to get the gist of the workflow going so if tomorrow you need to disaggregate some of them, the basic architecture is already set up. The refactor should be less painful that way.
Or perhaps you’re having to process a lot of information daily. One approach would be to just iterate over it and serially process it. After all, having 10 or 20 users means you only take ten minutes. That’s not a big problem. But what happens when your users start to scale up? 100? 1,000? Now you’re jumping from 10 to 100 minutes, or maybe even more. Is your processing script still able to cope with that amount of data? Instead, you could’ve foreseen this and thought about doing some parallel processing. It would’ve been harder to implement from the start, but the process would’ve scaled up a lot better now.
The point I’m trying to make is that there is a big difference between getting your first version up and running to make sure it works vs. having a product that you can call “production-ready.” The first one is the PoC, and we’re allowed to do whatever the heck we want inside it, but the second one, which we can call MVP or version 1, needs to be built with certain considerations because it’ll be the one our real users will interact with. And we want them to be happy, don’t we?
Scale is a problem from the start — not a big one, mind you, but it should be in the back of your mind — and you should drive all your design decisions based on it (along with your other business needs).
Just Because You Build It, They Won’t Come
“If you build it, they will come.”
That phrase doesn’t work in this situation. Building a great product is not enough if you want to succeed. You also have to find a way to reach your audience.
And there are many ways to do it too; it’s all about marketing in one way or the other. But the gist of it is that you have to have an online presence.
If you’re not findable online, your chances of your product being a success are greatly diminished.
What does it mean to be findable? That’s the key isn’t it, there is no one single way because it depends on the type of users you’re targetting. Are those users normally finding what they need through Google? Are they using Reddit? Perhaps they’re searching on Pinterest because they’re looking for visual products?
There are infinite ways for them to find what you’re offering, the point is that you should understand them before deciding on your marketing strategy.
Once you do, provide them with as much information as you can:
- Creating content around your product might help. Blog posts, videos, Instagram stories, you name it. The point is to create fresh content around your project that others might find. This helps transmit the message that you’re actively working on it and that you care about interacting with your users. This is not a project built ten years ago and then forgotten.
- Create evergreen content as well. Tutorials and user guides answering common questions about how to use your product are great ways to get users to love you. You then have to find the places where they’re asking about it and try to link the content there. If they’re going on Facebook groups to ask, make sure you’re there to answer. If they’re asking on Stack Overflow, set up an alert and reply to those questions. Be there for your users.
- Finally, building online is a trend that’s proving to work quite well too. By sharing your building process you gain an audience while at the same time developing your product. That way, by the time you have your project’s first version ready, you have a set of clients already interested and eager to try it. This is not an easy process, and it requires you to share both your highs and lows to prove you’re honest about it. However, if done right, the results can be great.
Whatever you decide to do, remember that building the product and having the code working is not enough to call it “done.” Reaching your clients is just as important and should be part of your plan from day one as well.
Is it easy? Heck no! And you might want to ask for help if you’ve never done it before. But neglecting it and having no marketing strategy whatsoever means you’ll have a much harder time ramping up the user count once you release. Keep that in mind!
Next time you have an idea for another side project that you really want to finish, remember to:
- Push through the idea of starting to code it right away and make a plan for it.
- Allow for stability in your code once you do code it.
- Think about scale and design around that idea.
- Start building an audience as soon as possible.
This should help you increase your chances of getting to a point where your project can actually be deployed and used by others.
What do you think? Have I left a step out?
Top comments (0)