DBETA Bones: What Our Web Platform Is, from 8.0 to 9.0

DBETA Bones is the web platform we make: the software we build and run our clients’ websites on. It started as a research question about why websites become slow, fragile and hard to interpret as they grow. That research became Bones 8.0, the version in production today, and it now continues as Bones 9.0, a next-generation platform that is in development.

Traditional web builds are often treated as visual exercises: designed in tools such as Figma, then translated into templates that look correct at launch but struggle as the system grows. Once a platform grows beyond a small number of pages, the absence of a formal architectural strategy becomes a constraint. Content rules, multilingual expansion, performance consistency and machine-readability all need a disciplined technical environment, not more templates or plugins.

That is the problem Bones was built to address. This article explains what Bones is, then follows how it has developed: what the research set out to answer, what Bones 8.0 does today, and where Bones 9.0 is heading.

What DBETA Bones Is

Bones is the platform underneath the websites we build. It is not a theme, a page builder or a plugin, and it is not a CMS you download and install. We build each client site on it as custom code, starting from an agreed structure for that organisation.

What it gives organisations

The value of Bones is not any single feature. It is two things that matter more as a website grows:

• Control over your information. Each fact, such as a service, a company detail or a review, is kept once as a structured record and reused everywhere it appears. Changes are made in one place, follow agreed rules and go live through a controlled release, so the site does not drift into several conflicting versions of the truth.
• Speed, for visitors and for change. Sites are custom code with no theme, page builder or plugin stack underneath, and caching, compression and minified assets are set up as part of the build. Because templates, content and structure are kept in separate layers, the design or a section can change without rewriting the content, and new pages follow the structure that already exists.

Neither of these is automatic. A Bones site still needs updates, maintenance and measurement, and results depend on the content and the integrations involved.

Features that come from the structure

Because content is kept as structured records rather than inside page layouts, a set of outputs is generated from the same source as the pages: Schema.org markup (JSON-LD) for each page, AIDI files that summarise the business and its content for machines, sitemaps and llms.txt. When a page changes, its structured data records the new modified date automatically. These are useful features, but they follow from the structure; they are not the reason to choose Bones on their own.

How organisations use it

Bones is available through our Bones Implementation service. Each project starts from a Structural Blueprint, which sets out what the site covers and how it fits together, and we then build the site on Bones 8.0. Your content and data belong to you; Bones itself remains DBETA’s proprietary platform, and the terms for using it are set out in each client agreement.

This website is built on Bones 8.0 too, so the pages, structured data and AIDI index behind it are generated in the way described above.

The Engineering Gap: Why Platforms Break at Scale

Most platforms struggle at scale not because the technology is poor, but because they were never designed with clear structural rules. Many tools optimise for rapid deployment; scale needs predictability, ownership and controlled change.

As platforms grow, unmanaged dependencies, duplicated logic and inconsistent templates accumulate. Performance plateaus, updates become risky, and the structure becomes harder to read for both people and machines.

The WordPress Reality

WordPress can perform well when it is run with discipline: limited plugins, a clear content model, good hosting and active technical ownership. Problems arise when it is stretched into a complex platform through a plugin-first architecture.

In those environments, responsibility is spread across third-party dependencies, update cycles introduce risk, and performance gains reach a ceiling.

Generalist Frameworks

General-purpose frameworks offer flexibility but leave architectural responsibility with the development team. Content modelling, routing conventions, structured data, content rules and discovery layers must all be designed, enforced and maintained by hand.

Bones was built to take on that work by making structure and discoverability part of the framework rather than optional add-ons.

The Research Behind Bones (2021–2024)

Between 2021 and 2024, we investigated whether a framework could deliver consistent performance, framework-level automation and structured machine-readable output without relying on a CMS platform or a plugin ecosystem.

The questions we set out to answer

• Whether deep modularity could scale without slowing the platform down
• How automation could be built into the framework rather than added later
• Whether performance could come from architecture rather than optimisation tools
• How far reliance on third-party plugins could be reduced

These questions could not be settled with off-the-shelf patterns. They took iterative experimentation, testing, failure and refactoring.

What the research produced

• A modular architecture separating sections, features and settings
• Centralised configuration and content logic
• Routing mapped to real entities
• Framework-level automation and structured data generation
• Performance-first execution with enforced constraints

Bones 8.0: The Production Version

Bones 8.0 is where that research went into production. It is the version our current client platforms run on, and the version behind this website.

The structural problems it targets

• Logic decay: content relationships become implicit and fragile.
• Performance drag: duplicated scripts and uncontrolled execution paths.
• Template drift: standards erode as templates multiply.
• Dependency risk: core behaviour relies on third-party updates.
• Operational fragility: small changes cause widespread regressions.

Bones 8.0 reduces these failure modes by setting structure, relationships and content rules at framework level rather than page by page.

Architectural Comparison

This compares typical approaches, not every project. A well-run CMS can outperform a poorly run framework.

Machine-Legible Architecture and AIDI

