Engineering
Custom software development
I build systems someone else will take over and live with for years. That is a different brief from shipping something that passes acceptance – and it is decided by the architecture, the tests, and what I leave behind in the documentation and the access rights.
What I do
From architecture design to a finished system in production. Usually systems that have to keep data straight and survive the people around them changing.
- System architecture and technical design
- Implementation and integration with surrounding systems
- Test strategy and automated tests
- Review of existing code and tests
- Consulting on decisions that are hard to walk back
Deployment and operations
I treat operations as part of development, not a follow-up order. The goal is an environment you can run without a full-time specialist and whose cost you can predict.
- Infrastructure design and build
- Automated deployment and CI/CD
- Monitoring and operational oversight
- Taking over and cleaning up an inherited setup
Taking over from another supplier
A routine part of the work. First I go through the code, the dependencies, the environment and the access rights, then I tell you what is worth taking over and what is worth rebuilding – including what each path costs in time. Only then do we decide whether to go ahead.
- Review of code, dependencies and environment
- An inventory of risks and technical debt
- Moving access and accounts to your side
- A staged handover with no downtime
The independence line
Whoever I build or run software for does not get an audit from me – and the other way round. The law requires the auditor to be separate from the people who design and operate security. If I am building for you, I am on that other side, and your audit has to come from someone else.
How it works
- 01
Initial call
Get in touch with what you need solved. You do not need a finished brief – writing it is often the first part of the job. No commitment.
- 02
Scope and milestones
I confirm in writing what I will do, in which milestones and by when. Milestones are cut so that each one leaves something usable, not something half-built.
- 03
Development by milestones
I work to the agreed milestones and hand them over as they land, so you have something to look at well before the end. If something turns out to be a dead end, you hear it straight away.
- 04
Handover
The finished system, the documentation and the access rights – all on your accounts, not mine. Not depending on one person is part of the brief, not a bonus.
Something to build, or to take over?
Send me a few lines about what you are dealing with. I reply within 48 hours.