/* Real pages, drafted from Dylan's Notion plan and the 9/10 call — not the generic placeholder
* scaffold (Placeholder(), in site/nav.jsx) every other unbuilt destination still uses. Built
* the same way home.jsx builds the home page: real sections, the design system's own
* components, sticky notes only where something is genuinely still open — not a "this page has
* to do X" meta-description sitting above the real copy.
*
* Review codes use the same v2 note format as the homepage (see review.jsx): yellow/inert when
* nothing is outstanding, red when something still needs a decision. Platform overview (DA/DB),
* Security & trust (EA/EB), Migration & evaluation (GA/GB), Pricing & licensing (FA/FB),
* Federal/DDIL edge (KA/KB), Remote and resilient edge (LA/LB), Compare overview (OA/OB) and all
* six competitor pages (PA/PB/PC/PD, QA/QB/QC/QD, RA/RB/RC/RD, SA/SB/SC/SD, TA/TB/TC/TD,
* WA/WB/WC/WD). The Why Basalt page (CA/CB) is gone as of 15 Sept — see the note before Platform
* overview below for why, and review.jsx's own removed-CA/CB comment for the call quote.
*
* Six competitors as of the 15 Sept Triq V2 walkthrough (Dylan/Donnie/Luigi): VMware, Nutanix,
* Proxmox, Red Hat OpenShift Virtualization, HPE Morpheus, and Oracle Linux (OLVM) — replacing
* Hyper-V/Azure Local and Scale Computing/StorMagic, which they asked to drop ("not really a
* competitor in a real sense... Microsoft doesn't even talk about that workload"). Page letters
* S and T are reused for Red Hat and Oracle Linux respectively rather than renumbering every
* later code. Order follows their own tiering: VMware alone, then Nutanix and Proxmox ("our top
* two takeout targets"), then Red Hat, HPE and Oracle Linux ("everybody else").
*
* VMware and Nutanix keep the cost calculator (PC/RC — see ComparePresetCost below); Proxmox, Red
* Hat, HPE and Oracle Linux lead with the management-overhead problem instead (QC/SC/WC/TC — see
* ManagementOverheadLead below), per the same call: "I think this pricing calculator... we should
* be doing this for Nutanix and for VMware. I don't think it resonates the same for everybody
* else." Rates live in SW_PLATFORMS (widget.jsx); Nutanix, Red Hat and Oracle Linux are all
* derived estimates pending an actual client conversation, not published list prices the way
* VMware's, HPE's and Proxmox's are.
*/
/* Mike, 14 Sept: "let's not reinvent the wheel — we just need that same cost calculator put
there, set to VMware." Replaces the old blank-fields CostCompare (three empty inputs a visitor
had to fill in before seeing any number) with the same live calculator Run the numbers uses
(widget.jsx's LiveCostFlow — the inputs table plus its own "see how this number was reached"
gate, not just the bare table), seeded to this page's own competitor so a real number is
already on screen. Deliberately its own local state rather than the shared corner-widget one
(swLoad/swSave) — this section's whole point is "here's what THIS competitor costs," so it
always opens on that platform regardless of whatever a visitor was comparing on another page or
in the corner widget. firstVisit is set to mount time so "since you arrived" starts ticking from
zero on this page, same live-clock behavior as everywhere else LiveCostBox appears. */
/* Mike, 15 Sept — Triq V2 walkthrough: "I think this pricing calculator... we should be doing
this for Nutanix and for VMware. I don't think it resonates the same for everybody else."
Decision: the cost calculator stays on VMware and Nutanix — real per-core renewal shock, the
two platforms buyers are actually fleeing. Red Hat, HPE and Oracle Linux lead with the
management-plane problem instead (see ManagementOverheadLead below), since none of those
comparisons is really about the sticker price.
Mike, 16 Sept review: the calculator's own total now folds in an estimated management cost per
platform (SW_PLATFORMS' own comment, widget.jsx) rather than counting license alone — "the
total amount has to incorporate management costs." LiveCostFlow's own large-mode breakdown
sentence (widget.jsx's LiveCostBox) states the split live, so the static caveat that used to sit
here ("this still doesn't count the people and management overhead...") is gone — the number
above now does count it. That fix is also what made Proxmox's own preset calculator (while
Proxmox still had its own dedicated Compare page — see ALSO_CONSIDERING_POINTS below for where
that content lives now) honest rather than misleading: its cheap license no longer read as the
whole story.
Same-day follow-up, his own second pass: "I am not actually seeing what you employ... your
variable does not include the number of management hours per year... go out and do some
research... what the average salary, wage per hour is." The first pass had folded a flat,
invented $/server/year figure straight into the total with no hours anywhere on screen. It's
now hours x a real wage instead — LiveCostBox shows "Management hours/year" as its own row (not
just a bigger silent total), and ADMIN_HOURLY_WAGE (widget.jsx) is a real U.S. Bureau of Labor
Statistics figure, not a guess — see that file's own comment for both citations and for why the
hours-per-platform side of it still can't be sourced the same way. */
function ComparePresetCost({ platform, heading }) {
const seed = () => {
const p = SW_PLATFORMS.find(x => x.value === platform) || SW_PLATFORMS[0];
return { firstVisit: Date.now(), platform, servers: SW_DEFAULT_SERVERS, perServer: p.perServer, rate: p.rate };
};
const [state, setState] = React.useState(seed);
const [now, setNow] = React.useState(Date.now());
React.useEffect(() => {
const id = setInterval(() => setNow(Date.now()), 1000);
return () => clearInterval(id);
}, []);
return (
);
}
/* Mike, 15 Sept: the four Compare pages that don't get the calculator above lead with this
instead — the same "every incumbent needs a local control plane per cluster" doctrine the home
page now states plainly, applied to what's specifically true of each of these four. Same dark
section, same slot in the page, same centered narrow column as ComparePresetCost, so a visitor
moving between Compare pages doesn't feel a layout seam where the content actually differs. */
/* `tone` defaults to 'inverse' (dark) to match every existing call site (PF/RF/SF) unchanged.
The Compare overview's own use of this (OD, below) passes tone={null} — Mike, 17 Sept: that
instance should be light, not dark, since it's acknowledging alternatives rather than making
Basalt's own case. */
/* `illustration` is optional — only the VMware page's PF passes one (see ClassOfItsOwn,
site/diagrams-v2.jsx), so RF/SF/OD keep the original centered, text-only layout unchanged. */
/* `tightTop` is optional — Dylan, 17 Sept review call: "the cost model is above... you have to
scroll, and it looks like there's enough room to put them on the same page." Passed by the
three sections that follow a ComparePresetCost calculator directly (PE, RE, SC) once the
SectionDivider that used to sit between the two is removed, so the pair reads as one closer
block instead of two full-height sections stacked with a full scroll between them. Every other
call site is unaffected — default top padding is unchanged. */
function ManagementOverheadLead({ eyebrow, title, lead, points, tone = 'inverse', illustration, tightTop }) {
const { SectionHeader, StatRow } = DS;
const bg = tone === 'inverse' ? 'var(--surface-inverse)' : 'var(--surface-page)';
const padTop = tightTop ? '28px' : '70px';
if (illustration) {
return (
{illustration}
);
}
return (
);
}
/* Mike, 16 Sept, HourPlus call, first pass: "when they come to the VMware page... we can talk
about all of the other ones and say, by the way, we already know you're considering these
ones — go check out Proxmox, go check out Morpheus." Built that first pass as three cards
linking out to dedicated pages for each.
Mike, 17 Sept, second pass, overrules that structure: "those three pages don't even need to
exist... they just need mentions on this page." Proxmox, HPE Morpheus, and Oracle Linux (their
own former Compare pages — Q/W/T — are gone; see build_pages.py's own note) no longer get
dedicated pages at all, just a mention here, on each of the three featured pages, right where
the "someone still has to apply the STIG" narrative used to live on Proxmox's own now-deleted
page: "that's where you can have those additional management-layer conversations... you're
probably considering Proxmox, Morpheus, OLVM... and that's wonderful, because you're moving off
these incumbents, but the management layer hasn't changed." One shared constant rather than a
fourth near-identical component — this is exactly what ManagementOverheadLead already renders. */
const ALSO_CONSIDERING_POINTS = [
{ label: 'Proxmox', value: 'open-source, but still on-site', detail: 'No license fee, but someone still has to physically show up to a remote cluster, or open a VPN exception to reach it, the same control-plane-per-cluster overhead, just without a vendor support contract.' },
{ label: 'HPE Morpheus VM Essentials', value: 'the same overhead, HPE hardware only', detail: 'Per-socket pricing on top of a hardware tie, with the same per-cluster control plane every legacy hypervisor carries.' },
{ label: 'Oracle Linux (OLVM)', value: 'cheap license, same management problem', detail: 'Built on the same open-source KVM core Basalt is, but the per-cluster control plane, and the hours it takes to run, don’t go away.' },
];
/* Mike, wide-monitor review: "you need a comparison table because that is what all of the
customers are doing — they want a feature comparison table that shows they're making the right
choice." Basalt on the left, the competitor on the right, same five rows on every Compare page
so the shape is consistent from one to the next. Every cell reuses a fact already published
somewhere on the site — the competitor's own core from VirtualizationParity (site/diagrams-v2.jsx),
the licensing unit and consolidation behavior each Compare page's own StatRow already states —
rather than inventing new claims for a table that didn't exist until now. Where the site hasn't
published a specific fact about a competitor (most vendors' own inbound/outbound management
model, for instance), the cell says "Not published" rather than guessing. */
const COMPARE_FEATURES = {
vmware: {
name: 'VMware',
rows: [
{ feature: 'Licensing model', basalt: 'Flat, deployment-scoped', them: 'Per-core' },
{ feature: 'Consolidation penalty', basalt: 'None: fewer hosts costs less', them: 'Yes: renewal scales with the infrastructure' },
{ feature: 'Underlying core', basalt: 'KVM + Rust', them: 'ESXi (proprietary)' },
{ feature: 'Edge & disconnected sites', basalt: 'Built for constrained, disconnected sites', them: 'Not edge-optimized' },
{ feature: 'Support model', basalt: 'One assigned engineer, not a ticket queue', them: 'Enterprise support tiers' },
],
},
nutanix: {
name: 'Nutanix',
rows: [
{ feature: 'Licensing model', basalt: 'Flat, deployment-scoped', them: 'Per-core' },
{ feature: 'Consolidation penalty', basalt: 'None: fewer hosts costs less', them: 'Yes: renewal scales with the infrastructure' },
{ feature: 'Underlying core', basalt: 'KVM + Rust', them: 'AHV (built on KVM)' },
{ feature: 'Edge & disconnected sites', basalt: 'Built for constrained, disconnected sites', them: 'HCI-focused, not edge-optimized' },
{ feature: 'Support model', basalt: 'One assigned engineer, not a ticket queue', them: 'Vendor support tiers' },
],
},
redhat: {
name: 'Red Hat OpenShift Virtualization',
rows: [
{ feature: 'Licensing model', basalt: 'Flat, deployment-scoped', them: 'Subscription tier, priced per core pair' },
{ feature: 'Consolidation penalty', basalt: 'None: fewer hosts costs less', them: 'Yes: scales with the subscription tier' },
{ feature: 'Underlying core', basalt: 'KVM + Rust', them: 'KVM, via KubeVirt' },
{ feature: 'Edge & disconnected sites', basalt: 'Built for constrained, disconnected sites', them: 'Needs the full container-platform stack' },
{ feature: 'Support model', basalt: 'One assigned engineer, not a ticket queue', them: 'Red Hat–certified specialists required' },
],
},
};
/* Mike, 14 Sept: "we need a little bit of a visual indicator, like those green checkmarks or
the red X's or something, that show that Basalt is the leader." The design system's own
palette (ds/tokens/colors.css) has no green/red semantic colors to pull from — it's the
pumice/lapis pair used everywhere else on the site — so the mark uses that same accent
(lapis-500) for Basalt rather than inventing an off-brand green, and stone-500 (already
--text-muted's own source) for the competitor's side — white on both so the glyph itself stays
legible, rather than stone-500-on-stone-400 washing out to near-illegible gray-on-gray. Shared
by both this page's own table and the mega table below so the two read as one design language,
per Mike: "whatever design language you create applies to our other pages." */
function CmpMark({ good }) {
/* Mike, 14 Sept: "the little X's are not centered in the circle vertically... your check mark
should probably be up and over a little." The ✓/✕ Unicode glyphs sit at different optical
centers within their own em-box depending on the font's own metrics, so flexbox centering the
text line never quite centers the actual ink — worse for one glyph than the other. A drawn
SVG check/cross instead of a text glyph has a real, known geometry, so it centers exactly
the same way for both, in any font. */
return (
);
}
function CmpCell({ good, children }) {
return (
{children}
);
}
function ComparisonTable({ platform }) {
const c = COMPARE_FEATURES[platform];
const th = { textAlign: 'left', padding: '12px 16px', font: 'var(--weight-bold) 13px/1 var(--font-mono)', color: 'var(--text-muted)', borderBottom: '2px solid var(--border-ink)' };
const tdFeature = { padding: '16px', font: 'var(--weight-bold) var(--type-body)', color: 'var(--text-primary)', verticalAlign: 'top' };
const tdBasalt = { padding: '16px', font: 'var(--type-body)', color: 'var(--text-primary)', background: 'rgba(58,63,146,.06)', verticalAlign: 'top' };
const tdThem = { padding: '16px', font: 'var(--type-body)', color: 'var(--text-secondary)', verticalAlign: 'top' };
return (
Basalt
{c.name}
{c.rows.map((r, i) => (
{r.feature}
{r.basalt}
{r.them}
))}
);
}
function ComparisonSection({ platform, id }) {
const { SectionHeader } = DS;
const c = COMPARE_FEATURES[platform];
return (
);
}
/* Mike, 15 Sept — Triq V2 walkthrough: "I'm gonna remove the Why Basalt page because it is a
redundant page, and we're gonna cover this information on the home page because we think the
home page basically needs to be our pitch deck... the home page is the table of contents, it is
the skinny version of a pitch deck." What changed / what your team gets back / why the
economics differ all already have a home-page equivalent (Problem, Outcomes, ControlPlane) —
this page restated the same three arguments at greater length for no audience that doesn't
already have the home page. Gone outright, not folded in: there was nothing here that wasn't
already said, once Outcomes shrank to the same three-claim shape (see home.jsx). */
/* --------------------------------------------------------------- Platform overview (D) */
function PlatformHero() {
return (
Platform
Platform overview
A Type 1, bare-metal platform built on KVM and implemented primarily in Rust, with one
control plane and one operating model from a single node to a global footprint.
);
}
/* Mike, v5 review: no clear rule for when a section goes dark vs. light — the fix is one rule,
not a per-page judgment call: serious, technical sections (a real architecture or protocol
claim, usually paired with a technical drawing) go dark/inverse, the way BD and BE already do
on the homepage; everything else stays light. This is the platform page's own architecture
section — HostStack alongside a StatRow of the same core claims BD/BE make — so it's the
clearest case for it. */
function PlatformArchitecture() {
const { SectionHeader, StatRow } = DS;
return (
{/* Dylan, 17 Sept: "the diagram model is a little too generic... there's nothing about
the diagram model that says this is how we do things." HostStack was a stock
design-system diagram; PlatformArchitectureDiagram (site/diagrams-v2.jsx) is built
specifically to make the hyperconvergence/control-plane/agent-model claims concrete. */}
);
}
/* Mike, 16 Sept review: "the platform overview should really be the table of contents for the
rest of the pages inside of the platform mega menu... make sure the overview pages actually
give you a full overview of each one of those pages." The architecture explainer above states
the doctrine (he was explicit that stays: "I like the idea of you having an explainer... not a
problem whatsoever"), but nothing on this page previously named or linked the four detail pages
individually — a visitor had to already know they existed, via the nav. Same card-grid pattern
as CompareList below, which he pointed to as the model to match ("the comparisons overview
page... is well done"). */
function PlatformList() {
const { SectionHeader, Card } = DS;
const list = [
{ title: 'Security & trust', body: 'Outbound-only management, audit depth, and certification status stated precisely.', href: 'platform-security.html' },
{ title: 'Pricing & licensing', body: 'Deployment-scoped licensing, so consolidating does not create a new penalty.', href: 'platform-licensing.html' },
{ title: 'Migration & evaluation', body: 'Prove Basalt beside the incumbent before the organization commits to anything.', href: 'platform-migration.html' },
];
return (
{/* Mike, 17 Sept, HourPlus call: technical documentation removed for launch (confirmed
against the transcript — see build_pages.py). Down to three cards, back to the shared
three-column leverage-grid every other card grid on the site uses instead of the
16 Sept two-and-two fix (leverage-grid-2), which existed only to fit the fourth card.
Mike, later the same day, on the title this replaced ("The three pages behind this
one"): "I already told you to get rid of your placeholder copy... that doesn't make any
sense at all... you need to actually write the goddamn copy" — a title that just narrates
"here are the cards below it" is the same placeholder tic in a new spot, not a fix.
Rewritten in TDC's own voice (tdcmarketing.com/connecting-the-dots), the same read he
pointed to for Section BC. */}
Outbound-only management, audit depth measured in action types rather than logins, and a
clear line between what is held today, what is in evaluation, and what has not been
claimed: written for the CISO and the accreditor.
);
}
/* Mike, 16 Sept, HourPlus call: "make this loud and clear... really, really important" — Luigi
caught that the zero-inbound-ports claim was sitting in this StatRow at the same visual weight
as things like audit logging, which are genuinely just table stakes. Dylan's own read: "some of
this stuff is just table stakes... NIAP certification is a differentiator, the lack of holes in
the firewall is a differentiator, cryptography is a differentiator... pardoning, isolation,
availability, those are all [table stakes]." Mike's own fix, agreed on the call: split the page
into two sections instead of one flat list — What makes us special, then Table stakes — so a
reader's attention isn't spread evenly across six items that don't deserve equal weight.
The differentiators section also picks up two things Dylan asked for directly: naming NIAP as
a certification in progress (not a generic "hardened baseline"), and a real government-market
positioning statement — "we were built this way because this is what the government needs... a
large white font, built from the ground up to be deployed in the government's most secure
environments... government-grade security, commercial-grade prices." Cryptography is named as
FIPS 140-3 specifically (the actual federal standard), not "post-quantum" — Donnie's own
caution: "you need to be real careful with post-quantum." */
function SecurityClaims() {
const { SectionHeader, StatRow } = DS;
return (
{/* Web/copy director review, 21 Sept: "eyebrow describes the section's own rhetorical
job rather than stating a claim" — retitled to name the actual topic, matching every
other section kicker on the site ("The architecture," "Multi-tenancy," etc.).
Separately, the Cryptography stat's detail was a broken double negative — "not a
certificate we do not hold" logically asserts Basalt HOLDS FIPS 140-3, a specific
federal validation that requires a NIST validation number to claim honestly. Given
this StatRow's own NIAP entry is carefully hedged ("pursuing... not a generic
hardened-baseline claim"), this was very likely meant to be the same kind of hedge
and got inverted by a stray/missing "not." Fixed to state plainly that Basalt is
built to the standard, not yet formally validated to it — matching Donnie's own
caution elsewhere in this file about being "real careful" with security claims. */}
{/* Mike, 17 Sept, fifth pass: "that same exact model and diagram is on section EB...
you should replicate the size and the layout of that illustration... it doesn't make
a whole lot of sense why you wouldn't do that." This used to cap the shared drawing at
380px while the home page's own copy of it (BEV) rendered at full column width — same
SVG, two different sizes for no reason. Matches home.jsx's own plain wrapper now. */}
Prove Basalt beside your incumbent on real workloads, with the rollback story written
down before anything moves. The person proposing this is putting their own credibility on
the line: every step here has a named exit. There is no easy migration off an incumbent
this deeply embedded, and this page does not claim one. Basalt accounts for that work and
is built to support it, so you are not doing it alone.
);
}
/* Mike, 15 Sept — Triq V2 walkthrough: "if you're moving off VMware, you have to do all the work.
There is no easy migration off VMware. Does not exist... we're accounting for it, we're here
for you, we're gonna support it." The claim on this page was already "stand up alongside, not
a cutover," which never called it easy — the hero's own lead now says so explicitly instead of
leaving it implied, so a reader can't mistake the phased approach for a promise of effortless. */
/* Mike, v5 review: same dark-mode-for-technical-sections rule as Platform overview's own
architecture section — this is the evaluation sequence with its own technical drawing, so it
goes dark too. */
function MigrationSteps() {
const { SectionHeader, StatRow } = DS;
return (
);
}
function MigrationEvaluation() {
return (
);
}
/* --------------------------------------------------------------- Plan a controlled evaluation (U) */
/* Dylan, 17 Sept, first thing he flagged on the whole call: "the first thing I noticed was that
the plan controlled evaluation needs copy. Right now it's just a placeholder. Because that
plan controlled evaluation is an important button to click." This was still the generic
Placeholder scaffold (nav.jsx) — visibly a "This page is a placeholder" card — even though
it's the site's own primary call to action (every page's DecisionBand links here as CTA_SECOND)
and every Compare page's own closing CTA points at it too. Real content now, drafted from the
structure that was already sitting in build_pages.py's placeholder dict (what you tell us / what
we bring / what runs / what you keep) — not invented from nothing, just written up properly and
moved into a real page the way Migration & evaluation (G, directly above) already is. */
function EvaluationHero() {
return (
Get started
Plan a controlled evaluation
This is a scoped test, not a sales call. Basalt stands up beside your incumbent, runs real
workloads, and the rollback is written down before anything moves. You set the scope, and
you keep the findings either way.
Deployment-scoped licensing, so consolidating your infrastructure does not create a new penalty
for having become more efficient. Legible enough that a finance reviewer can model it
without a call.
);
}
/* Mike, 16 Sept, HourPlus call, Dylan: "very simple. It's $800 a year per server until you get
to 100 servers, and then you call us." Replaces the earlier "roughly 3% of the incumbent bill"
placeholder — a benchmarked-against-the-competitor story, not a real quote — with the actual,
settled number (SW_BASALT_PRICE_PER_SERVER_YEAR / SW_BASALT_SERVER_CAP, widget.jsx), which the
live calculator directly below this section already computes from. */
function PricingModel() {
const { SectionHeader, StatRow } = DS;
return (
);
}
/* Mike, wide-monitor review: "underneath that flat unlimited-use section, repeat your cost
calculator on Run the numbers, so if they're already looking at pricing and licensing, they
can just do the math right there." Same LiveCostBox (widget.jsx) Run the numbers uses, same
shared localStorage state so it's a genuine continuation rather than a second, disconnected
counter — just without that page's own multi-step email gate, since the point here is "do the
math without leaving the page," not a second lead-capture flow. */
function PricingLiveCost() {
const [state, setState] = React.useState(swLoad);
const [now, setNow] = React.useState(Date.now());
React.useEffect(() => {
const id = setInterval(() => setNow(Date.now()), 1000);
return () => clearInterval(id);
}, []);
React.useEffect(() => { swSave(state); }, [state]);
return (
Explore Basalt for government missions and commercial infrastructure.
);
}
/* Mike, 16 Sept review: "an industries overview page is... almost a table of contents for the
rest of the tabs inside of the industries pages" — same fix as Platform overview (see DC
above), and the same complaint that drove it: "our mega menus do not help us instinctually
understand the options that we have." This page used to be a single flat Placeholder list of
eight items, each carrying its own "Commercial:"/"Government:" prefix because nothing else
said which was which. Two real sections instead, Government then Commercial — matching the
mega menu's own order ("one to three to five," his own words) and dropping the per-item prefix
now that each section's own heading says it once.
Mike, 17 Sept: "you're starting to write some AI slop in your placeholders using these M
dashes" — both leads used to be "[N] environments, one operating model — from [A] to [B],"
the same em-dash-range construction back to back. Rewritten as plain sentences naming the
actual environments instead of gesturing at a spread between two extremes. */
/* Design/dev + copy director review, 21 Sept: this card list still had two of the exact phrases
Dylan's consolidated email named for removal — "a closet somewhere with some switches" and
"racks of it" — plus "Regional" hadn't picked up the "Regional & field operations" rename.
Reused the nav's own subtitle text for the latter two so this card, the mega menu, and the
footer all describe each page identically instead of drifting into their own separate phrasing. */
function IndustriesGovernment() {
const { SectionHeader, Card } = DS;
const list = [
{ title: 'Tactical / DDIL', body: 'Run tactical mission workloads in disconnected environments and across unreliable networks.', href: 'industries-government-tactical-ddil.html' },
{ title: 'Regional & field operations', body: 'Manage compute across government facilities, regional offices, and field locations.', href: 'industries-government-regional.html' },
{ title: 'Enterprise compute', body: 'Support agency workloads with centrally managed virtualization across large-scale data center environments.', href: 'industries-government-enterprise.html' },
];
return (
{/* Mike, 16 Sept, HourPlus call: "I hate the term 'denied links to data-center scale.'
That's terrible... it can't be denied links — it needs to be... from the desert to the
data center." Retitled to his own suggested phrase, which also fixed his separate
complaint about this title specifically ("the size is a very distracting large font
that isn't real") — the old phrase read badly at any size; this one just states the
actual range.
Mike/Dylan, 23 Sept call: live-edited the lead here to drop "denied-link forward site"
(the exact phrase Mike calls "terrible" above, still sitting in the sentence he replaced
it for), then reconsidered entirely: "so no paragraphs underneath our H1s... we don't
need them." Dropped rather than reworded again, on both this section and Commercial's
own below — the standalone statement was the point, per Dylan: "the statements stand
alone, right?" */}
{list.map((c, i) => (
{c.body}
))}
);
}
function IndustriesCommercial() {
const { SectionHeader, Card } = DS;
const list = [
{ title: 'Managed service providers', body: 'Reduce operational overhead by managing customer environments from one platform with dedicated access and tenant isolation.', href: 'industries-msp.html' },
{ title: 'Oil & gas', body: 'Support operational workloads across remote production sites and central facilities, even where network access is unreliable.', href: 'industries-oil-gas.html' },
{ title: 'Telecommunications', body: 'Manage widely distributed compute across network sites, edge locations, and data centers.', href: 'industries-telecommunications.html' },
{ title: 'Critical Infrastructure and Medical Industries', body: 'Keep control of your infrastructure with governed access and auditable operations.', href: 'industries-regulated.html' },
{ title: 'Enterprise virtualization', body: 'Run business workloads on your infrastructure with streamlined management and straightforward, high-value licensing.', href: 'industries-enterprise-virtualization.html' },
];
return (
{/* Mike, 16 Sept, HourPlus call: Dylan's own framing for this section — "we built a
platform so flexible and so easy, but also so scalable — that's the impressive claim."
He explicitly cautioned against leading with cost: "if you talk about cost explicitly
in your marketing, you lose a lot of your ability to differentiate yourself" — the old
"real budget" title led with exactly that. Retitled to state his own claim directly.
Mike/Dylan, 23 Sept call: "ditch the gray beneath 'flexible enough for any industry...'
I think that statement does not need a lot of reinforcement... no paragraphs underneath
our H1s... we don't need them on either one of those." Lead dropped, same as
Government's own section above, for the same reason. */}
{list.map((c, i) => (
{c.body}
))}
);
}
function IndustriesOverview() {
return (
);
}
/* -------------------------------------------------- Government: Tactical / DDIL (K) */
/* Refiled from Solutions → Federal/DDIL edge, 15 Sept — Triq V2 walkthrough: "Solutions becomes
Industries," split into Commercial and Government (see review.jsx's own IA note). Content is
unchanged; only the eyebrow and nav placement move, from Solutions to Industries → Government. */
/* Design/dev director review, 21 Sept: nav, footer, and the industries.html overview card all
say "Tactical / DDIL" per Dylan's own consolidated rename, but this page's own H1 still said
"Federal / DDIL edge" — a visitor clicking "Tactical / DDIL" in the mega menu would land on a
page that appears to have a different name. Matched to the nav label. */
function FederalHero() {
return (
Industries · Government
Tactical / DDIL
{/* Dylan Conner, 21 Sept, consolidated feedback: "Remove 'the mission owner's fear,' the
unexplained third-server reference, and the accreditation placeholder." Both this hero
and Section KB below led with that framing — rewritten to describe the actual DDIL
capability directly instead.
Mike/Dylan, 23 Sept call, on this exact page: "the design assumption here, not exception
handled later... we can delete that part. Like, everything has to be dash... these feel
like dangling sentences, conversational outtakes... it makes it frustrating to read
because the same errors keep showing up in different places." Dropped the trailing
fragment; the sentence ends clean at what the platform actually does. */}
Mission systems that keep running through denied, degraded, intermittent, or limited
connectivity.
);
}
/* Dylan Conner, 21 Sept, consolidated feedback: headline/body/points below are his verbatim
replacement. Removed the accreditation-status stat entirely (still read as a placeholder) and
kept the claim specific to loss of the MANAGEMENT link, not "the link" generally — a workload
with no network at all still has no path to a client either way. */
function FederalClaims() {
const { SectionHeader, StatRow } = DS;
return (
);
}
function FederalDdil() {
return (
);
}
/* -------------------------------------------------------- Government: Regional (L) */
/* Refiled from Solutions → Remote and resilient edge, 15 Sept — same move as Federal/DDIL above
(see that section's own note). Content unchanged; Luigi's own framing for this one on the
call: "your compute lives where your services are... a data center in a closet somewhere with
some switches." */
/* Design/dev director + copy director review, 21 Sept: this page had accumulated FIVE different
names in circulation — nav/footer "Regional & field operations", the industries.html card
"Regional", the breadcrumb "Government: Regional", this H1 "Remote and resilient edge", and a
compare-vmware.html cross-reference calling it "Remote edge". Matched the H1 to the current
nav label; the industries.html card and the compare-vmware.html cross-reference are fixed in
their own spots. */
function RemoteEdgeHero() {
return (
Industries · Government
Regional & field operations
{/* Dylan Conner, 21 Sept, consolidated feedback: "The current headline makes a limitation
the main message. Lead with resilience in a small footprint, then explain recovery
plainly." The prior hero led with "no outside witness" as the headline fact — that
detail moves out of the main pitch entirely; he said it belongs "in the technical
deployment details once the supported configuration is confirmed," which isn't
confirmed yet, so it isn't stated here at all rather than guessed at. */}
Keep essential services close to the people who depend on them, with a compact two-node
deployment built to recover when one server fails.
);
}
/* Mike, v5 review rule applied here too (see review.jsx's own LB note): technical enough — a
real architecture claim, now paired with a purpose-built drawing — to go dark/inverse like
Platform overview's and Federal/DDIL's own architecture sections, instead of staying light
with no illustration.
Dylan Conner, 21 Sept, consolidated feedback: headline/body/points below are his verbatim
replacement, leading with resilience instead of the restart limitation. */
function RemoteEdgeClaims() {
const { SectionHeader, StatRow } = DS;
return (
);
}
function RemoteEdge() {
return (
);
}
/* ---------------------------------------------------- Government: Enterprise compute (Y) */
/* Mike, 16 Sept, second pass: "you're going to have to go write the enterprise compute [...]
government page holder placeholder copy, and it's going to have to match [...] the page
structure of tactical DDIL and regional." Moves from the generic Placeholder scaffold to the
same Hero + dark Claims-with-illustration shape as Federal/DDIL (K) and Remote edge (L) above —
Luigi's own one-line rationale ("true data center, big, lots of racks") is still all the brief
this has, so the copy stays close to that line rather than inventing detail nobody has stated. */
function EnterpriseComputeHero() {
return (
Industries · Government
Enterprise compute
{/* Dylan Conner, 21 Sept, consolidated feedback: "Remove descriptions such as 'a real data
center,' 'a closet with some switches,' and 'the scale end of the same architecture.'
This page should address enterprise operational needs without restricting the customer
to one facility." Both this hero and Section YB below defined themselves by comparison
to the Tactical/DDIL and Regional pages — rewritten to stand on its own and cover
multiple data centers, not a single large one. */}
Run mission and business workloads across your data center environments, with hosts,
clusters, and virtual machines managed under one common platform.
);
}
/* Dylan Conner, 21 Sept, consolidated feedback: headline/body/points below are his verbatim
replacement. Illustration grouped into two labeled data centers (EnterpriseComputeScale) per
his note, since this page shouldn't restrict the customer to one facility. */
function EnterpriseComputeClaims() {
const { SectionHeader, StatRow } = DS;
return (
);
}
function GovernmentEnterprise() {
return (
);
}
/* --------------------------------------------------------------- Commercial: MSP (J) */
/* New, 15 Sept — Triq V2 walkthrough, Donnie's own description: "real multi-tenancy means you
have a super admin that can't see tenants' information... click through their tenants, have
one controller handle all of those individual clusters for their customers." This is the one
Industries page besides Government's two that's real content rather than a placeholder — see
review.jsx's own JB note: not yet checked against Dylan or Luigi's read of the MSP buyer, this
leans entirely on Donnie's explanation from the one call. */
/* Dylan Conner, 21 Sept, consolidated feedback, on the MSP claims section below: "Remove 'can't
see inside': customer isolation and controller visibility are different concepts." That fix
landed in MSPClaims and MSPTenancy, but this hero's own paragraph carried the identical framing
("no tenant who can see another tenant's environment") and was missed because the instruction
was scoped to a different section. Same underlying claim, same fix, applied here too. */
function MSPHero() {
return (
Industries · Commercial
Multi-tenancy for managed service providers
One Basalt controller behind every customer's clusters, with access scoped to each
tenant so provider staff and customers each work within their own boundary.
);
}
/* Mike, 16 Sept review: "you must create an illustration for multi-tenancy for managed service
providers." No drawing existed here before — just the StatRow's own words. Moved to dark/
inverse with a split layout to pair with the new MSPTenancy illustration (diagrams-v2.jsx),
the same treatment every other real architecture claim on the site gets (Platform overview,
Federal/DDIL, Remote edge) once there's a purpose-built drawing to go with it. */
/* Dylan Conner, 21 Sept, consolidated feedback: "Remove the blanket assertion that VMware cannot
support multiple tenants unless we substantiate a specific comparison." The prior version led
with an unsubstantiated VMware claim as its whole premise — replaced with headline/body/points
he supplied verbatim, framed around what Basalt does rather than what a competitor can't. */
function MSPClaims() {
const { SectionHeader, StatRow } = DS;
return (
);
}
function CommercialMSP() {
return (
);
}
/* --------------------------------------------------------------- Commercial: Oil & gas (C) */
/* Mike, 16 Sept: "oil and gas, same thing. You're going to have to create the page holder copy
for each one of these commercial ones as well as the accompanying illustration. This is
terrible work." Real first-draft content, same treatment MSP got the round before — straight
from Luigi's own rationale, not invented: "I might have oil and gas as one, where you have kind
of the same story you have at the federal DDIL style story, right? Because they have
infrastructure all over the place... they got a ton of money." Not yet reviewed by Dylan or
Donny — see review.jsx's own CA/CB notes. */
/* Dylan, 17 Sept: "that's not at all the message. The message with oil and gas has to be
about — we work where the work is... it has to be like a rugged message." The claims section
below (OilGasClaims) was already rewritten to lead with ruggedness; this hero paragraph still
had the old "distributed sites for a buyer with the budget" framing he explicitly rejected. */
function OilGasHero() {
return (
Industries · Commercial
Oil & gas
{/* Final pre-send audit, 21 Sept: Dylan's consolidated email asked specifically for
Telecommunications to drop "we don't care what's already on site" and use "supported
x86 hardware" instead of "any x86 server" — this page had the same unqualified framing
("what hardware is already on site," "whatever is already on site") and was missed
because the instruction was scoped to a different page. Same underlying claim, so same
fix, applied here too. */}
We work where the work is: a platform, a pipeline station, a refinery, regardless of
network conditions, on supported x86 hardware already in place.
{/* Dylan Conner, 23 Sept call: "I would just say something like oil and gas needs a
platform that goes to the North Sea, the desert and jungle... I would just delete
the [rest]" — cut the "doesn't need a data-center pitch" opener, another instance of
the half-thought filler he flagged repeatedly on this call. Also: "the last sentence
says Basalt still ties... I would just get rid of still." */}
{/* Dylan, 23 Sept call: "just make it a stylized oil... rig part of oil rig... pipeline
station could just be a mountain and a refinery could just be like the little factory
icon... we'll keep that Starlink one too... we'll get rid of the terminal." Terminal
dropped (3 sites, not 4); the boxes themselves are now the stylized icons the sites
list describes, so the 'mountain' and 'remote' terrain cues that used to sit under a
generic box are redundant with Pipeline station's and Refinery's own new icons and
are dropped — only Platform keeps its terrain cue, since the Starlink dish is its own
detail on top of the rig, not a stand-in for it. */}
);
}
function CommercialOilGas() {
return (
);
}
/* -------------------------------------------------------- Commercial: Telecommunications (X) */
/* Same instruction and treatment as Oil & gas above — Luigi gave both the same shape on the call:
"I might have telecommunications as another because they have infrastructure everywhere."
DistributedSiteReach is reused with telecom-specific site labels rather than redrawn, the same
way VirtualizationParity is reused across the Proxmox and Nutanix pages. */
function TelecomHero() {
return (
Industries · Commercial
Telecommunications
Infrastructure everywhere the network reaches: a core data center, a point of presence, and a
cell site, each one traditionally needing its own control plane to manage.
);
}
/* Dylan Conner, 21 Sept, consolidated feedback: "Remove 'a data center in every tower,' 'we don't
care what's already on site,' and promises that technicians never need to visit. Use 'supported
x86 hardware' instead of 'any x86 server.'" Headline/body/points are his verbatim replacement,
framed around distributed operations rather than infrastructure-everywhere hyperbole. */
function TelecomClaims() {
const { SectionHeader, StatRow } = DS;
return (
{/* Dylan, 23 Sept call: "your data center should almost certainly be a server rack...
your point of presence could be like an electrical substation looking thing... your
cell site would be like a tower with a little blinky thing on top... get rid of edge
facility" — dropped to three sites, each icon matching the site it actually is
instead of a repeated generic box. Core data center has no explicit icon override, so
it falls back to DistributedSiteReach's own default Block, which already reads as
server hardware.
Donnie, 25 Sept call: "do I just swap core data center and the pop icons?" Mike:
"put point of presence on the left, [and] core data center in the middle." Reordered
both arrays together — sites and icons are matched by index. */}
);
}
function CommercialTelecom() {
return (
);
}
/* ------------------------------------------------------- Commercial: Regulated industries (M) */
/* Same instruction as Oil & gas and Telecommunications above. Luigi's own rationale: "you might
have just enterprise, uh, sovereign data, sovereign compute under commercial, where like, hey,
look, you're in an industry like healthcare or legal where you don't trust your infrastructure
to someone else's care." Unlike the two pages above, this is a custody claim, not a distance
one — new illustration (DataCustody) rather than reusing DistributedSiteReach. */
/* Dylan, 17 Sept: "the reason they're regulated is because they have data that's sensitive, so
they have a fiduciary or statutory requirement to maintain a certain level of hygiene in their
network... they're regulated, not their data — but the value we provide is not around their
data, it's around the infrastructure the data sits on, and that's what's missing here." The
claims section below (RegulatedClaims) was already reframed around infrastructure-level
compliance standards; this hero paragraph still led with the old data-custody framing. */
/* Mike/Dylan, 23 Sept call: "I don't even know how you might call this medical, or critical
infrastructure... I'm gonna retitle regulated industries to critical infrastructure and medical
industries" — renamed everywhere the label is customer-facing (nav mega menu, footer, this hero,
the Industries overview card). Function/file/id names (RegulatedHero, industries-regulated.html,
the "M"/"MA"/"MB" review codes) are internal and untouched, the same convention the site already
uses for "Tactical / DDIL" vs. its own FederalHero/industries-government-tactical-ddil.html. */
function RegulatedHero() {
return (
Industries · Commercial
Critical Infrastructure and Medical Industries
Healthcare, legal, and anywhere else your infrastructure has to be governed with the same
rigor as the workloads running on it.
);
}
/* Dylan Conner, 21 Sept, consolidated feedback: "Remove the blanket statement that Basalt already
meets the combined NIST, FedRAMP, NIAP, and CMMC 'bar.' Any standards or certification
references need to state the specific status and scope accurately in a separate credentials
section." No such credentials section exists yet on the site — rather than fabricate specific
status/scope claims to fill it, this section drops standards references entirely and keeps to
what's actually being delivered: control, governance, and auditability. A dedicated credentials
section with accurate, scoped claims is separate follow-up work. */
function RegulatedClaims() {
const { SectionHeader, StatRow } = DS;
return (
);
}
function CommercialRegulated() {
return (
);
}
/* --------------------------------------------------- Commercial: Enterprise virtualization (N) */
/* Same instruction as the three pages above. Luigi's own description was "the generalized" catch-
all commercial case — not its own distinct architecture claim the way the other four are.
Dylan Conner, 21 Sept: reusing ControlPlaneComparison here meant this generalized page was
quietly asserting "every VMware cluster requires its own vCenter" without the comparison context
the actual VMware page provides — replaced with BasaltMultiCluster, which shows the same one-
controller/many-clusters shape without naming or asserting anything about a competitor. */
function EnterpriseVirtHero() {
return (
Industries · Commercial
Enterprise virtualization
Bring your virtualization environment under one management platform, with licensing that
doesn't multiply per host, per core, or per socket as you grow.
);
}
/* Dylan Conner, 21 Sept, consolidated feedback: "Cost is a central part of this story. Make the
licensing advantage concrete instead of saying 'a price you can afford.' Remove internal
commentary such as 'the honest pitch,' along with unsupported claims of complete feature
parity." "The honest pitch" was exactly the internally-focused artifact he opened the whole
email calling out. Headline/body/points below are his verbatim replacement; the licensing point
is grounded in the real $800/server/year figure established on the pricing page rather than a
vague affordability claim. */
function EnterpriseVirtClaims() {
const { SectionHeader, StatRow } = DS;
return (
{/* Mike, 23 Sept call: "center the tag, center of the document" — the review-mode
"Illustration NBV" tag is a plain inline span (site.css's own .rv-tab-illustration),
so it sits left-aligned under the SVG by default. Centered locally rather than
changing that shared rule, since it wasn't asked for on any other illustration. */}
);
}
function CommercialEnterpriseVirt() {
return (
Where each alternative is the better answer, and where it isn't. Nobody was foolish for
standardizing on what they standardized on. The deal changed after they had.
);
}
/* Mike, 16 Sept, HourPlus call, Dylan's own framework: "we're supposed to only have three
options: VMware, Nutanix, and Red Hat." Those three are who a buyer is actually migrating off
of, or actively evaluating against — "everybody else" (Proxmox, HPE Morpheus, Oracle Linux)
drops out of this featured list, the mega menu, the footer, and the cost calculator. Their own
pages stay live and linked from AlsoConsidering (below), not deleted — Mike: "we already know
you're considering these ones, go check them out." */
function CompareList() {
const { SectionHeader, Card } = DS;
const list = [
{ title: 'VMware', body: '“The standard. Nobody gets fired for buying it.” The bargain changed after you had standardized.', href: 'compare-vmware.html' },
/* Copy director review, 21 Sept: "93% as expensive" only reconciles against the live cost
calculator's own default numbers if it means license cost alone (37/40 core-rate ratio);
total cost including management overhead lands closer to 96%, and the calculator's own
defaults can change. "Easier to leave" is also unsubstantiated and contradicts the actual
compare-nutanix.html page's own argument (RE section: "Same controller and the same
management problem") — replaced with that page's real, supported claim instead of a
specific number that has to be re-verified every time the calculator's defaults move. */
{ title: 'Nutanix', body: '“The premium, safe, drop-in replacement”, but the same per-cluster control plane as VMware, and nearly the same total cost.', href: 'compare-nutanix.html' },
{ title: 'Red Hat OpenShift Virtualization', body: 'A credible, well-funded platform: built for container-native workloads, with virtualization added on top.', href: 'compare-red-hat.html' },
];
return (
{list.map((c, i) => (
{c.body}
Read the comparison
))}
);
}
/* Mike, wide-monitor review: "underneath OB, you need a mega table that compares all six versus
Basalt... it's gotta appear as if it can compete and has everything they need." Same five rows
and the same per-cell facts as each competitor's own table (COMPARE_FEATURES) — one wide table
instead of six separate claims invented for this page. */
/* Mike, 16 Sept, HourPlus call: three featured competitors, not six — see CompareList's own note
above. COMPARE_FEATURES itself keeps all six rows; Proxmox, HPE, and Oracle Linux's own compare
pages still render their own individual table from it (ComparisonSection below), just not this
mega table. */
function MegaComparisonTable() {
const order = ['vmware', 'nutanix', 'redhat'];
const feature = i => COMPARE_FEATURES.vmware.rows[i].feature;
const basalt = i => COMPARE_FEATURES.vmware.rows[i].basalt;
const th = { textAlign: 'left', padding: '12px 14px', font: 'var(--weight-bold) 12px/1.2 var(--font-mono)', color: 'var(--text-muted)', borderBottom: '2px solid var(--border-ink)', whiteSpace: 'nowrap' };
const tdFeature = { padding: '14px', font: 'var(--weight-bold) var(--type-body)', color: 'var(--text-primary)', verticalAlign: 'top', whiteSpace: 'nowrap' };
const tdBasalt = { padding: '14px', font: 'var(--type-body-sm, var(--type-body))', color: 'var(--text-primary)', background: 'rgba(58,63,146,.06)', verticalAlign: 'top' };
const tdThem = { padding: '14px', font: 'var(--type-body-sm, var(--type-body))', color: 'var(--text-secondary)', verticalAlign: 'top' };
return (
Basalt
{order.map(p =>
{COMPARE_FEATURES[p].name}
)}
{COMPARE_FEATURES.vmware.rows.map((_, i) => (
{feature(i)}
{basalt(i)}
{order.map(p =>
{COMPARE_FEATURES[p].rows[i].them}
)}
))}
);
}
function CompareMegaTable() {
const { SectionHeader } = DS;
return (
);
}
/* Mike, 17 Sept, HourPlus call, tentative ("I almost feel like..."): the same "considering
Proxmox, Morpheus, or OLVM" content each featured competitor page carries (PF/RF/SF) should
also live here, underneath the mega table — but in light mode, not dark, since it is
acknowledging alternatives rather than making Basalt's own case. Reuses ALSO_CONSIDERING_POINTS
rather than inventing a new secondary comparison table, since Proxmox/HPE/Oracle Linux "don't
need their own landing pages, they just need mentions" (the same reasoning that removed their
pages in the first place). */
function CompareAlsoConsidering() {
return (
);
}
function CompareOverview() {
return (
The bargain changed after you had standardized. This is what a credible, tested
alternative looks like before the next renewal.
);
}
/* Mike, wide-monitor review: same dark-mode-for-technical-sections rule as Platform overview's
own architecture section and Federal/DDIL and Remote edge below — every Compare page's own
content block now carries a real illustration (VirtualizationParity), which is exactly the
condition that rule already applies to. All six flip to inverse together, not one at a time. */
function VMwareCompare() {
const { SectionHeader, StatRow } = DS;
return (
{/* Copy director review, 21 Sept: specific unsourced numeric/behavioral claims about a
named competitor ("150-1,200%", "80% of paid features unused") are the highest-risk
claim category on the site — no citation, and this same page cites its own labor-cost
assumption to the BLS just above. Softened to the general, well-documented narrative
(renewal increases since the Broadcom acquisition are widely reported) without a
specific unverified number attached. */}
);
}
/* Mike, 16 Sept: "VMware, Nutanix, those things also have management issues as well... you're
going to have to make sure that those things are incorporated in this in each one of those
pages as well." VMware and Nutanix already carry the cost calculator's management-hours line
(PC/RC) and ControlPlaneComparison/VirtualizationParity's own control-plane-per-cluster
illustration, but — unlike Proxmox (QC) — neither had the qualitative "someone still has to
show up" story explaining what that overhead actually looks like day to day. New letter (PE)
rather than reusing one, same convention as Proxmox's own QE. Straight from Donnie's own STIG
walkthrough this call: applying a hypervisor, application, and database STIG to every single
vCenter, every year, "takes two [to] three days" each and often breaks things on top of that —
the same figure that grounds VMware's 60-hour/server/year estimate in widget.jsx's SW_PLATFORMS. */
function CompareVMware() {
return (
{/* Mike, 17 Sept, HourPlus call: "make some sort of illustration... put Proxmox, Morpheus,
OLVM on one side of a firewall, and Basalt on the other side... make it stand out that
it's in a class of its own." Only on this page (VMware) — RF/SF keep the original
text-only layout, since that's the one he was looking at when he asked for it. */}
} />
Hyperconverged at the core, and strong there. What differs at constrained, remote, and
disconnected sites, and in how the license is priced.
);
}
/* Mike, 16 Sept: same instruction as VMware's own PE, above — Nutanix needs its own "someone
still has to show up" narrative, not just the calculator's management-hours line. Straight from
Luigi this call, on Nutanix's architecture next to VMware's: "the important part of the
architecture, the controller portion, is the same — [you have] the same management problem
with Nutanix as you have [with] everybody else." Nutanix organizes storage and clustering its
own way, but the part that drives the labor overhead — a control plane per cluster — isn't
different from VMware's. New letter (RE), same convention as PE and Proxmox's own QE. */
function CompareNutanix() {
return (
);
}
/* -------------------------------------------------------------------- Compare: Red Hat (S) */
/* Mike, 15 Sept — Triq V2 walkthrough: replaces Hyper-V / Azure Local (Donnie/Luigi: "they're a
problem sometimes, but Microsoft doesn't even really talk about that too much — that's not the
workload they're chasing"). Reuses page letter S rather than renumbering every code after it.
Red Hat OpenShift Virtualization: "a very credible product offering, it's just super
complicated, super expensive... designed for cloud-native application deployment, and they're
shoehorning virtualization into it" (Luigi); "all of a sudden you need experts that understand
containerized infrastructure... you inherit all of Kubernetes' complexity into your virtual
machine infrastructure" (Donnie). No cost calculator here — see ManagementOverheadLead above. */
function RedHatHero() {
return (
Compare
Basalt vs. Red Hat OpenShift Virtualization
A genuinely capable platform, built for container-native workloads first, with
virtualization added on top. Where that complexity actually goes, and what it costs.
);
}
/* Mike, 16 Sept, HourPlus call: Red Hat joins VMware and Nutanix as the three featured
competitors ("we're supposed to only have three options: VMware, Nutanix, and Red Hat" —
Dylan). Those three are also the ones the cost calculator's own dropdown now features, so this
page gets the same live preset calculator VMware (PC) and Nutanix (RC) already have — new
letter (SE) rather than reusing one, same convention as Proxmox's own QE. */
function CompareRedHat() {
return (
);
}
/* ------------------------------------------------------------------------- Utility pages (Z) */
/* Mike, 14 Sept: "these company pages actually need their placeholder copy... right now I'm a
little bit lost on some of these things." Contact, Documentation login, Privacy, Accessibility
and Legal were all still the generic Placeholder() scaffold (nav.jsx) every unbuilt destination
uses by default — the right call for Industries overview or Technical documentation, where the
content genuinely doesn't exist yet, but these five are simple utility/legal pages a real draft
is easy to write for. Built as actual pages below instead of a meta "what this page has to do"
description. Anything that's a real company decision rather than boilerplate — the legal entity
name, actual monitored inboxes, a stated retention period — is called out as still-needed in
review.jsx (ZB/ZC/ZE/ZF/ZG) rather than invented here. */
function ContactHero() {
return (
Company
Contact
Reach the people who build and run this, without a routing form that guesses which of
them you need.
);
}
function ContactRoutes() {
const { Card, Button } = DS;
const routes = [
{ eyebrow: 'Sales & evaluation', title: 'sales@triq.tech', meta: 'the primary path',
body: 'Scoping a controlled evaluation is the fastest way in.', href: 'evaluation.html', cta: 'Plan a controlled evaluation' },
{ eyebrow: 'Technical questions', title: 'engineering@triq.tech', meta: 'architecture & integration',
body: 'Answered by people who can actually answer them, not a queue that routes back to sales.' },
{ eyebrow: 'Support', title: 'existing customers', meta: 'named escalation',
body: 'Open cases and environment status live in the customer portal.', href: 'customer-portal.html', cta: 'Customer portal' },
{ eyebrow: 'Press & partnerships', title: 'press@triq.tech', meta: 'one address, answered',
body: 'For press inquiries and partnership discussions.' },
];
return (
{routes.map((r, i) => (
{r.body}
{r.href && }
))}
);
}
function ContactPage() {
return (
);
}
/* Mike, 21 Sept: "the login button has one of those little boxes that says it's not wired and
it's a staging note. Are you nuts? You need to get rid of that." Right — a visible "Not wired /
Staging note" Card sitting next to the sign-in form was never gated behind review mode; it was
just permanent page content, exactly as visible to a real visitor as to Dylan on a review call.
The internal note tracking this (review.jsx's own ZC entry) already exists in the proper
internal-only channel. Replaced the card with the actual real-world answer to "why can't I just
sign up" — accounts are issued per organization, not self-service — which is genuine, useful,
customer-facing copy instead of an implementation caveat. */
function DocsLoginPage() {
const { SectionHeader, Input, Button, Card } = DS;
const [email, setEmail] = React.useState('');
const [password, setPassword] = React.useState('');
return (
Documentation
Sign in
Most of the documentation (architecture, the API reference) is public and needs
no account. This is only for the material that genuinely can't be: deployment
guides tied to a specific contract, and anything under an evaluation's own NDA.
Access is provisioned as part of an active evaluation or a signed contract, not
self-service. If you're evaluating Basalt or already under contract and need
access, contact us and
we'll get your team set up.
);
}
// Post-launch checklist, 25 Sept: a custom 404 instead of Cloudflare Pages' own default,
// noindexed (site/build_pages.py) since an error page has nothing worth ranking.
function NotFoundPage() {
const { Button } = DS;
return (
404
That page isn't here
The link may be out of date, or the page may have moved. Here's where to go instead.
);
}
/* Mike, 14 Sept: "combine your accessibility policy in with the privacy policy and your legal
policy — it should all be in your privacy policy." One page instead of three (was PrivacyPage,
AccessibilityPage, LegalPage as separate destinations) — none of the three was long enough to
earn its own page, and splitting them just meant three nearly-identical "draft, pending review"
headers. Footer's Accessibility/Legal links (site/nav.jsx) now jump straight to their own
section here instead of a separate URL. Kept as three distinctly reviewable blocks (ZE/ZF/ZG)
rather than one merged note, since Dylan/Donny will sign off on privacy language, an
accessibility claim, and a trademark/licensing list on very different timelines. */
function PrivacyLegalSection({ id, background, title, badges, lead, sections }) {
const { SectionHeader, Badge } = DS;
return (
{badges &&
{badges.map(b => {b})}
}
{sections.map(s => (
{s.h}
{s.p}
))}
);
}
function PrivacyPage() {
const { SectionHeader, Badge } = DS;
const privacySections = [
{ h: 'What this site collects', p: 'Standard web analytics (pages viewed, referring source, approximate location from IP), and whatever you type into a form on this site: the cost-calculator inputs, and a name and email if you request the working behind a number. Nothing is inferred beyond what you actually provide.' },
{ h: 'Why', p: 'Analytics to understand which pages are useful. Form submissions to answer the request you made with them and nothing else. Neither is sold, and neither is used to build a profile beyond this site.' },
{ h: 'Cookies', p: 'A small number of functional cookies (remembering your cost-calculator inputs between pages, whether the review overlay is on) and, if analytics is enabled, a standard analytics cookie. No third-party ad tracking.' },
{ h: 'Third parties', p: 'Named here once the actual vendors (analytics, email delivery) are chosen, not before.' },
{ h: 'Retention', p: 'Form submissions are kept as long as needed to respond to them and no policy exists yet for a stated deletion period; analytics data follows the retention window of whichever tool is chosen.' },
{ h: 'Your requests', p: 'Ask to see, correct, or delete what this site holds about you by writing to privacy@triq.tech. Answered by a person, not a form that disappears into a queue.' },
];
const accessibilitySections = [
{ h: 'The standard', p: 'This site targets WCAG 2.1, Level AA: a stated target while the site is still in staging, not a claim of certified conformance yet.' },
{ h: 'What’s handled by construction', p: 'Color contrast, focus states, and reduced-motion behavior are set once in the design system rather than per page, so they don’t drift component by component. The hand-drawn illustrations are decorative and carry a text alternative wherever they convey information StatRow or a caption doesn’t already state.' },
{ h: 'Known gaps', p: 'A full pass hasn’t happened yet: this section should name specific known issues (and a fix date for each) once one has, rather than a blanket "we’re working on it."' },
{ h: 'Reporting a barrier', p: 'Write to accessibility@triq.tech with the page and what happened. Answered by a person; if it’s a real gap, it goes on the known-gaps list above with a date, not just a thank-you.' },
];
const legalSections = [
{ h: 'Terms of use', p: 'This site and everything published on it belong to Triq Technologies. You may read and share it; you may not republish it as your own or use the competitor comparisons to imply an endorsement that wasn’t given.' },
{ h: 'Trademarks', p: 'Basalt and the Basalt mark belong to Triq Technologies. VMware, Broadcom, Nutanix, Proxmox, Red Hat, OpenShift, HPE, Morpheus, and Oracle Linux are trademarks of their respective owners, named here for comparison only, no affiliation or endorsement is implied.' },
{ h: 'Open source', p: 'Basalt is built on KVM and other open-source components. A full attribution and license list for what ships in the product belongs here once the bill of materials is finalized.' },
{ h: 'Typefaces', p: 'This site is set in TeX Gyre Adventor, licensed under the GUST Font License, and IBM Plex Mono, licensed under the SIL Open Font License 1.1.' },
];
return (