How I build side projects
My strategic end-to-end approach for building side projects
Introduction
I love to build things. I’m grateful to have the skill set to do so.
In this post, I want to share how I build side projects.
In the end, I’ll answer some of the questions you asked me about building side projects.
Requirements in a document
I start by writing down what I want the project to include. What should it do? I tend to let loose and include many things.
Once that’s done, I reduce the requirements to the MAVP (Minimal Actually Viable Product). What’s the minimal thing I can ship that still offers real user value?
In the first iteration of my project, I don’t want to ship something that includes “everything”. It would take too long to build. I want to ship the minimal thing that still includes the core value the project delivers.
Sketch in Excalidraw
Usually, I have a rough idea of how the project will look like. If I don’t, I’ll look for inspiration over at Dribbble.
Once I have a rough idea of how it should look, I sketch the UI in Excalidraw. This is not too tricky, it’s simply the base for the design.
Design in Figma
Once the sketch is done, I design the project in Figma. I start by deciding the colors and fonts. Designing your project can be difficult if you’re not a designer.
I enjoy designing the project in chronological flow. By that, I mean how the user would land on the page and figure out how to use the app from start to finish.
For my last project, for example, I started by designing the login screens and finished with the share dialog screen.
Resources
To learn to design, I recommend Refactoring UI.
To learn accessible design, I recommend Inclusive Design Patterns.
To learn Figma, I recommend this workshop at Frontend Masters.
Build the project
Now it’s time to build the project.
I start by initializing it and pushing it to a Github repository.
I then deploy my project immediately and ensure automatic deployment is in place. This is quite easy with Vercel. Simply import your repository and deploy, and every time you push to the main branch, it’ll deploy automatically.
It’s important to deploy your project right away. You don’t want to build a full-blown app locally and then struggle with deployment. Pinning down the error will be tricky if that happens, speaking from my own experience.
It’s easy to get distracted. Focus on getting the first iteration of your project done. You can always add more things later. Perfection is the enemy of progress.
As for testing, I enjoy writing tests where it makes sense. My goal is to gain enough confidence to be able to ship. It’s important for me that the core features work as expected. If I have functions that transform data, I enjoy doing TDD and putting a unit test in place.
I prefer E2E tests for the UI tests. I’ll use Playwright or Cypress. If I know how the UI will be implemented, I do TDD. Otherwise, I don’t mind building for a while till I get some more clarity. But I’m a big fan of driving my code with tests.
When writing E2E Tests, make sure to use Testing Library’s accessible queries. This way, you test your app the way the user would interact with it rather than querying implementation details. If you use Cypress, this isn’t baked in (compared to Playwright). You’ll have to add Cypress Testing Library.
Further reading
This post may interest you:
Test-Driven Development (TDD) is not for Frontend developers
Where to learn TDD? FollowDaniel Mokaif you want to learn everything about TDD. Introduction I started out as a Frontend developer. When I learned how to write tests, I dug into TDD. Looking into it, I didn’t think it was for Frontend developers. It felt complicated.
Final check
When you think you’re done, do a final check.
Play around with your app in production. See how it feels. Put yourself in the users’ shoes. Try to break the app.
I often end up doing slight modifications to enhance the user experience before considering it done.
Document the side project
Lastly, you want to document the side project in the README.
Here are some things I like to include:
Demo
What it does
How to get it running locally
Specific features and some code
Bugs or Future improvement ideas
Architecture
Tech stack
Announce
Once it’s all done, you can announce your project.
Share it on all of your socials!
Next steps
The next step is to keep working on the app. The first iteration doesn’t mean you’re entirely done. You can either improve based on user feedback or just keep hacking!
FAQ
What to build?
I like to build a clone of something I want to learn, such as Figma, Excalidraw, Miro, or Google Docs.
Or I like to build something to make it Open Source and actually try to get users.
If you don’t know what to build, just start building something small. It doesn’t have to be the next big thing. Mini projects are totally ok. As long as you’re learning.
How do you find the time?
I’d recommend forming a habit. Regular deep work where you put in the work on your side projects. Focus on being consistent. Consistency adds up over time. Being consistent is better than putting in much intensive work and getting burned out.
How do you finish it on time?
Sometimes I do, sometimes I don’t. You get more clarity on how long it takes to build something as you’re building it. My advice is to really focus on shipping the first “iteration” as mentioned in the beginning. Don’t try to ship something crazy at once.
How long should I work on it?
How long you want. As long as you’re learning and having fun, right?!
If you are building a side project for money, you should avoid working on it for a long time. Instead of making the final product, just make a simple product and see if people like it. If people don't, it won't succeed even if it was final product as well.
Nice article, Tiger! I love how you focus on document your side projects. That’s something I should do more often. When you’re time severely fragmented it’s critical to leave clear pointers on what you were trying to achieve and what would be the next steps. For me it happened quite a lot to forget some important details regarding why a certain approach was not good enough.