Enterprise

A shared planning environment for complex website programmes

On a large programme the decisions about a website end up spread across slide decks, design files, spreadsheets, documents, tickets, chat threads and somebody's notes. None of them agree, and none of them survive the handover. Scaffolds is one structured environment for the decisions themselves.

Where it fits

The work this is built for

Scaffolds came out of consulting on large website programmes, and the model still reflects that origin.

Discovery and architecture

Turning research and stakeholder input into a defensible structure, with the evidence for each decision recorded where the decision lives.

Redesign programmes

Holding the current site, the proposed structure and the reasoning for every change in one model, so the case for the redesign is auditable.

Careers and digital experience planning

Journeys that leave the website and enter external systems, which is where most candidate and customer experiences actually break.

Implementation handoff

Giving delivery the page structure, block sequence, component names and rationale as one readable file rather than a slide deck and a verbal briefing.

Collaboration and governance

What exists today, stated plainly

This section is deliberately conservative. Everything below is in the product now, and the roadmap further down is labelled as direction rather than capability.

Per project sharing

Access lives on the project itself. Owner, editor and viewer, with invitations addressed to an email so you can invite someone before they have an account.

Available now

Read only links

Projects are private by default. Switch link viewing on for one, and a stakeholder reads the whole thing with no account. Editing is never granted by a link.

Available now

Review and history

Comments on blocks, pinned notes on the canvas, a roster of contributors, and version history behind every revision-checked write.

Available now

What Scaffolds does not have yet. There is no single sign on, no formal compliance certification and no granular role based access control beyond the three roles above. If your procurement process requires any of those, say so early and we will tell you honestly where it stands rather than putting a badge on this page.

AI policy

No platform lock-in on the AI

Most enterprises have already decided which AI providers they are allowed to use, and that decision was not easy. A planning tool with its own embedded model asks you to make it again.

Scaffolds does not. It carries the structured context and owns the rules for reading a change back in. Which model does the reasoning is your choice, it can differ by team, and it can change without touching a single project.

  • Scaffolds makes no outbound call to any model; your AI connects inbound and reads, or you move the file
  • A connection is scoped to one project, only reads, and is ended in one control
  • Nothing a model sends can write to a project; a proposal waits for a person
  • Switching provider changes nothing about the model or its history

Who owns what

Scaffolds owns
The structured truth: the model, its identifiers, its revisions, its access and the rules that validate a change.
You own
The intelligence. Whichever provider your organisation approves, under your agreement with them.

Delivery model

How this usually starts

Anybody can sign up and start; that is what the published plans are for. This is how an enterprise programme usually starts instead, when there is procurement, a security review or a contract between the team and their first project.

  1. 01

    A conversation

    We talk about the programme, the decisions you need to hold and who has to review them. If Scaffolds is the wrong fit we will say so.

  2. 02

    A planning engagement

    The product is introduced inside real website planning work, so the first scaffold is a deliverable rather than a trial project.

  3. 03

    A continuing workspace

    The team keeps access to the projects it has built, available as an annual licence.

None of this is a prerequisite. If your team can simply buy a plan and get on with it, do that; the published plans are the whole product, and Enterprise exists for the programmes where an agreement has to come first.

Direction

Where this is going, without overpromising

An enterprise buyer is entitled to know the trajectory, and the status against each line is the whole point of showing it. Four of these have shipped since this list was first written, which is the only reason a roadmap is worth publishing at all.

  • Shipped

    Component inventory

    What the site is built from, counted from the component names already on blocks, marking what exists, what is new and what nobody has established yet. The first of the planning domains, and the pattern the rest follow.

  • Shipped

    Richer planning domains

    Content requirements, search intent, design tokens, accessibility requirements and technical integrations, each added as its own domain rather than bolted onto pages. All five are in the product.

  • Shipped

    Orientation

    What the product is for, what it must do and the rules it is judged against, written once where every view and every connected AI can refer to them.

  • Shipped

    Direct connection

    Claude, ChatGPT, Gemini and coding agents connect straight to a project and read it where it lives, carrying exactly the same review guarantees the export always had. This was the line that said the export step would one day disappear; it did not disappear, it became the second road.

  • Planned

    Dependency intelligence

    Relationships as real records, so "what else does this change affect" becomes a query rather than an argument.

  • Planned

    Drift detection

    Reading the repository back and showing where what was built has diverged from what was planned. Intended state against observed state.

  • Exploring

    Observations from live systems

    Analytics, search performance and content state attached to the pages and journeys they belong to, rather than a separate dashboard.

Questions

The questions procurement asks first

Answered plainly, including the ones where the answer is no. An enterprise buyer will find out either way, and finding out from us is cheaper for both of us.

Does Scaffolds support single sign on?

Not yet. Sign in today is a Google account or an email address and password through Firebase Auth, with per-project sharing by invitation. If SSO is a procurement requirement for you, tell us and we will say honestly where it sits rather than putting it on a roadmap slide.

Do you hold any compliance certifications?

No. There is no SOC 2, ISO 27001 or equivalent certification. Scaffolds holds website planning material rather than your customers' records or behavioural data, which changes the risk profile. It does hold the personal data needed to run the service, which is the account and invited member email addresses and the names people put against their comments. Neither point changes the answer to this question.

What data does Scaffolds actually hold?

The planning model: page structure, wireframe blocks, the reasoning written against them, journeys, comments and the email addresses of people invited to a project. No end-user personal data, no analytics data and no content from your live site.

Is our project data sent to an AI provider?

Not by Scaffolds. There is no model in the product and it makes no outbound call to one, which is still true now that an AI can connect to a project: the direction is inbound. Your approved AI authenticates and reads, under your agreement with that provider, and a connection is made deliberately by a project owner, is scoped to that one project, only reads, and can be ended in one control after which the credential is dead. If you would rather nothing connected at all, the export is the same model as a file and needs no connection.

Can we control who sees a project?

Yes. Every project is private by default: only the people invited to it can open it. Access is per project, with owner, editor and viewer roles and invitations addressed by email. Read-only link sharing can be switched on per project when you want a stakeholder to read without an account, and a link never grants editing. There is no finer-grained role model than those three.

What happens to our work if we stop using Scaffolds?

You export it. Every project writes out as one complete Markdown file that is readable by a person, diffable in Git and parseable by anything else. That is a permanent part of the product rather than an export button added for procurement, because portability is the reason the format exists.

How is it priced?

There are published plans bought with a card: a free tier, and paid tiers priced by how many projects a workspace holds. They are on the pricing page. Enterprise is the one that is not a number: it is invoiced against an agreement, because the terms that matter to a programme are projects, people, security review and how procurement wants to pay, and those are the conversation. Teams often start on a published plan and move to an agreement when procurement catches up.

Get in touch

Discuss an enterprise workspace

A short enquiry is enough. We are trying to understand the programme, not qualify you through a form.

We use this to reply to you. Nothing else.