I like knowing what happens behind the interface.
I'm Poonkawin — a Python backend developer in Coimbatore, three years into building and maintaining a production multi-tenant SaaS platform.
I didn't choose the backend because it was harder, or because I disliked the frontend.
What fascinated me was understanding how real systems work behind the interface.
During college, after building my first full-stack applications, I realised I enjoyed designing APIs, modelling databases and solving performance problems far more than styling user interfaces. The interesting part was never the screen — it was what the screen was asking for.
That curiosity led me to Django, FastAPI and PostgreSQL, where I found the work I actually like: building scalable systems, making slow applications fast, and solving the problems that only show up in production.
Today I'm most interested in backend architecture, developer experience, and AI-powered engineering workflows.
Sri Ramakrishna Institute of Technology. Built my first full-stack applications here — and worked out which half of them I actually enjoyed.
An internal trainee and employee management system. My first production Django codebase, and my first look at how software is maintained rather than just written.
Amazon Sales Analytics on FastAPI — SP-API integration and crawlers moving large volumes of e-commerce data. Where async stopped being a keyword and started being a tool.
Sole Django engineer on a multi-tenant group-buying platform. I own the architecture, the standards, and the paths that move money.
Most backend problems are decisions someone made a year ago.
So I try to make the kind of decisions that are still defensible a year later — and to leave behind a codebase where the next person can see why, not just what.
The slow part is almost never where it feels like it is. I have been wrong often enough to stop guessing.
Good structure is not the one that handles today's requirement most elegantly. It is the one that survives next quarter's.
If a new developer cannot follow it without me in the room, it is not finished — however clever it is.
Measure before optimizing.
Numbers before instinct. Then measure again after, because a fix that cannot be demonstrated is a guess that happened to feel productive.
Simplicity scales better than cleverness.
Clever code is a loan against your own future attention. Plain code keeps paying.
Build systems the next developer can understand.
That person might be a new joiner, or me in eight months with none of the context I have today.
Performance is a feature.
A correct response nobody waits for is not a working feature. Latency belongs in the requirements, not the backlog.
Architecture should make future development easier.
If every new feature costs more than the last, the design is quietly charging interest.
Automation is an investment, not a shortcut.
It costs time up front and pays out on every run afterwards — which is exactly why it gets skipped, and exactly why it should not be.
Good developer experience improves product quality.
Faster feedback means smaller changes, and smaller changes mean fewer things break. The team is a user too.
What has my attention right now.
Mostly more of the same, honestly — learning new technologies, trying AI tools, reading engineering blogs, and continuously sharpening my own development workflow.