A developer who thinks like a security specialist.

Security is not a layer I bolt on

Most web developers meet security as a checklist near the end of a project. My route in was different: alongside application work I did frontend development for a network security and firewall company, which meant living inside the tooling — Suricata IDS/IPS, Microsoft 365 Security, Microsoft Defender and web filtering.

That gave me hands-on exposure to how security is engineered at the infrastructure level, not just the application layer. The practical result is that I design web applications to be secure from the interface down to the network, rather than hardening them after something has already gone wrong.

It is also why the rescue work on this site — malware removal, hardening, incident cleanup — is not a sideline. It is the same skill set pointed at a problem that has already happened.

What I actually work with

Where I go deepest

• Full-stack web development — PHP/Laravel and the MEAN stack, across everything from small business sites to enterprise systems.
• WordPress security, malware removal & blacklist recovery — cleanup, root-cause analysis, Google Safe Browsing and blocklist delisting, then hardening so it does not happen twice.
• AI-integrated web applications — FastAPI backends powering AI features inside real products, not demos.
• REST & GraphQL API development — versioned, authenticated and documented APIs, plus the integrations that hang off them.
• Database design & optimization — schema design, indexing and fixing the slow queries that only show up once real data arrives.
• CI/CD pipeline design & automation — GitHub Actions pipelines that make deployment boring.
• Network & firewall security — Suricata, Microsoft 365, Defender and web filtering.
• Cloud infrastructure & server management — AWS, Linux, and the hosting layer underneath it all.

How I work

• Scope and price agreed in writing before anything starts. No hourly creep, and no invoice you have not already approved.
• You own everything. Code lives in your repository, infrastructure is written down, and the handover includes documentation your next engineer can follow.
• I tell you when the answer is no. If a rewrite is not worth it, or your budget will not cover the job properly, you hear that before you pay rather than halfway through.
• Reversible by default. Canary rollouts, tested backups and written rollback plans. Nothing consequential happens without a way back.

Who I like working with

Startups, founders and creative teams building something meaningful — people who want a developer close enough to the problem to argue with them about it, not a supplier who ships whatever the ticket says.

I am based in India and work remotely with clients anywhere in the world. Everything runs in English and in writing by default, so there is always a record of what was agreed. Urgent work — a compromised site, a production outage — gets a same-day response whatever your time zone.

Why fixed scope, not hourly

Hourly billing rewards the wrong things. It pays more for slow work, punishes the engineer who solves a problem in one line, and leaves you unable to budget.

Fixed scope forces both of us to be clear about what is being built before anyone starts — the part most projects skip. It also puts the risk of the work running long on me, which is where it belongs.