How I work: six rules I keep on every project
If you are deciding whether to hire me, the stack matters less than how I make decisions. These are the six rules I keep on every build, each with the project that taught it to me and a link to the evidence.
On this page
A list of technologies tells you what I have used. It does not tell you what it is like to hand me a problem. This page is the second thing: six rules I keep on every build, and the project behind each one.
1. The database holds the rule
If two things must never both be true, the database enforces it, not the application code in front of it.
On Hair Crezz, a salon booking product, the promise was that two customers can never book the same slot. Checking availability and then inserting passes every test and still oversells under load. A constraint in Postgres makes the bad row impossible to write. I wrote up the four layers that go around it.
2. Store first, notify second
Anything a person sends me is written down before anything else happens to it.
The contact form on this site saves an enquiry to the database before it tries to send the notification email. If the email provider is down, the enquiry is still there. The same rule runs the payments on Kat-Katha: a donation is settled from a verified, recorded event, exactly once, not from a callback in a browser tab that may have closed. The details are here.
3. The model gets the judgement, the code gets the rest
A language model is the right tool for a decision and the wrong tool for anything that has a correct answer.
In the document-to-article pipeline I built at Fibre2Fashion, the Word file is parsed by code, the table of contents and its anchors come from one source so they cannot disagree, and the model is only asked to write. In the news-discovery agent, the system finds and drafts and an editor still chooses which stories are pursued. I explain the reasoning in Don't ask the model to keep two things in sync.
4. Measure before fixing
I do not optimise by instinct. I find the number, change one thing, and read the number again.
This site's home page was painting its headline 2.5 seconds after the HTML arrived. The cause was one file that nobody would have guessed, and removing it brought that down to 0.2 seconds. Nothing about that file looked slow; only the measurement pointed at it.
5. Ship with the gates on
Quality is checked by a machine on every change, not remembered by a person.
Every push to this site is linted, type-checked, built and audited for accessibility, and the build fails on a single WCAG 2.1 AA violation at desktop, tablet or phone width. The site also builds and runs with no secrets at all, with each integration degrading to a sensible fallback, so a missing key is never the reason a deploy breaks.
6. The change and its explanation ship together
Code that works but that only I can maintain is a liability I have handed to my client.
A fix goes in with the reason it was needed, written where the next developer will look. Where something cost real time to find, it is recorded as what it looked like and what it turned out to be, so nobody pays for that discovery twice.
What this means if we work together
You get a written scope and a fixed price before work starts, after a free 30-minute call to find out whether I am the right person. A typical product goes from kickoff to a live URL in three to six weeks, and an AI feature into an existing product in one to three.
You also get someone who will tell you when the simple version is the right one. Most of these rules are about not building things: not a queue where a constraint will do, not a model where a parser will do, not a rewrite where a measurement shows one line is at fault.
If that is how you would like your project built, send me a message. I read every one, and reply personally, usually within 24 hours.
Frequently asked questions
- How long does a typical project take?
- A typical SaaS MVP goes from kickoff to a live URL in three to six weeks. An AI integration into an existing product lands in one to three weeks, depending on the data and how much of the product it touches.
- How do projects start?
- With a free 30-minute discovery call. Scopes are written down and priced as a fixed amount before work begins, so you know what you are buying. Messages get a personal reply, usually within 24 hours.
- Do you work alone or in a team?
- Both. The two AI systems at my day job were built end to end on my own, and the TexPro dashboard rebuild is shared between three developers. For freelance work you talk to me directly.
- Where are you based, and do you work remotely?
- I am based in Ahmedabad, India, and work fully remote for freelance clients. For full-time roles I am open to remote-first or hybrid teams.
A payment can succeed and still go wrong: a dropped webhook, a replayed one, a signature nobody checked. Here is how I verify them, settle exactly once, and keep a ledger I can reconcile against months later.
ReadCheck-then-insert reads as correct and oversells anyway, because two requests can both pass the check before either writes. The fix is layered, and the database does almost all of the work.
Read