Introduction
When I was learning to code, I was building side projects in a bad way.
I was unproductive and struggled with deployment.
This is the article I wish someone had handed me when I didn't have a clear framework for building side projects.
I'm not saying this is the way you should build side projects, but this is what I would've told my younger self.
Step-by-Step guide
Requirements
Begin by defining the requirements.
Open a Google document and write down what the user should be able to do. This will make it easier when you're modeling the data or designing the UI.
Break down the project
It's easy to begin defining loads of requirements.
Break down the project to a minimal usable version. This way you won't have to come up with imaginary scenarios in your head while doing the latter steps.
Design the UI
If you don't know Figma and don't have the time to learn it, you can use something like Excalidraw to at least have a mockup.
Design the UI. Keep it simple. You don't have to design every single detail. It's a side project.
Design the UI to a point where you have a clear vision of what you want to build.
Data modeling
If you're building a full-stack app, spend time modeling the data.
When I model the data, I define the structure and relationships.
How you handle the relationships depends if you're going with SQL or NoSQL.
Another thing to mention, when defining the structure, I also define the type of every property e.g. name: string
.
Building the project
Begin by creating a Github repository and push up something minimal like Hello World.
Deployment
Deploy your project on a platform where you can do automatic deployment like Vercel. Usually, you can just import your Github repository and every time you'd push a new commit, the platform will detect that and redeploy your project.
This is important to do from the beginning because if something causes the deployment not to work, then you know it right away.
In the past, I used to deploy at the very end, but that's risky. If deployment doesn't work in the end, you'll end up debugging the entire project.
Code
How you commit, I leave it up to you.
I recommend not making the commits too big.
When it comes to the code itself, make sure you use a linter and something that formats the code.
As a TypeScript user, I use Eslint and Prettier.
Testing
If you write tests or not, that's up to you.
To me, it depends on the size of the project. If it's big and includes many user interactions, then I'll include E2E Tests.
Completion
If you're done with the project and deployment is working, document it in the README of your project:
Description
What you learned
How to run it locally
Technologies and tools used
Demo (video)
License (MIT)
Conclusion
How to build side projects is pretty subjective.
But there are many things I wish I did earlier.
It would've helped me a lot.