Evidence, not pitch
This page is for founders and technical buyers deciding whether to trust someone with a codebase they will live in for years. It is the evidence, not the pitch.
A cross-platform app across iOS, Android, Windows and macOS, built over 14 months.
A code-intelligence tool with a CI-gated benchmark pinned to public commits, so the result reproduces.
Plus 405 test files in the Flutter app and end-to-end suites on the web work. Counted separately, because test files and test cases are not the same unit.
One Flutter codebase compiled to mobile and desktop, with a shared design system underneath.
Register of practice
Most engineering claims are unfalsifiable. These are the ones I can point at a repository, or a project, for.
01 / Practice
Not coverage for its own sake. I test the paths where failure is expensive: payment webhooks, sync reconciliation, auth boundaries, anything that touches a paid API. On the tooling project that means a benchmark regression gate in CI, so a change that makes retrieval worse fails before it merges.
Context Mesh case study →02 / Practice
Partway through the Flutter app I replaced the WebView-based editor with a native one, a large mid-project rewrite. It went out behind a tagged rollback point. The decision was right, but I did not know that with certainty in advance, and building the escape hatch cost less than being wrong without one.
Slote case study →03 / Practice
A 60-second function timeout on a hosting tier is not a surprise you hit in week three. It is a thing you architect around in week one, which is why the scraping pipeline starts a job and returns a run ID rather than blocking. Same with running costs: the client site had a target monthly bill before it had a homepage.
Trawl case study →04 / Practice
The benchmark in my tooling project ships with a disclaimer I wrote against my own results: the scripted judge cannot model how a real model degrades when an enormous context is dumped on it, so the success rate flatters the tool. The cost figure is the one to trust, and the page says so.
05 / Practice
I am usually the only developer and almost never the only person. On the PLAY Films site the visual direction sits with the designer on the project; my job is to build to their calls and say early when a layout will fight the browser or cost a second of load time. Before that I worked inside a platform team, where other developers built against my interfaces and nothing merged unread. And some of it is not code at all: that same site's domain took a run of emails with more than one hosting provider before it answered again.
PLAY Films case study →06 / Practice
Mainstream tools, documented decisions, and code in your repository. On client work every account transfers into your name at completion. The measure of a good handover is that a different developer can pick the project up without calling me, and that you are never paying me for access to your own software.
Who owns your website →07 / Practice
The Flutter app has a maintained launch-readiness document tracking every open issue by severity. Resolved rows stay in the table for two releases, so there is a history of what went wrong and why. A clean list that has forgotten its own past is not the same as a healthy project.
Contract engineering, technical co-founder conversations, and architecture reviews. Tell me what you are building and where it is currently stuck.
Replies within one business day