AI speed, with the engineering that makes it safe to ship.

Each project has a CLAUDE.md or AGENTS.md: the invariants an agent must not break, the commands that prove a change works, and the decisions already made so they are not re-litigated. A NEXT-SESSION.md hands the live state to the next session - what is deployed, what is gated, what is untested. An agent that starts cold reads those before touching anything.

Where to see it: Timber Logistic keeps a launch-day checklist separate from the backlog, because several items on it are easy to assume handled when they are not.

Every repo has a verify command - typecheck, lint, tests, build, dependency audit - and CI runs it on every push. For anything with a database, the test suite includes the security property itself: two real accounts asserting neither can read the other's rows, and the demo account calling the delete endpoint and expecting a refusal. If a guarantee matters, there is a test that would fail loudly when it stops being true.

Where to see it: FoodBoard: 193 tests. Kinetiq: 34, including the accessibility claims the README makes. Timber: a CI step that decodes every JWT in the production bundle and fails on a service key.

Agents write client code quickly, and a client that filters by owner is one omitted where clause away from leaking every tenant. So authorization lives in Postgres row-level security and Firestore rules - the client physically cannot express a cross-tenant query. That posture is what makes it safe to let an agent move fast in the UI: the blast radius of a mistake is a broken page, not an incident.

Where to see it: Timber Logistic: RLS on all 20 tables, every state change through SECURITY DEFINER procedures, no generic UPDATE policies.

Two from this month. A prerendering step for menu link previews serialised the restaurant's own description into an inline JSON-LD block; the test for it revealed that a literal </script> in a description would close the block early. And a public demo account's Delete button was hidden in the header - presentation, not a guard - until a test that actually called the RPC forced the check into the database function. Both were found by writing the assertion, not by reading the code.

Where to see it: Both fixes are single commits in FoodBoard's public history, with the reasoning in the message.

Every README has a Known limitations section written plainly, because those are the parts a reviewer should ask about. A payment integration was described as gated until the day it went live. A demo's staleness window is stated in hours. A number on this site has a date next to it. Speed with AI is only worth something if the person receiving the work can trust what they are told about it.

Where to see it: FoodBoard's README says which architectural decision I would reverse if I built it again, and why.

Every public-facing project receives a technical SEO and generative engine optimization pass appropriate to its architecture. That means crawlable HTML where a client-rendered app is not enough, route-specific titles and descriptions, canonical URLs, sitemaps, robots directives, structured data and link previews. Content is organized so both search crawlers and answer engines can identify the product, audience, capabilities and evidence without guessing from a bundle of JavaScript.

Where to see it: FoodBoard prerenders one shareable page per menu with JSON-LD and a sitemap. Clinica Naturell prerenders service routes. This portfolio publishes canonical and hreflang metadata for English, Romanian and Russian.