I have studied pharmacy, which is a strange thing to lead with on a developer's site — until you find out I also built and sell a pharmacy ERP that real pharmacists use for real, daily billing. That's not a coincidence. Most of what I build sits at the same intersection: institutional systems, retail operations, construction workflows, public procurement — places where the software has to get a real-world rule right, not just look right.
I look for the rule beneath the screen, the dependency beneath the feature, and the point where a process usually breaks, then build backward from there. The interface matters. The data model underneath it matters more, and it's usually the part nobody in the room wants to talk about first.
Day to day, that means getting sharper across the whole stack at once: schemas that hold up under real concurrent use, frontend code that doesn't fall over on a pharmacist's five-year-old laptop, and enough testing and deployment discipline that shipping on a Friday doesn't feel like a personal risk. AI tools do a lot of the typing these days. They don't get a vote on the data model.
Engineering principles
The rules I actually apply, not a mission statement.
Data model correctness over UI polish
A beautiful screen sitting on top of a wrong model doesn't fail quietly — it fails in production, in front of a customer, usually months after everyone stopped double-checking it. Get the model right and the UI is just decoration you can redo anytime.
Get the core domain right first
Every feature bolted onto a fuzzy domain model is a small loan against future rework, and the interest rate isn't fixed. I'd rather lose a week arguing about what a 'student enrollment' actually is than lose a month migrating a table that was never quite right.
Complexity should track the problem
New patterns show up because they're interesting, not because the project needs them. If the problem is a CRUD app, it gets CRUD-app complexity — reaching for something fancier because it was trending that week is how you end up maintaining two systems instead of one.
Maintainability is a product feature
Nobody puts 'easy to change safely' on a feature list, but it's the one that decides whether the product is still alive in two years. A system too fragile to touch doesn't announce it — it just quietly stops shipping.
The best abstraction is often none
Three near-identical blocks of code are annoying. A wrong abstraction pretending three things were always the same thing is expensive — and you usually don't find out which one you built until a fourth use case shows up and doesn't fit.
Milestones
January 2025 — Present
Founder & Developer · SARK ERP
A commercial, offline-first desktop ERP for independent Indian pharmacies — a single Go binary with an embedded React frontend and a local SQLite database, sold directly with node-locked licensing.
January 2026 — Present
Full-Stack Product Builder · Independent / Freelance
Designing and building multi-tenant SaaS products, civic-tech scraping pipelines, and analytics-heavy product workflows — EduWav, the KPPP tenders dashboard, and Pro Trader Journal.
January 2025 — December 2025
Full-Stack Developer · Independent / Freelance
Built GST-ready retail ERP workflows, veterinary pharmacy inventory systems, and tender-discovery foundations for contractor workflows — QUIK ERP and QUIKTENDERS.
January 2024 — December 2024
Frontend Developer · Independent / Freelance
Shipped focused browser tools for construction estimation and GST-ready document generation — Civil Tools and related business utilities.
Currently
Most days that means shipping on three fairly different products at once — EduWav, the KPPP tenders dashboard, and Pro Trader Journal — which sounds like context-switching until you notice they're all the same problem wearing a different costume: keep the data honest while real people lean on it. The rest of the time goes to getting properly good at the parts of the stack I didn't grow up in — deployment, testing discipline, and using AI tools the way a good junior engineer should be used: fast, never unsupervised.