Now, I approach backend design very differently.
Instead of asking:
“How can I make this flexible?”
I ask:
“What constraints are actually real right now?”
Because unnecessary flexibility is still complexity.
You just notice it later.
One backend mistake I made early that caused unnecessary complexity later:
Trying to make everything flexible from the start.
At first, it felt like the “right” approach.
I wanted systems that could:
adapt easily,
support future changes,
and handle multiple possibilities.
The more flexible the system became,
the harder it became to reason about:
How data moved
How components interacted
What behavior was actually expected
Everything technically worked.
But understanding and maintaining the system became slower over time.
Over the next few months, I’ll be focusing on:
- backend architecture
- distributed systems fundamentals
- building scalable services
MIP isn’t going away. It’s just moving in a different direction.
I’ll be sharing that journey here.
That changed how I want to approach this.
Instead of continuing MIP as just a full-stack app, I’m shifting focus towards the backend and system side of it.
I’ve started working with Go and diving into system design to understand how real systems are built and scaled.
This phase isn't glamorous.
But it's where most projects quietly fail; when the work becomes repetitive and unshowy.
Still building.
Still prioritizing correctness over cosmetics.
One small but useful decision along the way:
For email flows, I used Nodemailer's temporary test accounts instead of wiring up real Gmail credentials.
It kept things simple and avoided premature infrastructure decisions.