A web framework that doesn’t spy on anyone.
A static-site generation framework built specifically for high-turnover local verticals. Next.js, LLM-orchestrated dynamic content, architectural zero-data-collection, performance- preserving script isolation. 95-100 mobile Lighthouse across all four categories.
Mobile performance.
Dynamic content. Privacy.
There is a structural problem with web infrastructure for small local businesses, and the entire industry has agreed to pretend it does not exist.
If you run a restaurant, an auto dealership, a clinic, a service business — your website is almost certainly built on one of three things: a template platform (Wix, Squarespace, Toast), a WordPress install, or a custom agency build. All three optimize for the same thing — getting a site live quickly using the tools developers already know — and all three force the same compromise.
Most page builders ship with embedded tracking scripts. Most modern CMSes pull data client-side, destroying Core Web Vitals on the mobile hardware your customers actually use. Most custom agency builds get compromised in the last 48 hours of the deadline. We thought this was worth solving.
One framework.
Three architectural choices.
The framework runs on Next.js but reshapes how the generation pipeline actually works. It decouples data ingestion from rendering, maintains an immutable static core, and enforces a strict zero-data-collection constraint at the architectural level. Three modules carry the load.
The Orchestration Engine
When a request hits an ungenerated content node — say, an inventory detail page for an item no one has viewed yet — the engine performs a single, isolated, server-side LLM call. The model ingests raw, unstructured specification data and synthesizes a localized semantic asset. That asset compiles directly into the static layer.
Every subsequent request for that page is served as a pre-rendered static file. No further LLM calls. No client-side fetches. Lazy generation, but deterministic and idempotent — so it runs concurrency-safe across thousands of nodes without firing duplicate webhooks or serving incomplete DOM trees.
Zero-Data-Collection Enforcement
Because content is generated server-side and persisted as static files, there is no architectural reason for the framework to know anything about the user requesting it. Dynamic third-party utilities (maps, inventory APIs) integrate through a stateless caching layer that isolates, filters, and strips tracking code before edge deployment.
No consumer data is cached, stored, or transmitted. This is not a privacy feature. It is a property of the system that exists because we built it that way from the foundation.
Performance-Preserving Script Isolation
Marketing teams want maps and tracking widgets. Compliance teams want zero tracking. Most agencies resolve this by shrugging and letting both win — which is how the average local business site ships with a dozen embedded scripts and a punishing LCP.
We resolve it with an automated rule-based optimization engine that lazy-loads heavy third-party scripts in isolation, maintaining the 95-100 Lighthouse mobile score across varying network conditions. The isolation layer simulates the runtime environment the widget expects, then filters its output.
A few things we
underestimated.
- Race conditions in lazy generation. When multiple users hit an ungenerated content node before synthesis completes, naive implementations either fire duplicate generation webhooks (waste) or serve incomplete trees (wrong). We solved it with an idempotent generation lock and a request-queuing layer — but it took several iterations to get the queue semantics right under real traffic patterns.
- Determinism under heterogeneous third-party data. Our verticals — automotive, restaurant, retail, medical — pull from wildly different data shapes. Manufacturer inventory feeds. Menu structures. Service descriptors. SKU databases. Getting deterministic, predictable generation across that heterogeneity required more abstraction layers than we initially planned.
- Stripping tracking code without breaking utility scripts. Third-party widgets ship with telemetry baked in. Removing it without breaking the widget required building an isolation layer that simulates the runtime environment the widget expects, then filters its output. This is the most technically delicate part of the system and the one we are still refining.
Questions about the framework.
Answered.
How does the LLM orchestration work?
When a request hits an ungenerated content node — say, an inventory detail page for an item no one has viewed yet — the framework performs a single, isolated, server-side LLM call. The model ingests raw, unstructured specification data and synthesizes a localized semantic asset. That asset is compiled directly into the static layer. Every subsequent request for that page is served as a pre-rendered static file. No client-side fetches, no further LLM calls.
What makes "zero-data-collection" architectural, not a feature toggle?
Most platforms market "privacy" as a checkbox the operator can disable. DARKHORSE makes privacy a structural property of the system: because content is generated server-side and persisted as static files, there is no architectural reason for the framework to know anything about the visitor requesting it. We integrate dynamic utilities (maps, inventory APIs) through a stateless caching layer that isolates, filters, and strips tracking code before edge deployment. The framework cannot leak user data because the user data never enters the framework.
Does the framework support third-party scripts like maps and analytics?
Yes — but through an automated rule-based optimization engine that lazy-loads them in isolation, maintaining the 95-100 Lighthouse mobile score. Operators get the marketing widgets they need; the privacy guarantee stays intact because the isolation layer simulates the runtime environment the widget expects, then filters its output before anything reaches the client. This is the most technically delicate part of the system and the one we are still refining.
What verticals does the framework support?
Built specifically for high-turnover local verticals: automotive dealerships, restaurants, home services, professional firms, medical and dental practices, retail, and real estate. The data shapes are wildly different — vehicle inventory feeds, menu structures, service descriptors, listing databases — so determinism across that heterogeneity required more abstraction layers than we initially planned. Active demos at /showcase/dealer, /showcase/restaurants, and /showcase/home-services.
What is the Lighthouse score target?
Verified 95-100 mobile across all four Google Lighthouse categories: Performance, Accessibility, Best Practices, and SEO. The benchmark is reproducible in Google's own PageSpeed Insights tool on any deployed page. Performance correlates with Google ranking; structured data depth correlates with AI search engine citations. Both are designed into the framework, not bolted on after.
Is the framework open source?
Not currently. The framework is operated as a service: DARKHORSE builds, deploys, and maintains client sites on the architecture. Each client owns their code, their domain, and every digital asset from day one — there is no proprietary CMS or platform lock-in. If a client migrates away later, the handover includes the full codebase. We may open-source individual modules in the future; the orchestration engine is the part most likely to stay proprietary.
Run the scan.
Verify the framework.
Every architectural claim on this page is reproducible in Google’s own PageSpeed Insights tool, on any DARKHORSE-built page, in 30 seconds.