About
One engineer,
and a specific opinion about where models belong.
Code and Proof is Faizan Hasnaat. Three years building production software, most recently on two products that are live and have paying customers, plus a set of tools built to solve problems that kept recurring across client work.
That is the whole team today. It is worth saying plainly, because the alternative — implying a department that does not exist — is the single fastest way to lose a technical buyer’s trust, and they always find out on the first call.
What you get is the person who wrote the code, on the call, answering the question directly.
Checkable
Why this and not general development
The obvious business to start was a general MVP shop — auth, Stripe, CRUD, deploy, four to eight weeks. It is a real market and plenty of people make a living in it.
It was rejected for one reason that matters: that work is getting cheaper every month as coding agents get better at it, and price competition in that lane only moves in one direction.
Going back through six months of shipped work surfaced something more defensible. The same four commitments appeared in every project, across two clients and three products, without anyone planning them as a philosophy. They were just how the work got done.
Those four are the business now. Everyone can call a model. Far fewer people have shipped the system around one and watched it survive contact with real users.
The four
- 01Deterministic where it matters
- 02Every output traces to its evidence
- 03A human gate before anything irreversible
- 04It heals itself
Range, honestly stated
The wedge is AI reliability, but the underlying work is full-stack and the range is real: TypeScript and Next.js, Python with Django and Celery, Postgres and Supabase, Cloudflare Workers, Containers, Durable Objects, queues and cron. Playwright and Storybook where the front end justifies them.
That breadth matters less than it sounds. It is listed here because “can you also do the backend” comes up on most first calls, and the answer is yes — but it is not why you would hire us.
You would hire us because a system you shipped is confidently wrong somewhere and you need someone who has fixed that before.
Where this is going
The intent is a small firm rather than a permanent solo consultancy — a few engineers who work to the same four commitments, on projects where being wrong is expensive.
We are at the beginning of that. If you would rather work with an established shop of thirty people, that is a completely reasonable preference and there are good ones. If you would rather have the person who wrote it explain it to you, that is what this is.