Building OpsGate:
operating estates as a system

OpsGate is our own product. We designed it, built it, and run it in production, which makes it the clearest available evidence of how we approach systems for other people. This is an account of the engineering decisions, not a pitch.

The problem it addresses is specific. An agency or freelancer is accountable for a set of WordPress sites they did not all build. Each site has its own plugins, its own core version, and its own drift. The operator's real question is not "is this site up" — it is "which of these needs me first, and can I prove why."

Portfolio before site

Most tooling in this space is single-site: install something, look at one dashboard. That inverts the operator's actual workflow, which starts from a list and needs an ordering.

OpsGate assesses every connected site and ranks them by score, lowest first — by urgency rather than alphabetically. The operating loop the product is built around is deliberately short: observe continuously on a schedule, understand the condition and the evidence behind it, prioritize which site needs attention first, act on what is owned by whom, and verify on the next run whether it improved.

That last step is the one that shapes the data model. Verification only works if earlier state was retained.

Authority sits server-side

The most consequential architectural decision was where truth lives.

The WordPress plugin is deliberately thin. It reads plugin, theme, and core versions and reports that inventory over an authenticated channel. It holds no canonical truth of its own, runs no outbound scanning from the customer's server, stores no administrator password, and executes nothing that OpsGate returns. Assessment, scoring, and entitlement decisions all happen server-side in OpsGate's infrastructure.

This matters for three reasons. Security: a compromised site cannot escalate, because the credential is scoped and revocable and the connector returns nothing executable. Correctness: scoring logic changes centrally, so every site is evaluated against the same current rules without a plugin update. Entitlement integrity: what a plan includes is decided by the platform, never by client-side code that a customer controls.

Evidence as a first-class object

A score on its own is a number the operator has to trust. The product's stated position is that a score without its evidence is exactly that — so every assessment retains what produced it: the findings, their timestamps, and the release that resolves them.

Two consequences follow. First, trajectory becomes visible: a site can lose a substantial number of points over a few weeks, and the sequence of runs explains the verdict in a way a current-state page cannot. Second, the operator can show a client why work was necessary, with dated evidence rather than an assertion.

Evidence retention is also where the plan tiers become an engineering constraint rather than a pricing table. History windows differ by plan, so retention is a per-account policy the storage layer enforces, not a global constant.

Scheduled and triggered work

Assessment is continuous and runs on the customer's schedule. That makes background processing the core of the system rather than an auxiliary concern: a scheduler that fans out work across the connected estate, workers that execute assessments, and results written back as durable records.

The properties that matter are the ordinary ones. Runs are idempotent, because a retried assessment must not produce a duplicate history entry. Failures are recorded as outcomes — a site that could not be reached is a finding, not a gap in the record. And the schedule is per-account, so load is distributed rather than concentrated at a single hour.

Two access modes

OpsGate supports a public assessment that needs no plugin and no account, and a connected assessment that reads the site's real inventory after pairing.

Keeping both is a product decision with architectural weight: the assessment pipeline has to accept two very different input qualities and produce comparable output. External-only signals and full inventory data are not equivalent, and the system has to be honest about which it used.

Distribution through the plugin directory

The connector is published on the WordPress.org plugin directory, which means it passes the directory’s review process and installs the way operators expect — searching for it in the WordPress admin rather than uploading a ZIP from a vendor site. A manual ZIP install remains available for sites that prefer it.

Directory distribution imposes real constraints on the design. Review favours a plugin that does little, so keeping assessment and entitlement server-side is not only a security decision but a distribution one: a thin connector that reads inventory and reports it is far easier to justify than an agent that scans, decides, and executes. The listing is public at wordpress.org/plugins/opsgate.

Pairing itself is explicit. Activating the plugin gets it onto the site; pairing exchanges a code and binds that site to an account, and only then does connected assessment begin. Installation alone creates nothing — a distinction that removes a whole class of support confusion.

Tiers as system behaviour

OpsGate ships four plans: Free, Starter, Pro, and Agency. They differ in connected sites, history retention, notification channels, and feature access — reporting formats, uptime monitoring, compliance mapping, branded reports.

Because entitlement is decided server-side, adding a tier is a policy change rather than a client release. The plugin never learns what a plan includes, so it cannot be edited into a higher one.

What it demonstrates

The patterns here are the same ones we apply in client work: authority server-side, evidence retained alongside outcomes, background execution treated as core infrastructure, and entitlement enforced where it cannot be tampered with.

OpsGate is public, so the claims are checkable. You can open the product and read the documentation directly, or see how it sits in our selected work. The workflow discipline behind it is described in AI automation in production workflows.