Have you got several projects on the go that you’ll probably never finish? Yeah, me too. In this post, I will go through what I did to successfully develop and launch my latest side project. As a result of reading, I hope to inspire you to finish developing and launch one of your side projects.
Since I started working from home and haven’t been able to leave the house for anything non-essential, I have gained a lot of time and a nice home office setup.
Around the start of April, I made a conscious decision to spend my time creating things that would benefit my future, such as writing articles on Medium and a side project.
The side project I decided to start building was one that I’ve wanted to build for several years: A platform for developers to save their in-code solutions to problems. I’m still working on the elevator pitch.
So here’s the problem: You’re working on a project and come across a problem that you know you have solved before. Let’s say you need to remove empty arrays from a deeply nested object. Your go-to way to solve the problem is to find the codebase that you solved the problem in on GitHub, clone it, and look for your code.
Introducing snipd.io, a place to store and search code snippets. Whenever you come up with a solution to a commonly occurring problem, save your solution to Snipd, so you, and other developers, can quickly find the solution.
Tech stack
Frontend
The technologies used in the frontend application were the easiest to choose. In my experience, Next.js is currently the only frontend framework suitable for starting a new project.
Backend
The backend was less straightforward. I’ve been using GraphQL for a while and wanted to keep using that, but there are a few different ways to build a GraphQL server.
Option 1: Roll my own implementation of Apollo server and build the schema & TypeScript types on my own
Option 2: Roll my own implementation of Apollo Server, but use TypeGraphQL to help create the GraphQL schema and TypeScript types
Option 3: Use NestJS with TypeGraphQL for an opinionated implementation of Express and Apollo server
I choose to go with option 3 because it would be faster to get up and running, I could learn NestJS and the backend codebase would be well-structured
Deployment
The deployment process is always the trickiest part, I find it to be a huge context switch from developing the application. To make sure I got the application running and ready for users, I decided to go with the easiest solution I could think of, even if performance does suffer.
Both the frontend and backend applications run in their own docker containers on a single DigitalOcean Droplet.
The database is hosted with MongoDB Atlas, a managed database solution. I chose to use a managed database solution because keeping the data safe is a big concern and a professional provider is always going to do a better job of that than I can do.
The big problem with using a managed database solution is latency. Because I am using DigitalOcean, my database and application are not in single VPC, an option only available with Amazon VPCs. This means the application needs to make a request over the internet every time it reads and write data to the database.
If you would like to start a project with the same tech stack, I created a starter pack that includes everything mentioned above: https://github.com/tomanagle/NextJS-NestJS-GraphQL-Starter
Key learnings
You can create private networks between your applications with Docker: This won’t be new to anyone that is familiar with Docker, but I had never used this functionality before. Because Next.js renders pages server-side, it needs to make requests from its server application to the backend server. These requests can happen internally if you set the GraphQL endpoint to the server’s Docker address when the request is being made server-side.
To do this, create a network in the docker-compose file for both the server and the client, then set the GraphQL endpoint to http://your-container-name:5000/graphql the client.
Keep going, even if you fall out of love with the idea: Every time I stop working on a project, it’s because I fall out of love with the idea. The planning fallacy will always tell you that an idea is easy to execute, but it always turns out to be more effort than you first realized. When the realization sets in that it’s going to be a lot of effort, your natural response is: “is it really worth it”?
Switch your mindset from “is this idea good enough to spend all this time on?”, to “is getting something finished and learning along the way worth all the effort?”. You can never fully answer either question until you have a finished product in the user’s hands.
Don’t keep it a secret: It sounds obvious, but if you never talk about your new project, you’ll never get any users. In the case of Snipd, I was so proud that I finally finished something that I couldn’t help myself and what do you know, people started registering. Admittedly I only have 50 users, but getting users an extremely motivating force.
Make time for ‘leisure coding’: There’s a big difference between coding for a job and coding for fun. Coding for a job requires certain outcomes, often defined by other people. The technologies you use are often ones that you wouldn’t choose and having to build on other people’s code can be a mentally draining challenge. Don’t get me wrong, I love my day job but coding for leisure hits different.
Choose a time that works well for you and stick to it every day, unless you really need a break.
Conclusion
Choose one of your side project or an idea that you’ve wanted to work on for a while and start working on it. Push through the initial phase of dread when you realize the mammoth task ahead of you until you have your first users. Use the motivation from seeing users register and keep building your produce.
The reward of having released a side project makes the effort worth it, even if the idea does suck.
🌎 Let’s keep in touch
Subscribe on YouTube
Discord
Twitter
TikTok
FaceBook
Instagram
Buy me a Coffee
