How we work
Process
- Discovery. A call to understand the problem, followed by a written scope, timeline and fixed price or capped estimate.
- Build in small releases. Working software every week or two, in a staging environment you can see.
- Release with a way back. Every production change has a tested rollback and a backup taken first.
- Hand over. Source code, documentation and deployment steps belong to you.
AI-driven development
AI is part of how every project is built, not a feature bolted on at the end. It is why a small senior team can deliver what used to take a much larger one.
- Speed to market. AI drafts code, tests, migrations and documentation in minutes, so weeks of routine work shrink and the first working release arrives sooner.
- Accuracy. Speed alone does not make software correct. Every change is reviewed by an engineer, covered by automated tests and checked by the build pipeline before it ships.
- Efficiency. Less time on boilerplate means more on the decisions that matter: design, security and the details of your business.
- Accountability. The engineer owns the result. AI is a tool in skilled hands, not an autopilot.
How the work is split
Every project is built by an engineer and AI working as one team, with a clear division of responsibility.
The engineer decides
- Frames the problem, the constraints and what "done" means.
- Chooses the architecture and the trade-offs.
- Reads and approves every change before it merges.
- Owns security, data and every release to production.
AI does the heavy lifting
- Explores design options and flags risks early.
- Drafts code, tests, migrations and documentation.
- Searches the existing code so changes fit what is already there.
- Checks its own work: builds, runs tests and reviews diffs.
The loop
- Frame. The engineer writes down the goal, the rules and the limits.
- Draft. AI proposes a design, then builds it on a separate branch in small steps.
- Review. The engineer reads the change. Automated tests and the build must pass.
- Release. Small, reversible releases, with a backup first and a way back.
- Learn. Decisions and lessons are written down so the next change starts better informed.
Where AI does not act alone
- It does not deploy to production. A person runs every release.
- It does not change production data or database structure without explicit approval.
- It does not handle secrets, and nothing sensitive is committed to source control.
- Work happens on branches. Nothing reaches the main line until it is reviewed, deployed and confirmed.
Security
- Secrets live in a secret manager, never in source control.
- Least privilege: each service and person gets only the access the job needs.
- Customer data is isolated per tenant, and every read and write path is checked for it.
- Deletes are soft by default, so mistakes are recoverable.
- Changes are reviewed, and production access is limited and logged.
Health data and compliance
I build systems for organisations that handle protected health information. That means access control, audit trails, encryption in transit and at rest, and careful handling of exports and logs. Compliance itself is an organisational responsibility with legal and administrative parts that no software, and no vendor, can certify on its own. I will tell you plainly where the engineering ends and where your own policies and agreements begin.