00 / WRITING
Writing
Notes on building products — engineering, design, AI and the seams between them. Long enough to be useful, short enough to finish.
51 essays
002Engineering003Craft004Product005Systems006AI007Engineering008Craft009Product010Systems011AI
The API I wish every CMS had
Content modeling as if the frontend mattered. A look at the shape of a CMS that respects the people building on it.
The quiet case for design engineers
Why the strongest teams stop handing designs over a wall and let one person hold both the pixels and the code.
Shipping faster without shipping worse
Velocity is a design problem before it is an engineering one. Cut the decisions, not the corners.
Automating a home with local-first tools
A calmer, private smart home that keeps working when the cloud does not — and that you actually own.
Notes on building with LLMs in production
What survived contact with real users: evals, guardrails, latency budgets and the unglamorous plumbing.
The function that does one thing, named like it does
Naming is the cheapest documentation and the first thing to rot — a function whose name lies costs more than one with no name at all.
A design system is a product, not a file
Tokens are the easy part. The hard part is adoption, versioning and treating your team as the customer.
The roadmap is a list of things you're not doing
A roadmap full of everything is a roadmap that decides nothing — its real content is the long list of what you said no to.
Docker, but boring on purpose
Reproducible beats clever. A pragmatic baseline for containers that you can hand to anyone.
The eval is the spec
Before you tune a prompt or swap a model, write the test that says what good looks like — the eval is the real requirements doc.
Page 1 of 6 · 51 essays
→ / SUBSCRIBE
New essays, occasionally.
No spam. Unsubscribe whenever. Roughly one email a month.
← Back to indexionutdumitru.com