How we work
Research, develop, deliver, operate.
Four stages, one loop. What we learn from operating a system feeds the next thing we research — which is also why the building work and the security work sit in the same team rather than in two departments that meet at the handover.
The stages
What actually happens in each.
Research
We spend the first phase making the problem smaller and the constraints explicit. That means reading your systems, talking to the people who use them, and saying out loud which parts of the brief will not survive contact with reality. Scope shrinks here more often than it grows, and that is usually good news.
Develop
Short increments, each of which runs. We would rather show a narrow slice working end to end than a broad slice working in a demo. Review happens continuously and in your repository, so nobody discovers the architecture at the end.
Deliver
Delivery means your team can deploy, observe and change the system without calling us. Source, infrastructure definitions, runbook, and a session with whoever inherits it. If that is not true, we are not finished, regardless of what the schedule says.
Operate
Optional and always optional. Monitoring, support and periodic re-testing for the organisations that want it — never a dependency engineered into the handover to make leaving expensive.
Principles
The commitments behind the method.
These are the things we will not trade away for a faster delivery date, and the reason some conversations end without a proposal.
- No lock-in by designYou own the code, the data and the accounts. Our leverage is that the work is good, not that leaving is painful.
- Bad news earlyAn estimate that is slipping is reported when we notice, not at the milestone. Nobody has ever been glad to hear it later.
- Written scopeEspecially for security testing. What is in, what is out, when, and what makes us stop.
- Your data stays yoursProcessed where you decide, retained for an agreed period, deleted on schedule, and never used as a reference.
- Claims are measurableIf we say a system improved, there is a measurement behind it that you can run yourself.
- We say noTo engagements outside our competence, and to testing without proper authorisation. Both refusals protect you as much as us.
Questions
Asked often enough to answer here.
Can you build and then audit the same system?
We can, but not as an independent audit. Reviewing your own work is useful for quality and useless as assurance. Where you need an independent opinion on something we built, we will say so and help you brief another firm — and where you need an independent opinion on something someone else built, that is a normal engagement for us.
Do you work with our existing engineers or replace them?
With them, by default. The work is done in your repository, with your review process, and the goal is that your team can carry it after we leave. Teams that only receive a finished artefact tend to be unable to change it.
What languages do you work in?
English, German, French and Italian — for workshops, reports and day-to-day communication. Code, commit messages and technical documentation are in English regardless, because that is what the next engineer will expect.
How do engagements start?
With a conversation, then a short written scope covering objective, boundaries, effort and price. For security testing, the authorisation and the rules of engagement are part of that document. Work starts once it is signed, not before.
Sound like a fit?
Describe the situation in a few sentences. If we are the wrong team for it, we will say so — and usually point you at the right kind of one.