Velox started with a fairly ordinary afternoon of frustration. A client site needed a store locator. The obvious plugin was installed, and within a minute the admin had picked up a banner asking for a review, a second banner advertising the pro tier, and a settings screen with forty options for a job that needed four. The network tab showed calls to domains that had nothing to do with the site itself.

None of that has to be malicious. It is what can happen when a useful plugin gradually becomes a growth engine, a platform, or a bundle. Every individual addition has a rationale. Stacked together across a WordPress site running many plugins, the cost becomes harder to ignore.

That’s the constraint Velox is built inside. Each plugin does one job, ships what it needs, and tries to ask as little of you afterwards as possible. It is a narrower product than some alternatives, and that’s the trade being made on purpose.

The Approach page goes deeper into the product rules behind that decision.

I write the code, the documentation, and the replies to support messages. That’s a limitation, and I’d rather state it plainly than dress it up as a team — but it is also one reason the rules on the Approach page are practical to keep. There is no product committee pulling the software in another direction.

Velox grows out of years of working with WordPress and repeatedly running into small problems that were either underserved or solved by tools much larger than the task required. Most Velox ideas begin with something I needed on a real project and wanted in a form I would be comfortable installing myself.

When you report a problem, the person reading it is the person responsible for the plugin. There is no support routing layer. In exchange, this is not a 24-hour support operation, and I don’t want to pretend it is. Documentation therefore matters a great deal: it is the only honest way one person can support a growing number of users without turning every question into a ticket.