I almost didn't write this post. I had the tab open for three days, typed a few sentences, deleted them, and closed the laptop. Classic imposter syndrome loop.
But here's the thing: I'm currently building a full-stack project management SaaS called Planora, designing a supply chain intelligence platform from scratch, and figuring out RAG pipelines and distributed systems in between lectures. And none of it exists on the internet with my name on it. That bothered me enough to finally open the tab again.
It wasn't a single moment. It was a slow accumulation of solving the same problem twice because I hadn't documented it the first time.
Debugging a STOMP singleton issue on a WebSocket layer. Fixing N+1 query storms buried in JPA relationships. Understanding why OSIV is an anti-pattern in production. Good problems, the kind you learn from. But a week later, the exact mechanics had faded.
Writing is how I force myself to understand something fully, not just well enough to move on.
That's the real reason. Not personal branding, not SEO, not building an audience. I write because explaining something clearly is the only honest test of whether I actually understand it.
If you're an undergraduate building real things, not tutorial projects, actual systems with real constraints, I want this to feel familiar. Not aspirational. Not intimidating. Just someone a step or two ahead sharing what they're running into.
For me, this is a long-running document of how I think. Six months from now I'll read something I wrote today and cringe at my own reasoning. That's the point. Growth needs evidence.
I'm an IT undergraduate in Sri Lanka, working part-time on Planora, a Spring Boot and Next.js SaaS product for teams. My domains are authentication, task management, and document/S3 handling.
Outside of that, I'm building NexaFlow, a solo AI-native supply chain platform I'm planning to ship over four months.
My current stack:
I'm headed toward distributed systems, AI integration in backend services, and eventually building things that ship to real users. That's the thread you'll see running through everything I write here.
No rigid schedule. I've seen too many "I'll post every Tuesday" intros end at post three. Instead, I'll write when I have something worth saying. That might mean two posts in a week when I'm deep in a hard problem, and nothing for a few weeks during exams.
The format will vary too. Some posts will be technical deep-dives. Some will be short notes: decisions made, mistakes learned from. A few will be more personal, like this one, because learning in public keeps the work honest and useful.
I'm not a senior engineer. I don't have a job title that validates opinions on architecture. Half of what I know came from failing in production-adjacent environments and reading error logs at 1am. That's the honest version.
But I've also noticed that the people who helped me most weren't experts explaining concepts from on high. They were people slightly further along, writing about what they'd just figured out. That's the gap I want to fill, for whoever is a year behind where I am now.
You don't need to be an authority to be useful. You just need to be honest about where you are.
So that's what this is. An honest record of building things, breaking things, and figuring out what I actually believe about software. Thanks for being here at the beginning.
Newsletter
Occasional notes on full-stack craft, polished interfaces, and building a portfolio with real signal.
Sign in with GitHub to leave a comment or reaction
Related