I'm Kushal Tiwari — a senior software engineer with 5 years of designing systems that age well. From .NET backends to React frontends, from PostgreSQL schemas to mobile UX — I treat every layer as a chance to build something predictable, scalable, and clean.
Most engineers pick a layer. I pick problems — and design the entire stack to solve them.
I'm not just a backend engineer, and I'm not just a frontend one. I'm a full-stack engineer who thinks in systems — someone who can hold the whole stack in their head, from the database schema to the button a user clicks, and work every layer with the same care.
I work in essence before form. I ask why before how. I prefer a boring, predictable solution that runs for ten years over a clever one that breaks in ten months. Patterns are useful — they're the shared language of developers and the consequence of what worked — but the question I keep coming back to is: what is essential to this system? Hold to the essence, and you can change anything around it without breaking identity. I love clean patterns, generic abstractions, ownership of logic, and code that gets out of the way of the people who use it.
Over 5 years I've shipped credit lending platforms, medical ERPs, biotech websites, and a social platform — across .NET, React, Flutter, Angular, Node, PostgreSQL, MS SQL, MongoDB, Supabase, Firebase, Redis, and Docker. The stacks change. The discipline doesn't: understand the problem, design the system, then write the code.
People hire me not as a coder, but as a thinking partner — someone who can sit with a messy requirement, find the actual core, and turn it into a system that's elegant, maintainable, and built to evolve.
These aren't aspirations. They're the lens I evaluate every decision through.
Before any pattern, ask what is essential to this system — and what is incidental. Hold to the essence and you can change anything around it without breaking identity. That's what makes a system adaptive instead of brittle.
A boring solution that runs for a decade beats a clever one that breaks in months. I optimize for the next person who has to read this code at 2 AM, not for the cleverness of the one who wrote it.
Build abstractions that outlive the current feature. If we need it twice, we need it once — abstracted. If we need it three times, we need a system. The specific is the cost; the generic is the asset.
Not by over-engineering for traffic we'll never have — but by keeping the seams clean enough that growth becomes a config change, not a rewrite. The system should grow because its boundaries invited growth.
A great engineer doesn't stop at the API boundary. I think in user journeys, database queries, and network calls — all at once. The system is the product, not the layers.
I hold total clarity on what's accepted, what's denied, and what good looks like — for every system I touch. That's the only way AI, or any collaborator, can help us rapidly without costing us years of bug-fixing later.
Across fintech, healthcare, social, and enterprise. Each one taught me something the architecture had to absorb.
Five years of production. Depth where it matters, breadth by design.
The craft hasn't changed. The instruments have. I use both with intention.
To actually tame AI and use it to ship faster without losing creativity or productivity, the architecture and constraints have to be set clearly first. Form before matter: what is accepted, what is denied, what good looks like. We need total ownership of the logic of the code — even if AI writes it — so it can help us fully and creatively, not cost us 2 years of bug-fixing after 1 day of development. Better to spend 6 months on planning and development than 1 day of dev and 2 years of fixing.
Open to senior engineer roles. Hybrid & remote. Open to global timezones.