This one was genuinely hard, and we are not going to pretend otherwise. The brief was a platform that controls what a visitor is allowed to see on a page they have already loaded — not a login wall, not a paywall, but a decision made about the page itself, in the browser, in the time before anything is drawn. Everything that makes that difficult is in the last clause.
What it had to do
Five requirements, each of which rules out the obvious implementation of the other four.
- Decide before the page paints. By region, network, device or behaviour. A decision that arrives after the content has rendered has already failed — the visitor saw it.
- Notice when it is being inspected. Twenty-two signals record continuously, from a DevTools keystroke and a window-geometry probe through to an extension rewriting a native function or a bookmarklet injecting a script after load.
- Fail closed. If the gate cannot reach a decision, it withholds the page. The failure mode of a security control must never be "show everything" — and that is precisely the default behaviour of every naive implementation.
- Apply changes to visitors already on the site. An operator changing a rule should reach the people currently reading, not only the next ones to arrive, and without a reload they did not ask for.
- Be driveable by machines. A complete API, with a WordPress plugin and a Python package over it, so it fits a site that already exists rather than demanding one built around it.
Why it was difficult
Because the page has to look untouched. A control that announces itself — a flash of unstyled content, a visible delay, a layout that settles a beat late — is both a worse product and a worse control, because anyone trying to get round it now knows exactly where to look. So the hard constraint was not "make it work"; it was "make it work and leave no trace of working."
That constraint reaches everywhere. Access lists are compiled rather than shipped as raw data, so a large list stays fail-closed without a visitor downloading tens of kilobytes to find out they are on it. The hold shown while a decision is pending carries no spinner and no loading text, because the honest version of "instant" is indistinguishable from nothing happening at all. Each of those is a small decision; there are a few hundred of them, and they all had to agree.
Where it is now
The platform is live, running on the client's own infrastructure, and the company is preparing to launch it. It is Intigin, which is also why it is the one client on this page we can point you straight at.
Why this is on a Queantic page
Because the usual question from someone evaluating a small vendor is whether we are a template shop. Most of what we build is a site, and a site is the right answer most of the time. This is the other end of the range: a specification nobody had built before, delivered as a working platform with an API, two client libraries and documentation. When a solicitation asks whether we can build something that does not yet exist, this is the answer.
If you are evaluating us for a public agency, the relevant parts of this project are the ones about failure behaviour and about not surprising the people on the other end. What that looks like for an agency is set out on Queantic for public agencies.