Bones 8.0 is designed for a discovery environment where systems need to explain what they are, how they are structured, and how their information should be read.

It does this through a focus on machine-legibility . Structured entities and relationships are generated consistently across the platform, which reduces ambiguity for search engines and other automated systems.

Bones also exposes a machine-readable interface through the AIDI data layer . It gives structured context about services, relationships and the organisation, so systems do not have to infer it from keyword patterns. We do not guarantee rankings or citations.

Bones 9.0: In Development

Bones 9.0 is the next generation of the platform. It is under active development and is not currently available as a release or a self-service download.

It builds on what Bones 8.0 taught us, with two main changes. First, Bones 9.0 is being rebuilt as an application on Laravel rather than on our own PHP core. Second, it is being designed to start from business information instead of pages: an organisation defines the types of information it manages, such as services, projects, cases, people or locations, and connects them through explicit relationships. The aim is for one source of that information to support administration, publishing, websites and machine-readable outputs, so the same facts are not maintained in several places.

Design principles we are working to

• business information comes before pages
• organisations define their own information structures
• publishing is a deliberate step, not a side effect of editing
• machine-readable information stays connected to its source
• presentation does not own business truth

What Bones 9.0 Is Being Designed to Do

Bones 9.0 is being designed as one platform for an organisation’s websites and the information behind them. The areas below describe the design direction. None of them is available as a product yet, and the detail may change as development and testing continue.

Governance

Bones 9.0 is being designed around fixed roles: Owner, Administrator, Editor, Author and Viewer. Authors are meant to prepare changes that someone with publishing rights then approves, and editors to work only on the sites assigned to them. An audit log of significant actions, single sign-on and two-step sign-in are part of the design.

Publishing

Publishing is designed as a deliberate step with clear states: draft, in review, scheduled and published. Visitors keep seeing the current version until the new one is released. Reviewers are meant to compare old and new values field by field and see which pages and feeds a change will affect, and each publication is recorded so it can be rolled back.

Content types and relationships

Administrators are meant to create their own content types, such as services, events, case studies or locations, in the admin area without writing code, either from a ready-made starting point or from a blank one. Each type has defined fields with validation, and entries are linked through named relationships, so a change to one service can show on every page that refers to it. Changes to a content type are planned to go through a reviewed change plan that lists the entries affected before anything is applied.

Website builder

Pages are designed to be assembled from ready-made, on-brand sections rather than through drag-and-drop layout. List sections fill themselves from the underlying records, and previews include drafts on desktop and mobile. The design also covers running several sites and domains from one installation, sharing the same entries, with redirects created when an address changes.

AI assistance

AI assistance is planned as an optional helper for content work: suggesting rewrites, summaries, translations and metadata. Every suggestion goes to a person and through the normal review; the AI is not designed to approve or publish anything itself. Each installation is meant to choose whether to switch it on and which provider to use, and AI assistance is separate from AIDI.

Search and AI discovery

Each content type is planned to map to a Schema.org type, with structured data added to a page only when it validates. Sitemaps and the AIDI index are designed to refresh after each publish, with administrators choosing which fields are included. As with Bones 8.0, this helps search engines and AI tools read a site; we do not guarantee rankings or citations.

Who Bones 9.0 Is Being Designed For

Enterprises and multi-site organisations

The design is aimed at heads of digital, IT and communications who run several websites and need the same information kept consistent across them: one platform, shared entries, approval steps, single sign-on and an audit trail. Both DBETA-managed and self-hosted set-ups are being considered, with content and structure exportable in a structured form. Any adoption would start with evaluation and a pilot.

Developers and agencies

For developers, Bones 9.0 is being built as a Laravel application. The design includes modules that plug into declared extension points without bypassing approvals, a content API for published entries, and webhooks for connecting other systems. For agencies, it plans separate client installations and a client sign-off flow.

Sectors

The kinds of organisation we are designing for include professional services, councils and public bodies, membership organisations, education and training, events and venues, hotels and accommodation, property and directories, and publishing and knowledge services. These are examples of intended use, not sector products that exist today.

Measurement and Validation

• Performance measured across core templates
• Change control on shared framework code
• Consistent structured data generation

Outcomes vary by content weight and the condition of the existing platform, which is why measurement comes before migration. The same applies to Bones 9.0: its capabilities will be described as available only once they have been built and validated.

Limits and Trade-Offs

DBETA Bones is not designed for every project. Small, short-lived sites with minimal structural needs may be better served by a well-maintained CMS.

Bones suits organisations where scale, longevity and structural clarity outweigh initial convenience. Projects starting today are built on Bones 8.0; Bones 9.0 is not yet an option for client work.

Next Steps: Technical Architecture Audit

If your platform is held back by performance ceilings, dependency risk or structural decay, a technical audit can show whether a framework approach is appropriate. It typically looks at:

• Template and routing structure
• Performance baselines
• Accessibility risks
• Structured data clarity
• Migration feasibility