Guides
The long version, when the short one is not enough
Two documents that take a subject end to end rather than answering one question about it. Each sits above a cluster of shorter articles, so you can read the argument in full or go straight to the piece you needed.
What makes something a guide here
An article answers a question. A guide answers the question behind it, which usually means establishing scope before it gives advice — who this applies to, when, and on what basis. That is most of the value in subjects where the published summaries are confidently wrong about who is affected.
They are written to be read in fragments rather than linearly, which is why each one opens with a chapter index rather than a preamble. Nobody reads five thousand words on first arrival, and pretending otherwise produces a document with its useful parts buried.
We add one when a subject keeps producing the same conversation from a different angle. If four separate clients ask four different questions that all turn out to depend on the same underlying scope test, that test deserves a document rather than a paragraph repeated four times.
What none of them do is tell you that you need us. Where the honest answer to a question is that the work is not worth doing yet, or that it belongs to a different kind of supplier entirely, the guide says so in the same voice it uses for everything else.
All guides
- The EU compliance surface for a software productGDPR, the European Accessibility Act, the Cyber Resilience Act and NIS2, read for what each one actually asks of an engineering team — with the dates, the scope tests and the places teams get caught.
- A test automation strategy that survives contact with a roadmapWhat to automate, in what order, at which level, and how to stop a suite becoming the thing the team works around — written for teams who have tried this once already and got a suite they do not trust.
- Choosing and running a nearshore QA engagementHow the commercial side actually works — what drives the price, which model fits which problem, what to ask before signing, and the failure modes that have nothing to do with the day rate.
- Performance and accessibility as one workstreamThey are usually run as separate projects by separate people at separate times. They share most of their causes, most of their fixes and all of their failure mode, which is drift.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.