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

Source: Dev.to

Requirements

• 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

Initial Stack (2022)

• React 18
• PHP 8.1
• MySQL

It worked well and felt snappy. The codebase was simple and naive.

Switching to a More Powerful Stack

Next.js

Wanted raw SSR power, server‑side logic from the frontend layer, and SEO optimization.

Go

Needed API scalability for a future mobile app and thousands of users.

PostgreSQL

Started paying for a managed PostgreSQL service, assuming it was needed over MySQL.

The first version was released in a month.

Price

The first problem was cost. Using render.com, each service cost $7 / month. With a frontend, backend, and database the total was around $21 / month, which was heavy for a small association.

Scalability

A major mistake was confusing scalability with complexity.
The system was full of abstractions and layers that made it organized but slow to change. Such a setup suits a large corporation with many developers, but for a small project it became a burden whenever a feature needed tweaking.

Version 3

After realizing we needed something cheaper, we switched to a different stack while keeping SEO benefits.

• Next.js – for SEO
• Directus – back‑office
• PostgreSQL

Next.js connected directly to Directus APIs, which felt great locally. Deployment was on fly.io for its low cost and automatic machine scaling.

Drawbacks: Directus took 5–10 seconds to start, the frontend another 2–3 seconds, resulting in 7–13 seconds to load the landing page.
Benefit: No monthly fees.

Version 4

We later realized many Directus‑editable sections were unnecessary. The refactor reduced editable parts to three sections.

• Next.js (full static site)
• PostgreSQL with Prisma as ORM
• NextAuth for a quick login system
• Simple dashboard for the three editable sections

The result: a one‑week website after almost four years of work.

What I Have Learned

• Complex solutions are great conversation pieces, not necessarily good for production code.
• Cost and infrastructure decisions should be made before drawing UML diagrams.
• The project taught me to view the product as an integral part of the overall system, aligning with the association’s needs.
• Scalability is relative; it depends on your actual requirements.
• “The less you think about the future of the product, the better.” Build simple things and leave room for growth—less is more.