SiteHold
TBSCG's website archiving tool, taken out of archiving and repositioned as proof: a governed record of what a regulated firm published, and when.
- Client
- TBSCG
- Role
- Head of Product and Lead Consultant
- Timeframe
- 2026
- Sector
- Regulated content / compliance software
- years in use inside TBSCG engagements
- 20+
- retention rules mapped, UK / EU / US
- 8
- papers to leadership
- 4
- brand directions
- 4
A tool that worked
In July 2026 TBSCG had a website archiving tool called SiteVault. It grew out of more than twenty years of use inside the firm's own engagements. It captured a live site byte for byte, timestamped every page and asset, and held the record outside the CMS that produced it, so the record survived a migration, a redesign or a retirement. I was asked to review it and work out a route to market.
What it lacked was a reason for a buyer to act. It was sold as web archiving for regulated industries, with six verticals listed side by side and not one regulation named. It had no operating figures in its collateral, no named owner and no standard export format. And it was heading towards Magnolia under a name a US software company already used.
The name, then the channel
I found the name clash: a live US-registered company was already selling software under SiteVault. I took the action to resolve it, and the product became SiteHold.
The channel was settled at the same time. SiteHold existed before TBSCG's Magnolia work, so it would go to market platform-neutral, with Magnolia as one partner channel rather than its home.
No rule says archive your website
That line opens the regulation paper, and the rest of the proposition rests on it. Every obligation attaches to what a website contains, whether that is a financial promotion, a marketing communication or a substantiated claim, and almost every retention clock runs from the last use of that material rather than from its publication. That is true for the FCA, the SEC, FINRA, the MHRA and the ABPI Code.
A live website cannot produce a last-use date, because the moment a page changes the previous state is gone. A crawler cannot produce one either, because it only knows what was live when it called. SiteHold captured on publish as well as on a schedule, so it knew when a page went up and when it came down. That capability was sitting third on a feature list.
So the positioning paper proposed taking SiteHold out of archiving altogether. Archiving sits next to the free public web archives, which makes it a sensible idea with no budget line attached, and it is measured against firms that have sold nothing else for a decade. SiteHold was proof: evidence, held outside the CMS, of exactly what a regulated firm published, when it went live and when it came down. That is a governance control, and it lands beside communications retention, where the budget already sits and an accountable owner is already named. The first vertical proposed was UK financial services and insurance, where COBS 4.10.2R asks an approver for a written quarterly attestation that a live promotion has not materially changed.
Running it as a product
Four papers went to leadership: positioning, go to market, regulation and standards, and product ownership. The last of these turned every question a compliance buyer would ask into a decision with a date against it.
- Immediately. One name in the product and the collateral.
- Before the first sale. A named owner, a maintenance commitment and a standard export format.
- Within three months. A certification plan.
- Before the partner conversation. A decision on platform variants.
Certification went in a strict order. ISO/IEC 27001 came first and alone, because enterprise procurement stops deals without it and it takes six to twelve months to achieve. ISO 30301, ISO 22301 and CoreTrustSeal followed. The paper recommended leaving the trustworthy digital repository audit alone, and saying so plainly.
Variants turned out to be cheaper than they sounded. Only the publish integration and the screen behind it were specific to a platform, and crawl, store, version, difference and preview all worked against a public website, whatever produced it. So a version for another platform was one integration and one interface skin, not a second product to maintain. The cost that does scale is maintenance, because each integration inherits its platform's release cycle.
Two motions, counted separately
Bundling SiteHold into service plans was already on the table, and it was the right primary route. My position was that a direct motion had to run alongside it from the start, with its own owner, its own target list and its own number. A bundled product defends renewals, but it is capped by the size of the firm's own client base, and products sold that way tend to get folded into maintenance work.
The sequence started with existing clients, offered a fixed free period in exchange for a named quote agreed in writing before installation. LinkedIn, a page on tbscg.com and G-Cloud followed, and partner-led selling came last, once there were references to put in front of a partner.
The interface and the brand
The interface as I found it had the right structure. Overview, Sites, Jobs, Files and Preview is how a compliance user searches, so it needed styling rather than rebuilding. Colour did not separate state from trigger, so a failed capture never stood out. Raw identifiers sat under every site name, the sharing panel repeated at the foot of every screen, and the product ran on a generated hostname.
Brand round one tested four identity directions against two people: a compliance buyer who has never heard of TBSCG, and a platform partner who wants SiteHold to look native to their own product. It recommended an endorsed product brand, carrying TBSCG as its maker in words a partner can remove, and the margin direction, where the change sits beside the page, where a lawyer already looks for it. The same overview screen was drawn twice, once in SiteHold's identity and once in a partner's, and only the tokens changed.
Where it stopped
The positioning, the decision calendar and the brand recommendation went to the board as proposals.
That was the work: a product somebody owns, a roadmap a seller can show, and a decision record so the same question gets the same answer every time. That is the difference between selling a product and explaining a project.
