How I Build Projects Faster - My Stack and Strategies

Juan Emilio - Jul 1 - - Dev Community

Hello everyone, I'm Juan, and today I want to share with you the strategies and technologies that I use to develop projects as fast as I can in my free time. In my last post, I talked about how I try to apply the 48-hour rule and how that helped me to get my first project that generates income, something that I couldn't achieve for the past 2 years, despite the amount of effort and time that I've dedicated.

I remember when I started to develop my first side-projects, I would wake up at 6:00 AM before going to my job so I could have some time to make all the progress possible in just 2 hours. But I'll be honest, most of those early mornings, I couldn't get anything done because I spent most of my time struggling to choose between one technology or another, trying to decide whether I should write my code one way or another, fighting against myself, deciding on a project and then changing all over again. Not to mention that each time I started a new project, I had to set up everything once more. For that reason, today I'll try to answer some of those questions that I used to have, and hopefully, my experience can help someone out there with the same struggles. Also, I'll take the opportunity to share with you, dear reader, what I think about writing shitty code for your personal projects.

We are not the industry

Before moving on to my stack and talking about which technologies I like to use, I would like to share my opinion on a problem that we developers share (at least most of the decent ones). When I started working on my first projects, something that stole most of my time was myself. Always trying to write the best piece of code, the most reusable function, the best component, everything in a perfect structure, putting as much attention to detail as I could, looking for the best technologies to start. And you know what? All of that is garbage for your side project. Let me ask you something: why do we need reusable code if the codebase is never going to grow? Why do we need a perfect structure if the project hasn't even started and we don't have any customers? Why spend so much time choosing the right technologies when things like Netflix or Instagram started with Python and Django? We need to remember that when we are starting a project, we are looking for speed, not perfection. The time to fix the mess that we are creating will come once we have at least a sustainable base of customers who are consuming our product or service. So I know and understand that you want to write the perfect code (I hope so), but it is not our priority when we are just starting a new project that we don't even know if it will go as we expect.

Let's try to change our mindset and prioritize wasting as little time as possible while developing as much code as we can.

Why do I love writing code this way?

I love pushing myself to develop as many features as I can in the minimum time possible because that forces me to stay focused and also gives me a real approximation of my ideas. I can't even count how many times I thought I had the best concept for my side project and when I finished it and brought it to reality, it was nothing close to what I was looking for. But that's good because I figured it out as soon as possible and now I can make all the changes that are required to get what I want.

Besides all of that, forcing yourself to fit your project into just a 48-hour window creates a special atmosphere. Everything feels different, and the code just flies around. You are able to solve more problems and teach yourself how to prioritize ideas and how to simplify them. I hope you give these strategies a chance and put yourself to the test. Try to see if you can create your side project in just 48 hours. Worst case scenario, you'll make decent progress on your project and will only need to spend another round of 48 hours.

How I do it?


Now that I've given my opinion and shared my ideas, let me try to explain as clearly as I can what I do each time a new idea hits my mind.

Get a roadmap

If you are going to follow my advice (and I hope you do), you'll be writing code while you run, and when you go that fast, it's easy to lose yourself among all the things you have to do. That's why we need to spend some time before starting to create a plan that is clear enough to guide you through your journey but not detailed enough to make your scrum master happy. Don't overcomplicate it; just get a piece of paper and write down all the things that you need to do with their corresponding sub-tasks. Or, if you are more fancy like me, you can download Obsidian and structure your roadmap there. You'll end up with something like this:

To do list on obsidian

This is just an example, and you can structure your work as you please, but the important thing is to have something that helps you quickly check what you have to do when you get lost.

Getting our toolkit

Perfect, at this point you already have your roadmap, and you are almost ready to go. But before we start, we need to avoid spending tons of time trying to find the perfect technologies to develop the project and sustain scalability across all development.
I hope you noticed the irony in the previous paragraph. There are no such things as perfect technologies, just tools that adapt to our needs or the needs of the project itself. Normally, what I do to avoid overthinking this is just choose the technologies that I'm most familiar with for the job ahead. If I don't know enough and I have to learn something new, I just pick the one that I'm most interested in. This is what I use:

Frontend:


Before moving into my list and some of my favorite libraries to save time, I'll just say that most of the time I end up using React with Vite instead of NextJS, simply because I don't really need the extra features that come with it, and it's faster for me initially to use React "vanilla".

So here's my list:

  1. React
  2. Tailwind
  3. React-Router
  4. Auto-Animate
  5. React-Query
  6. Redux
  7. Smart-Layout
  8. React-Hot-Toast
  9. React-Icons
  10. Zod
  11. React-Hook-Form
  12. Shadcn
Auto-Animate:

Auto-Animate landing-page picture

This is by far one of my favorites because I think animations in a web app add professionalism. I really hate when I enter an app and it's all static. If you want automatic animations for your components when they are mounted or unmounted, this one is really handy.

React-Hot-Toast:

React-Hot-Toast landing-page picture

If you don't know it, you can thank me later because by far this is the best library to render notifications on the screen. To be honest, there is nothing bad to say about this library. It's easy to use, visually appealing, and undoubtedly helpful.

I use it to render alert, success, and loading events, saving me a lot of time when I want to let users know what's going on.

Smart-Layout

Smart-Layout documentation picture

I created this library in my free time, and let me tell you, it is really helpful when you don't want to waste too much time trying to think about the "perfect" layout structure. Not to mention that maybe what you think is the perfect layout structure for you is not for your users.


