Insights / Engineering journal
Write from the workbench.
Technical content should contain the details that only appear when someone has actually built, operated or repaired the system. We publish fewer articles than most agencies, and we would rather they be worth citing.
What does TechSteps publish here?
Articles based on work we have actually done: failure modes we have investigated, configurations we have had to correct, and decisions we have had to make with incomplete information. Where an article relies on a third-party fact, it cites the primary source and keeps that separate from our own observation. We do not publish keyword-driven filler, and we would rather say nothing than pad an article to a word count.
Published articles
Building SecAI: what a Linux security agent should collect, and what it should not
An agent on someone else's production server is a privileged, permanent guest. These are the constraints that shaped what ours collects and what it deliberately refuses to do.
Read the article- Search
AEO and GEO in 2026: what changed and what did not
A real channel appeared and a large amount of nonsense appeared around it. This separates the parts that are genuinely different from the parts being sold as new.
- Infrastructure
When a small business should use managed VPS support instead of self-managing
Plenty of businesses should manage their own server. This is how to work out whether yours is one of them, without anyone using fear as an argument.
- Engineering
What software production readiness actually means beyond passing CI
The gap between working and ready is where most production incidents live. A checklist of the questions a green build does not answer, and how to answer them.
- AI
How we think about AI agents with production permissions
An agent that can act on production is a security design problem before it is an AI problem. This is the permission model we build to, and the failure we design around rather than hope to avoid.
- Security
How a long-lived server backdoor can survive routine security checks
A malware scanner answers one question. It does not answer whether someone still has access. Here is the difference, where persistence hides on a Linux host, and how to decide between cleaning and rebuilding.
- Search
Why a website redesign should start with the old URL map
Redesigns lose traffic for a small number of specific reasons, and all of them are decided before launch. This is the inventory and mapping process that prevents it.
- Security
What to check after removing WordPress malware
Reinfection is not bad luck. It means the entry point is still open or persistence was left behind. Here is what to look for, in the order that preserves the evidence you need.
- Security
Cloudflare security rules that can break WordPress
The usual sequence: security is raised, something breaks, the rules get switched off entirely. Here is what actually breaks, why, and the path-specific rules that avoid it.
- Security
A production Linux server hardening checklist that will not break your application
Generic hardening scripts break things, get reverted, and leave the server less secure than a careful subset would have. This is the order we apply changes in, and why each one comes when it does.
- Infrastructure
Nginx mistakes that make WordPress slower instead of faster
Nginx is fast by default and easy to configure badly. These are the misconfigurations we find most often, what each one actually costs, and how to confirm you have it.
- Infrastructure
WordPress to VPS migration checklist for a live business site
Copying files and a database is the easy half. This is the checklist for the other half, in the order the steps have to happen, with the reasoning for each.
Editorial principle
What has to be in an article before we publish it.
Anyone can generate a thousand words about server hardening. The test we apply is whether the piece contains something you could only know by doing the work.
- 01 At least one real failure mode, configuration example or measurement
- 02 Third-party facts cited to a primary source, not an agency blog
- 03 A clear line between what we observed and what a source states
- 04 Explicit limits, including what the advice does not cover
- 05 A publication date, and an update date when it changes materially
- 06 No invented statistics, and no numbers without a method
Rather not do this yourself?
If an article describes a system you are responsible for, we can look at your specific case instead of the general one.