AuraGlass vs Building In-House
Compare buying a production Liquid Glass React system with building blur, motion, themes, accessibility, and visual QA internally.
#Build In-House When
Build in-house when the glass material is core product IP, the design team has a unique interaction model, and the engineering team can fund the long tail: tokens, CSS architecture, React APIs, accessibility states, docs, visual regression, performance budgets, SSR behavior, and release management.
This path gives maximum ownership. It also means every bug is yours: overlay stacking, contrast over media, focus traps, reduced-motion fallbacks, chart readability, mobile density, optional peer boundaries, and documentation drift.
#Use AuraGlass When
Use AuraGlass when the product needs a premium interface now and the team would rather adopt a package than build a glass system from scratch. The package supplies component APIs, style tokens, compound parts, recipes, optional-peer guidance, and docs that agents and engineers can follow.
The tradeoff is visual opinion. AuraGlass is not a blank primitive kit. It is meant to give the app a polished Liquid Glass direction quickly, then let the team tune tokens and layouts without owning the entire material engine.
import { Card } from 'aura-glass';
import { AppShell, Sidebar, TopBar } from 'aura-glass/app-shell';
import { Table } from 'aura-glass/data';
import 'aura-glass/styles.css';
type Row = { account: string; revenue: number };
const rows: Row[] = [
{ account: 'Acme', revenue: 128400 },
{ account: 'Globex', revenue: 96200 },
];
const columns = [
{ accessorKey: 'account', header: 'Account' },
{ accessorKey: 'revenue', header: 'Revenue' },
];
export function RevenueDashboard() {
return (
<AppShell.Root>
<TopBar.Root>
<TopBar.Title>Revenue command</TopBar.Title>
</TopBar.Root>
<Sidebar.Root>
<Sidebar.Nav aria-label="Main">
<Sidebar.Item href="/revenue" current>
Revenue
</Sidebar.Item>
<Sidebar.Item href="/accounts">Accounts</Sidebar.Item>
</Sidebar.Nav>
</Sidebar.Root>
<AppShell.Main>
<Card.Root>
<Card.Body>
<Table data={rows} columns={columns} caption="Revenue by account" />
</Card.Body>
</Card.Root>
</AppShell.Main>
</AppShell.Root>
);
}#Cost Comparison
A credible in-house build must budget for more than blur and rounded corners. The team needs component semantics, keyboard interaction, layout containment, portal behavior, dark mode, reduced motion, route-level performance, docs, examples, and upgrade testing.
A package adoption still needs review, but the review starts from working components and documented contracts. That is the difference between buying a product surface and starting from a visual experiment.