It still needs a lot of work, but it's stable and some interesting changes are coming. If you want to know more about it, here is another post of mine, giving some examples.

Shadcn

Shadcn landing-page picture

Shadcn is your best friend when you are trying to get some components pre-made but at the same time having your own style. It still needs more components, like a datetime-input, but besides that, there's not much more problem than that.

Backend:


For the backend, I used to use FastAPI with Python or NestJS with TypeScript, both of which are really good frameworks. But if you are looking for velocity, I would choose FastAPI. NestJS follows the SOLID principles and forces you to write code that way, something that can be good at a bigger scale and for the industry but definitely is going to slow down your progress in the short term.

Small backend:


You probably noticed that I didn't pay much attention to the backend. That's not because I don't like it, but because most of the time I try to keep my backend as simple as possible, for the following reasons:

Don't reinvent the wheel

Let's be honest, probably the majority of the things you need are already invented. That's why I always spend some of my time looking for tools or services that make my life easier before doing anything while I'm tracing my roadmap. I know, I know, just a few lines before I said that we have to keep it simple and not look for the perfect technologies. That's correct: keep your roadmap easy and don't look for perfect technologies. But probably the first time you are going to do a side project, you'll have to invest some of

your time learning about a bunch of technologies, services, or tools to help you. That's partly why I'm doing this post: to save you that time. You can copy my stack and you are ready to go, but probably there are going to be things I don't cover here. So look for something that solves your problem and don't overthink it.

Use your client's power

If you are just starting a side project, try to avoid investing money in it, at least until you validate your idea. If you follow this principle, you probably won't have a lot of computational power at the beginning. That's why you should take advantage of your client's power. I focused so much on the frontend because that's where I usually concentrate most of the product's logic, at least at the beginning. In that way, the computational load for each one of them will depend on their devices.
This is not ideal in the long term for various reasons, but I don't see any problem doing this at the beginning. Just keep in mind that it will be more secure, better performing, and easier to control if you keep the logic on your side. The only problem is the cost.

BaaS, Database, and more magic for free


As I mentioned before, I try not to reinvent the wheel each time and instead take advantage of any technologies, tools, or services that I can access within my budget. So next, I'll present you a list of options that I use when I want to save some time and avoid spending any money.
It's important to clarify that these options are free only up to a point. From there, you'll have to pay. When you reach that point, hopefully, you'll be able to sustain the structure with your customers' income or migrate to other options that better suit your budget if you decide to do so.

Turso-DB

TursoDB landing-page

By FAR one of my favorites. This is a database running over libsql, a fork of sqlite with wonderful performance and scalability, having a generous free tier with over 500 DBs available and 9GB of space, more than enough to get something up and running to validate your idea.
Not to mention it has available servers in LATAM (Chile) so if you are from the southern hemisphere like me (Argentina) you'll really enjoy it.

Clerk-Authentication

Clerk landing-page picture

I've tested many User Management Platforms but none of them are as good as Clerk. If I had to define it with some keywords, I would say: easy to use, amazing documentation, wonderful examples, attention to detail, easy to customize for free.
So take advantage of Clerk and just like me, give your users an amazing experience when authenticating on your app and avoid wasting time reinventing the wheel.

Cloudinary-Media Storage

Cloudinary landing-page picture

Avoid the trouble of implementing a media storage system in your API and take advantage of Cloudinary. With the free tier and limiting your users to HD images, they can upload up to 6000 pictures (obviously this can vary depending on many factors), more than enough to validate your idea.

Self-Host Deploy

Coolify landing-page picture

If you choose to self-host, something that I strongly encourage at the beginning, I'd go with Coolify. By far the best Self-Hosting tool ever created. You can easily handle: domains, servers, automatic deploys, and much more with just a few clicks. It's really easy to use, but if you have any doubts, probably the best video about it out there is this one (even better than the documentation itself).

Do it faster next time with your own tools


Finally, to do it even faster every time, I use a scaffolding project, avoiding having to reconfigure my entire project each time I want to start something new based on something else that I previously worked on. In order to do this, I use:

Degit - what a wonderful tool to reuse your code

Degit is a tool that helps you clone repos automatically unlinking them. This is amazing for creating scaffolding projects really easily. If you don't know what a scaffolding project is, let me explain and show you how to create one.

What is a scaffolding project:

A scaffolding project is a code base that you can easily reuse to generate other projects, avoiding generating all the boilerplate repeatedly. It can be any code base that you constantly repeat over and over again.

How to build one:

It's really easy. Just create any project, push it to a public repository on GitHub, install Degit:



npm install -g degit


Enter fullscreen mode Exit fullscreen mode

and execute:



degit user/repo my-new-project


Enter fullscreen mode Exit fullscreen mode

From now on, you have a reusable project from any of your repositories.

Wrapping UP


If you reached this point, let me congratulate you because it was a huge post, and it was even longer, but I shortened it due to the reading duration. Let me know if you are interested in smaller posts with more content like this, maybe talking about payment methods, ORMs, and more tools and strategies to create code even faster.

HEY!!! Before you go


If you enjoyed this article, please help me stay out of the diabolic "9-5", so I can keep trying to learn and share my experiences with all of you:

Buy Me A Coffee

Among friends


Now that we are among friends, let me tell you that even a little help is really helpful. I'm twenty years old and I've been coding since I was fourteen. Now I'm trying to do something slightly different, and maybe it's hard to imagine, but that little donation helps me a lot.

. . . . . . . . . . . . .