Pinned Tweet
Hey everyone
I’ve been meaning to properly introduce myself here, so… here we go
I’m George, a full stack developer. I’m really into building things with code, learning new stuff, and figuring out how to turn ideas into something people can actually use.
I’m currently focused on full-stack development, but I’m especially enjoying the backend side of things - APIs, databases, system design, and all the little problems that come with building real applications.
One of the things I’m currently working on is SewDesk, a project I’m building to help tailors manage their businesses more easily.
I’m still learning, still making mistakes, and definitely still figuring things out. But I thought it would be nice to start sharing more of that journey here.
So yeah, that’s me.
If you’re into tech, building things, or you’re on your own learning journey too, feel free to connect.
#developers
Sir George retweeted
Client: "Ok I can work with these terms, but first, which country are you from?"
Okay… this is starting to look like a real SaaS.
Some of the SewDesk UI I’ve been working on.
The goal isn’t just to make it look good, I want the experience to actually make running a tailoring business easier.
Frontend is coming together nicely.
#buildinpublic #webdevelopment #nextjs
Modular monolith 💯💯
Every serious application needs microservices? It's a lie.
It doesn't.
There are two architectures you should understand first:
Monolithic architecture;
Your users, orders, payments, authentication, inventory, etc. all live inside one application.
Everything is deployed together.
Modular monolith;
It's still one application and one deployment, but the code is separated into well-defined modules.
Users have their own module.
Orders have their own module.
Payments have their own module.
Each module has clear responsibilities and boundaries.
The major difference is coupling.
A poorly designed monolith can become a giant ball of interconnected code.
A well-designed modular monolith can remain organized, maintainable, and easy to scale.
And here's the part people overlook:
You don't need to start with microservices just because you're building something ambitious.
Start simple. Create strong boundaries. Split into separate services when there's an actual reason to.
Microservices solve some problems.
They also introduce a whole new category of problems.


























