Hello there!
This post here is to go through (with you) my thought process when trying to create and release a side-project idea. It's really important to try to get around the chaos of the creative process and stablish a structured process for any project. After reading my thoughts on this, feel free to engage the discussion and comment something below š
If you just want to check what was the project made, you can check it here.
The first step: The IDEA
This is where many of you can suffer a lot. I think we can divide the general programming public in two segments: the more creative ones and the more pragmatic ones, generally, more pragmatic people will have difficulties having an idea while creative people will have difficulties taking it out of the paper.
My approach to this is generally think of problems that impact my daily basis, all those problems require solutions and solving it for you can help others with the same problem too! Taking problems that exists within hobbies or trying to create solutions to problems that people you know have can be a great way to get your mind started.
The most important tip here is just to start creating. Sometimes we spent so much time thinking about the perfect idea that we end don't creating anything. Always remember: Not-perfect is better than inexistent.
The second step: The planning
After defining the ideia, you should go to plan before the code (sometimes, when the project is really, REALLY small, you can skip this and go direct to code, but beware, if you skip this step when you should not, it's going to bite you later).
The planning stage is kinda simple, get a somewhat free tool like Figma, or draw.io and put your idea in the white canvas. Don't worry too much if it does not make a lot of sense, the whole idea of this step is to achieve this.
Draw flows, databases, pages, start creating and don't have fear of making some mistakes. Don't forget to look into references too, they can give you a lot of inspiration!
The third step: The refinement
After you created the draft, it's time to create the definitive version of your project prototype. Define a scope and gather everything you think it's useful within that scope, refining the flows in order to have a good UX - this is majorly important, even with small projects (sometimes, we, as developers, can overlook the experience of the application, but whenever you'll need to show this project to someone, the UX that is what is going to be evaluated).
Since UX is really important, gather this Laws of UX and try to create a good consistent design.
If the project you are creating does not includes front-end and UX is not the problem, this doesn't mean you can create in the most chaotic way possible. Anytime you are creating something, spend some time to improve your skills and learn new things, unit and e2e testing, design patterns and architectural patterns can make a whole lot of difference and can be really fun to learn (you can check here to learn more)
The fourth step: The code
Code until it's done or until you are happy with the result (always remember, you can finish the project in another day)
The fifth step: The release
After you are done with the first version of the product, make a release plan! Where are you going to discuss about it? Never underestimate the power of organic conversion, many people can see your project even when you don't expect to.
Think of metrics that will gather good insights for creating more things for the product later and track them using analytics services like umami or others.
The practical case:
The problem: I really did not like the experience of searching for specific items in the wiki of Warframe (a game that I enjoy). I would like to have a better experience when searching for items and where to get them.
The idea: Create a website that would get data from Warframe's item API and would inform things that are useful for the user looking to get them (like price value, drop location, and things like that).
The planning: Started to sketch the flow in draw.io until it looked reasonably nice.
After that, started playing around with the UI components that Skeleton UI have until I was satisfied with the appearance of it.
The refinement: I defined a more ambitious scope, while started to research how I could get things from the API. After that, the whole project was already kinda structured and we could start to code for real
The code: Decided to use Svelte and SvelteKit (since I'm learning both of them) and started to code! Created a git repo, initialized the dev environment and created things like I planned before.
The release: Expected to release it in the reddit community of Warframe and see what kind of reactions I got! The sheer number of views and most visualized pages were interesting enough data for me to track.
The post:
The statistics:
And now, I'm posting it here (and probably will update this to reflect how other DEVs react to the post!
Thanks for reading! You can see the project live here
Top comments (21)
Wow! Realy nice post. When we stay alone with a Idea or new solution, do organize all aspects could be creppy on start. You explained all basic steps pretty fine.
Could you consider a sugestion about your next post? How do work with a partner on this same project, sharing doubts and code.
Bye!
Thanks for the comment and the suggestion! I really liked it!
I'll surely write about it, I was already working on something similar to this, so it should come in a near future! š
If you have any other suggestions of moments on the developer life that you struggle with, don't hesitate to tell me. I'll write my thoughts on it as soon as possible.
Hey @robsongrangeiro, I made an article about communication that I think you should check out! It can give you some insights on the process of working with partners and other people in general! Have a good readš
This is a great article. You showed us your thought process, which is thorough.
It's true that some developers never get their idea out of paper. I was like that before, but now, I'm trying to get out an MVP for feedback and suggestions. The processes you listed in this article will help.
thanks for sharing.
Thanks for the comment and the good feedback!
It's really good to see that you're trying to get feedback for your MVP and that the article will help you on it. It's easy for us to completely ignore the users in the creation process, leading to a product which the users don't need.
The users, which are the target public you want, are the central piece of it all. We should never forget that.
Thanks again!
Yes, the users are the main component in the success of any product.
If users don't like the product, the product is a failure, no matter how you paint it.
This is an article I never knew I ever needed so badly. I currently have some side projects but I never knew how to plan them out and implement them like some software engineering project. Your article gave me a lot of insights on how one can approach a project and just start building.
Thank you so much!
You have code way too late in the process for my taste. In my opinion you should start coding at step one and again at every step. Your planning and refinement will mean little until you start to flesh out your project.
Thanks for the comment!
Well, in minor side-projects, I agree with you that maybe we can pull up the code phase in the step list, but, if you're going to do something a little bit more than minor, I usually like the approach of thinking first - coding later better, since it can prevent a lot of refactor later.
The general idea is that, if you spend time thinking about it before coding, you'll only have to code the basis of the architecture once and it will naturally evolve and develop itself without a lot of hassle. When you don't spend the necessary time thinking, you generally solve the problems as they come (which can be unoptimal and even more problematic later, since quick solutions can generate even greater problems).
But you're not alone on you opinion too, a good strategy if you have more eagerness to code and don't care to refactor some of it later (while still maintaining the certainty that your code works as expected) is start by developing some tests! TDD can help you a lot in those cases š
This is comprehensive, and I loved reading along with you through this marvelous journey you shared with us.
Thank you!
It's great to read that you enjoyed reading as much as I enjoyed writing it!
Thanks for the reply!
Great article! I often see some developers neglect the planning and refinement phases, which I agree are big mistakes.
One 'hot take' that I have (honestly, I don't know if it is still a hot take) is that planning too much at the lower levels, like the code itself, is not worth it.
I don't mean people shouldn't think about code architecture and design patterns, but designing the entire system with UML and then starting to code is, in my opinion, a waste of time. It's sort of like learning programming fundamentals with pseudocode and then learning an actual language ā you can do both at the same time.
Great article - broken down the steps really well. This is very similar to how I would go about it but instead I prefer to do a bit more validation first before I start coding.
Thanks for comment!
The larger your project/idea becomes, more validation is needed before coding (and in general, is better to spend more time validating, than discovering that you coded something useless or bad architectured). Nice tip!
Exactly!
It's so important to do this before you start writing code, otherwise you have no idea if the things your building are actually want your customers actually need.
Plus having a bunch of features from day one can make it much harder to figure out whats working and whats not.
Thank you!
My question, as a beginner, would be: after you have the idea, between steps 1 and 2 (or 2 and 3), how do you evaluate the feasibility of completing what you first envisioned? Experience/knowledge? Or do you go over that during the 'planning' phase?
Excelent question! The feasibility of a project is majorly dependent on the experience/knowledge of the team working on said project and should be planned accordingly.
One way of resolving this is simply evaluating in terms of hours of development every feature drawn on the plan.
Your first evaluation probably will not be really precise (and you can ask other developers to evaluate this set of features aswell). But, do not worry! You'll get better at it!
At the end, the feasibility of a project will be a simple matter of answering the question: Do I have enough time to complete every feature? If not, what should I prioritize in order to create enough of a product that will still generate value for our users?
This was a grand article, thank you for sharing what you have learnt, providing resources and the real-life example.
Amazing article! The step by step guide with resource links and your own project as the case study with screenshots is high quality stuff!
Thanks a lot for the comment! I hope that part of my journey and the findings that I learned can be inspiring for you!