Why WebMatrix.
1 Matrix Systems Innovations Ltd, Cardiff CF10
Abstract
We state the positioning of WebMatrix Systems against the existing vendor landscape and argue, against the prevailing taxonomy, that the integration of edge, observability and policy on a common data model is qualitatively different from any stack assembled post-hoc. We list, equally explicitly, the kinds of work we will not do, which is the part of the positioning that costs the company growth and is therefore worth writing down.
Good infrastructure does not integrate. It is the integration.
The default vendor taxonomy for web infrastructure assigns one box per problem. A CDN for content delivery. A WAF for security policy. An APM for observability. An incident-management tool for paging. The boxes do not integrate; they expose APIs and SDKs whose only honest description is that they let the operator do the integration manually, after hours, with the help of a Python script. The boxes are not designed to integrate; they are designed to be sold individually.
WebMatrix exists because the integration is the value, and because nothing in the prevailing taxonomy aligns the financial incentive of any single vendor with delivering it. A CDN vendor does not benefit from its data being trivially joinable to a competitor's WAF. An APM vendor does not benefit from its trace being citable from outside its own dashboard. The integration is, by construction, a problem the existing vendors are not trying to solve.
What the positioning forces us to do.
Positions are useful when they force decisions. The integration-first position forces three decisions that are uncomfortable, and that we make anyway:
Build the data model first.
The temptation, on a new infrastructure platform, is to ship the edge first because the edge is what the buyer can immediately see. We built the data model first. The first six months of the engineering work were spent on the OTLP-aligned model that underpins all three surfaces. It looked, externally, like nothing was happening. It is the reason the rest works.
Refuse the surface that doesn't fit.
We have, in the life of the firm so far, refused to build three surfaces that customers asked for: an analytics surface (it is not infrastructure), a CMS surface (it is not infrastructure), and a chat-ops bot surface (it is the symptom of the integration failure, not the cure). Each refusal is in the changelog.
Make the eval public.
A platform whose only proof is the marketing copy cannot, in practice, be relied on for an incident at 03:14. We publish the monthly eval — the set, the rubric, the per-incident scoresheet — even when the result is bad. The two material misses in the last six months are in the eval log. We are not curating them out.
What we will not do.
The no-list
- We will not sell our customers' traffic data. Not aggregated, not anonymised, not as a "trend report". The traffic belongs to the customer that generated it.
- We will not run a multi-tenant model that lets one customer's noisy neighbour degrade another's edge performance. Isolation is at the kernel, not at the SLA.
- We will not publish customer logos on the homepage, in collateral or in slides without explicit, written, recently re-confirmed permission. Silence is not consent.
- We will not ship features that overlap with what an existing partner vendor does well. The platform integrates; it does not annex.
- We will not run a sales motion with quotas, qualification calls, or pre-meeting handlers. The first reply is from the engineer who would do the work.
- We will not promote a release that the eval has not run against. The eval is the gate.
These positions are not concessions to a regulator; they are the conditions under which the engineering desk operates. They are the rule against which any contracted customer may, at any time, hold us. They are also — we are aware — the rule that has cost us at least two named deals in the life of the firm so far. We think the deals were the right ones to lose.
If you want to test the positioning, talk to engineering.
The positioning is, ultimately, a hypothesis. The most useful way to test it is a forty-five minute working call against your existing infrastructure: your edge, your observability surface, your most recent policy file. The engineering desk will tell you, plainly and same-day, where WebMatrix would help and where it would not. If the second list is longer, we will say so.