About
How I work, and what I bring to a team
Five years of building the API and the interface that sits on top of it, mostly for people who are not engineers and need to trust what they are given.
In my own words
I work across the whole stack. On the backend that usually means Python with FastAPI or Django, SQLAlchemy and Pydantic for modelling and validation, and PostgreSQL or MySQL underneath. On the front end it means React with hooks and context, or Astro when a site has to be fast and search friendly above everything else.
Most of my work starts with an open-ended conversation rather than a written spec. I'm comfortable sitting with clients and researchers who are not engineers, turning what they describe into a data model, an API surface, and an interface they can actually use, then documenting it in language they can rely on long after handover.
I use AI coding tools every day, and I review and test what they produce to exactly the same standard as code I write by hand.
Based in the United States. Open to full-stack engineering roles.
-
API design that holds up
Typed request and response models, validation on ingest, and every endpoint documented in OpenAPI so the people consuming it never have to guess.
-
Front ends that match the contract
Component architecture and state management in React, with behaviour verified against the API contract before anything reaches release.
-
Security built in, not bolted on
JWT authentication, role-based access control, protected routes, session handling, audit logging, and CORS policy across both API and UI, then tested from the outside to confirm it holds.
-
Performance as a requirement
Core Web Vitals budgets, technical SEO, structured data, and accessibility treated as acceptance criteria rather than a later clean-up pass.
Process
How a project runs, start to finish
The same six steps whether it is a two week client build or a two year platform. The outputs are what you receive, not what I do internally.
-
Understand the problem, not the feature list
I start by asking what goes wrong today and who it affects. Most first requests describe a solution someone has already imagined. The useful conversation is the one underneath it.
A short written summary of the problem, agreed before any code.
-
Model the data
Entities, relationships, and the rules that must always hold. Getting this wrong is the most expensive mistake available in a project, so it comes before framework choices, not after.
A schema you can read, with the constraints written down.
-
Design the API contract
Endpoints, request and response shapes, error cases, and permissions. Typed with Pydantic and published as OpenAPI so the front end and any other consumer can build against it immediately.
A Swagger page that works before the implementation is finished.
-
Build in thin vertical slices
One real path at a time, from database through to interface, rather than a finished backend and an empty screen. You see something working early and can redirect it while that is still cheap.
Working software you can click through, every week.
-
Test, review, and harden
Automated coverage on the logic that matters, then a manual pass that tries to get at data it should not reach: another account's records through the API or storage, a role check that only runs in the interface, a price the client is trusted to send. Performance and accessibility are checked in the same pass.
A test suite, and findings ranked by severity with a fix for each.
-
Document and hand over
Runbooks, environment notes, and behaviour described in plain language. The measure of a good handover is that the next person does not need to call me.
Documentation your team can act on without me.
Review work
Going through what is already built
Not every engagement is a build. Some are a pass over an application that already exists, looking for the things that only show up when someone tries them.
-
Data isolation
Whether one account can reach another account's records through the API, the database, or file storage, and whether shared content reaches only the people it was meant for.
-
Authentication and access
Session handling, role and row-level security policies, and the server-side database functions that enforce them, tested from the outside rather than read in the source.
-
Identity verification
The sign-up and verification path end to end, including rate limiting and the abuse routes that only appear once you start trying them.
-
Payment flows
Whether the price is settled on the server rather than accepted from the client, and whether webhooks are checked by signature before anything acts on them.
-
Web and mobile
Manual and exploratory passes across both, since a mobile client usually talks to the same API with fewer of the front end's assumptions in the way.
-
A report you can act on
Findings ranked by severity, each with steps to reproduce it and a fix, and a plain verdict on whether data isolation and access control hold.
Education
Formal background
-
Master of Computer Applications
Indira Gandhi National Open University
Major project: ClinicalPilot AI
-
Bachelor of Science in Physics
Mahatma Gandhi University
Graduated with distinction
Next step
Want to talk through a specific problem?
The fastest way to find out whether I am useful to you is to describe what you are stuck on. I will tell you what I would do, whether or not you hire me to do it.
- Replies: Within two working days
- Based in: the United States
- Open to: full time, contract, remote or hybrid