Notes from building things.
Technology, product and business — and the decisions that sit where they meet.
2026
A portfolio that refuses to make things up
This site hides a section rather than fill it with an estimate. That rule shaped its architecture more than any design decision did.
Motion should explain, not decorate
Every animation on this site had to answer one question — what does it help the reader understand? The ones that could not were cut.
The animation was on the critical path
This site's hero looked fast and measured slow. Largest Contentful Paint was waiting on the animation library. Moving one reveal from JavaScript to CSS took mobile performance from 78 to 97.
An argument is not a test
I believed this site handled reduced motion correctly because the code said so. When I finally tested it, the first test reported a bug that did not exist.
Delete the row before the file
When a record points at a stored file, the order you delete them in decides which failure you get. One of them is a few cents of wasted storage. The other is a broken image on your live site.
An empty page is worse than an outage
When this site moved its content into a database, the first version degraded gracefully to nothing. That was the worst failure mode available, because nothing looked broken.
Good systems are opinionated about the few things that matter
Flexibility everywhere is a way of never deciding. The best systems hold firm opinions in a few places and stay out of the way everywhere else.
Harden the operation before the volume arrives
Scaling is rarely a performance problem first. It is usually an operations problem that performance makes visible.
Measure the few signals that would change what you do next
Most dashboards are archives of things nobody will act on. A useful metric is one where a different number would lead to a different decision.
Ship in slices that stand on their own
A slice is not a piece of a feature. It is a small, complete thing that works in production by itself. Build in those, and a project can stop at any point and still be worth something.
Real-time 3D on the web should earn its place
WebGL can make an experience unforgettable, or make a page slow for no reason. The difference is whether the third dimension carries meaning.
Build multilingual from day one, not translated after
Translation at the end is cheap to promise and expensive to deliver. Especially with Arabic, language is an architectural decision.
Gamified learning fails when the mechanic and the lesson can be separated
Points bolted onto a quiz are not a game. If players can win without learning, they will. The teaching has to be the thing they are doing.
In mobile multiplayer, latency is a gameplay problem
Players do not experience your network architecture. They experience whether the game felt fair. That makes latency a design problem, not only an infrastructure one.
Inspection is evidence work: designing for traceability
An inspection system's output is not an opinion. It is a record someone will rely on later, sometimes adversarially. Design for that moment.
Put the AI inside the record, not beside it
An AI that produces insights nobody can act on is a dashboard. Useful automation lands inside the system of record, where work actually happens.
Metering AI is a product decision, not a billing one
Every AI feature has a variable cost per use. How you meter it shapes the product more than any prompt does.
In a marketplace, the catalogue is the product
Buyers do not experience your code. They experience your catalogue. Its quality, structure and trustworthiness are the product you are actually shipping.
A marketplace has to solve both sides before either shows up
The hardest problem in a two-sided marketplace is not the storefront. It is giving each side a reason to arrive while the other side is still empty.
Spend your innovation budget where the user can see it
Every team can afford only a few new things at once. Boring infrastructure is what pays for the interesting product.
Architecture is the list of decisions that are expensive to change
Diagrams are not architecture. Architecture is knowing which few decisions will be painful to reverse, and making those carefully.
The cheapest evidence that the problem is real
Validation is not a phase you pass. It is the habit of buying the next piece of certainty at the lowest possible price.
Understand the domain until the constraints are obvious
The first step of any build is not requirements. It is learning a domain well enough that its real constraints stop being surprising.
Decide before you build: the user, the constraint, the refusal
Most product failures are not engineering failures. They are failures to decide three things early enough to matter.
Technology, product and business are one decision, not three
Most projects that fail were decided three times by three people who never compared notes. The work is making it one decision again.