Services
Systems built end to end, in writing
One architect who designs the system, writes it, hardens it and automates it. Work runs asynchronously: a written brief in, a working deliverable out, agreed milestone by milestone. There are no standing calls, and that is the point.
Why asynchronous is better work, not a compromise
An asynchronous engagement is one where every decision, constraint and trade-off is written down at the moment it is made, instead of being spoken in a call and reconstructed later from memory. It is slower to start and faster to finish.
The practical difference is that at the end of a project you own a readable record of why the system is the way it is. Nobody has to be interviewed to find out why a decision was made, because the reasoning is in the repository next to the code that implements it. The same discipline is why every project on this site has a page explaining what was rejected and why.
It also means time zones stop mattering, which is why the work is mostly for teams in the United States, the United Kingdom and German-speaking Europe.
Four kinds of engagement
Build the platform
You need a product built and there is no engineering team to build it.
Architecture, database design, API, front end, authentication, deploy pipeline and the automation that runs it afterwards. One person from empty repository to production, which removes the layer where a specification is translated between the person who designed it and the people who write it.
ReelVance, an autonomous publishing engine with a paid console
Harden what exists
Something is already live and you do not know what it exposes.
A review of the running system, not a checklist run against the repository: authentication and session handling, API authorisation, container and host configuration, secrets, dependency surface. The output is a written report with findings ordered by exploitability, and the fixes applied if you want them applied.
AiGrow, taken from an 8 out of 10 risk posture to a 2 out of 10
Automate the work
A process runs on people repeating themselves.
The pipeline that replaces it, including the parts nobody wants to own: the retry logic, the gate that stops it publishing something wrong, the ledger that says what it did. Automation that is trusted is automation that can be audited afterwards.
Own the identity layer
Authentication is the part you cannot afford to get wrong.
OAuth 2.0 with PKCE, token rotation, refresh token reuse detection, session revocation, multi-tenant isolation. Built to a threat model that is written down, not assembled from tutorials.
How an engagement runs
- 01You send a briefWhat you are building, what already exists, what constrains it. A repository link and a paragraph is enough to start.
- 02You get a scope backWhat I would build, what I would refuse to build, the milestones, and what each one delivers. In writing, before anything is agreed.
- 03MilestonesEach one ends in something that runs and that you can check yourself. You approve a milestone before the next one starts.
- 04HandoverThe code, the deploy path, and the written record of every decision and what it cost.
What this is not
Saying what a practice does not do is more useful than another list of capabilities, so: no staff augmentation, no joining your standups, no hourly billing, and no open-ended maintenance retainers. Work is scoped and priced per milestone. If what you need is a developer inside your team every morning, the honest answer is that you need to hire one, and I will say so rather than take the engagement.
Questions
- How is an engagement priced?
- Per milestone against an agreed scope, never per hour. You get the scope and its price in writing before anything starts, and you approve each milestone before the next one begins. Hourly billing rewards the wrong thing on work like this: the value is in the decisions, not in the time spent typing.
- What if I need to talk it through?
- Everything runs in writing, including the parts that would normally be a call. In practice a written thread is a better medium for architectural decisions than a meeting, because it forces the trade-off to be stated precisely and it is still readable six months later when someone asks why the system works this way.
- Do you work with clients outside Europe?
- Yes, and asynchronous delivery is what makes it work. Because nothing depends on both parties being awake at the same time, a team in San Francisco and a team in Berlin get the same responsiveness. Most engagements are with the United States, the United Kingdom and German-speaking Europe.
- How long does it take to build a platform from scratch?
- A working system that does one thing properly is usually weeks rather than months. A cognitive operating system with dialectic chat, a persistent actor identity, a memory graph, subscriptions and admin tooling was delivered across a sequence of milestones over several months. The variable is scope, not speed, which is why the scope is agreed in writing first.
- Who owns the code?
- You do, on delivery of each milestone, along with the deploy path and the written record of the decisions behind it. Nothing is held back as leverage and there is no dependency on me to keep it running.
- Can you work alongside an existing engineering team?
- For a defined piece of work with a clear boundary, yes: an identity layer, a hardening pass, an automation pipeline. For work that requires sitting inside the team day to day, no, and the honest answer in that case is that you need to hire, not contract.
Start with a brief
Send what you are building, what exists already, and what constrains it. You get a written scope back, with the parts I would refuse to build and why.