Principles, with receipts
How I work
I am a ai full-stack engineer who has spent my career as an early engineer on small teams: Marxx.ai today and Recur Club before it, owning systems end to end. These are the principles I build by. Each one links to a place you can check it in real code.
01
Make the wrong thing hard to write
Most security bugs are one forgotten line. I would rather design so that line is awkward or impossible to write than rely on remembering it.
In practice
AdmitDesk's services only accept a tenant from a verified token, and its repositories put the tenant in every query instead of using id-only ORM calls. That second part is still a convention, which is why database-level row security is next.
See it: Make the wrong thing hard to write02
Remove the capability instead of trusting the behaviour
If something must never happen, the strongest control is making it impossible, not asking a component nicely.
In practice
The AdmitDesk agent has no tools and no write path, so a prompt injection can only produce a wrong answer. In the rate limiter, check keys cannot raise their own limits.
See it: Remove the capability instead of trusting the behaviour03
Decide what failure means before it happens
Every dependency will be down at some point. The design question is which direction to fail, and the answer depends on what being wrong costs.
In practice
The rate limiter fails closed with a 503, because an accidental allow is the expensive mistake. AdmitDesk's own sign-in limiter fails open, because a non-critical dependency should not lock applicants out. Same question, opposite answers.
See it: Decide what failure means before it happens04
Let code compute facts, and let models phrase them
LLMs are good at explaining things and unreliable at counting them. Anything with a right answer gets computed in code first.
In practice
AdmitDesk computes which documents are missing in code and hands the result to the agent as fact, so the agent and the status page never disagree.
See it: Let code compute facts, and let models phrase them05
Write decisions down, including what I rejected
A decision without its alternatives is hard to revisit. Recording what was ruled out, and why, is what lets the next person change it safely.
In practice
The rate limiter's design records name the options it rejected: in-memory counters, Postgres row locks and Redis WATCH/MULTI, each with the reason.
See it: Write decisions down, including what I rejected06
Publish where it breaks
A benchmark that only shows the passing tiers tells you nothing about the edge. I would rather show the failure and say what I do not know yet.
In practice
The rate limiter's results keep the 5,000 req/s run, where one instance fell over with 31.9% errors, next to the 1.33 ms p95 at 2,000 req/s.
See it: Publish where it breaks07
Leave it empty rather than make it up
Missing data is honest; invented data is a bug that looks like a feature.
In practice
Musafir's place catalogue only uses attributable sources. If a source does not have a value, the field stays empty, even though that keeps photo coverage at 47%.
See it: Leave it empty rather than make it up08
One code path from laptop to production
Every dev-only shortcut is a second system that production never exercises, and that is where "works on my machine" starts.
In practice
AdmitDesk has no local-disk storage driver and no separate local database, on purpose.
See it: One code path from laptop to production09
Cheap by default
Early products die of complexity and cost long before they die of scale. I pick the smallest setup that is correct, and write down when to grow it.
In practice
The rate limiter runs for $0 a month. AdmitDesk became one app instead of two so free-tier cold starts would not hurt users. Musafir's route matching carries a note saying exactly when to rewrite it.
See it: Cheap by default