I built my project 4 times, that's what I learned

Refactoring an institutional website and what I have learned.

The requirements were simple:

I started my journey with Classicum Association 4 years ago in 2022.

• A landing page that could explain briefly what the Association was about
• A web app to register people and to sign their presence at events

I started with a simple webpage on this stack:

• React 18
• PHP 8.1
• MySQL

It all worked pretty well, it all felt pretty snappy for the time. The codebase was simple and naive.

Then the change happened.

We wanted something more powerful to handle notifications, concurrent events, accounts, comment sections, interactions, images, and that could scale to infinity.

The worst part is that I set these goals for myself without actually needing them or having anyone asking me.

I switched to this stack:

• NextJS: I wanted the raw SSR power, having the possibility to run server-side logic even from the frontend layer. And I wanted to be optimized for SEO
• Go: I wanted API scalability in order to have in the future a mobile app and scale with thousands of users in mind
• PostgreSQL: I started paying an actual service that served PostgreSQL. I did not know the difference with MySQL at the time but I felt like I needed it

The first version was released in a month.

Price

The first problem was the cost, I was using render.com and it cost $7 per service. Given that I had a front end, a back end and a database it cost around $21 per month.

The association was small at the time and that price was kinda heavy on us.

Scalability

One of my huge mistakes was confusing scalability with complexity.

Basically my system was not scalable, it was full of abstractions and layers that made everything very organized but very slow to change. That kind of system was suitable for a large corporation with many devs that can take their time to make changes and all the abstractions and layers are needed to avoid committing mistakes. For my use, that added complexity was a burden on my shoulders for every time I needed to add or tweak a feature.

Version 3

After the realization that we needed something way cheaper, we went with a different stack. I still wanted scalability but without reinventing the wheel.

1. NextJS: I wanted all that juicy SEO all for me
2. Directus: to handle all the back-office part
3. PostgreSQL

NextJS connected directly to the APIs exposed by Directus. It felt great working on it locally.

I deployed it on fly.io because it was cheap and it had the ability to turn on and off machines automatically.

That was the big problem of this setup — Directus took about 5 to 10 seconds to fire on my setup, the front end another 2–3 seconds. This meant I had to wait 7 to 13 seconds just to load the landing page.

On the bright side, we paid nothing monthly.

Version 4

Eventually I realized we didn't need all that Directus offered. Many sections of the website that were editable on Directus didn't need to be edited.

I refactored the codebase once again.

I only needed 3 sections to be editable. I went full Next.js and PostgreSQL, Prisma as ORM. Everything static except for these 3 sections. I created a quick login system with NextAuth and a simple dashboard to add items. That's it—almost 4 years of work just to get everything working with a one-week website.

What have I learned?

Complex solutions are something to talk about with your nerd friends at the pub to look cool, not something you want to find in your codebase.

Cost and infrastructure are something you need to think about way before even writing a UML diagram.

This project did not teach me a lot about new technologies or clean code or complex architectures; it taught me to think about the product as a part of the system that needs to agree with all the other parts of the system (which in this case is the association).

Scalability is not an absolute term; it depends on what you need.

If I could talk with the old me, I would tell him that when you are building something, "the less you think about the future of the product, the better." Let me explain: if you shoot for the stars with your products, you will find yourself in trouble quickly. As my team leader taught me, build stupid things and leave space for the future — do not add things to anticipate it. Less is more.