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.

How to build side projects from scratch

Comments (1)

More from this blog

Become a cracked product engineer today

Bipedal, humanoid, and the words for creature shapes in games

Lerp and smoothstep, what they actually do

IK and FK, what they actually are

How to make your textures fast on the GPU

Introduction

Step-by-Step guide

Requirements

Break down the project

Design the UI

Data modeling

Building the project

Deployment

Code

Testing

Completion

Conclusion

Command Palette

Comments (1)

More from this blog

Introduction

Step-by-Step guide

Requirements

Break down the project

Design the UI

Data modeling

Building the project

Deployment

Code

Testing

Completion

Conclusion