Nine days ago, we had zero internal web apps. Today we have 53 — live, deployed, backed by a real database, sharing a unified design system. No React. No Next.js. No webpack. No frontend team. Just one engineer, an AI agent called Alpha Agent, and a deliberate bet on radical simplicity.

This is the story of how that happened, what the architecture looks like, and why we think this model is the future of internal tooling.

The Problem: Internal Tools Are Everyone's Last Priority

Every engineering org has the same dirty secret: internal tools are terrible. The meeting notes app is a Google Doc. The client health dashboard is a spreadsheet. Sprint planning lives in someone's head. Sales tracking is vibes.

Nobody builds internal tools because the ROI math never pencils out. A "real" React app with CI/CD, tests, and a design system takes a frontend team weeks to ship — for an audience of maybe 20 people. So teams do without, and institutional knowledge lives in Slack threads and tribal memory.

We decided to solve this differently. What if the cost of building an internal app was effectively zero?

The Bet: Static HTML + Web Components + AI

Our thesis was simple: if an AI agent can scaffold, build, and maintain apps using a shared component library, the marginal cost of each new app drops to near-zero. But to make that work, we needed constraints:

• No build step. Every app is plain HTML, CSS, and JavaScript. No transpilers, no bundlers, no node_modules.
• Shared design system. A single theme.css file (imported via relative path) provides dark/light mode, glass morphism, typography, spacing — everything. Change it once, every app updates.
• Web components for reuse. Instead of a React component library, we built a library of 59 custom elements — <cc-card>, <cc-nav>, <cc-hero>, <cc-stat-card>, <cc-tabs>, and more — that work in any HTML page with a single script include.
• Supabase for data. Every app that needs persistence connects to the same Supabase instance. Auth, row-level security, and real-time subscriptions come free.
• Alpha Agent does the work. The AI agent handles scaffolding, coding, testing, deploying, and even nightly code reviews.

The Architecture in Detail

File Structure

Every app lives in ~/apps/<app-name>/ and is served at https://<app-name>.adam-harris.alphaclaw.app. The structure is dead simple:

apps/
├── shared/
│   ├── theme.css              # Global design tokens
│   ├── components/            # 59 web components
│   │   ├── cc-card.js
│   │   ├── cc-nav.js
│   │   ├── cc-hero.js
│   │   ├── cc-stat-card.js
│   │   ├── cc-tabs.js
│   │   ├── cc-modal.js
│   │   ├── cc-sidebar.js
│   │   └── ... (59 total)
│   ├── supabase-client.js     # Shared DB client
│   └── app-tracker.js         # Usage analytics
├── daily-updates/
│   └── index.html
├── sprint-planning/
│   └── index.html
├── client-scorecard/
│   └── index.html
└── ... (53 apps total)

The Shared Component Library

59 web components cover everything from layout primitives to full interactive patterns:

Every component uses Shadow DOM for style isolation, observes data-theme for automatic dark/light mode switching, and inherits design tokens from theme.css. No configuration required.

The Design System: theme.css

One CSS file. 30 design tokens. Dark mode by default, light mode via data-theme="light". Glass morphism aesthetic with amber accents. It covers backgrounds, cards, borders, text colors, accent gradients, shadows, and typography — everything an app needs to look cohesive on day one.

The key insight: by keeping the design system outside the components (as CSS custom properties), we can retheme every app in the fleet by editing a single file. We've done this twice already — adjusting the accent color and glass opacity — and all 53 apps updated instantly.

Supabase Backend

A shared supabase-client.js provides authenticated access to our Supabase instance. Each app that needs data gets its own table(s) with row-level security. The agent creates migrations, sets up RLS policies, and wires the frontend to the API — all in one pass.

Apps with database backing include: daily standup updates, meeting summaries, sprint planning boards, client scorecards, sales pipeline, lead management, user directories, recipe collections, travel logs, and more.

The 53 Apps

Here's a sampling of what got built — every one of these is live and in use:

Operations & Management

• command-center — Central dashboard linking to every app, with status monitoring
• daily-updates — Team standup log with Supabase persistence and Slack integration
• sprint-planning — Sprint board with story points, assignments, and velocity tracking
• standup — Quick-entry daily standup notes
• meeting-summaries — AI-processed meeting transcripts with action items
• uptime — Service health monitoring dashboard

Client & Sales

• client-scorecard — Client health scoring with trend analysis
• accounts — Account overview with contract details and contacts
• sales — Pipeline tracker with deal stages and forecasting
• cc-leads — Lead capture and qualification workflow
• sentiment — Client sentiment analysis across communication channels

Engineering & Architecture

• cc-architecture — System architecture documentation with Mermaid diagrams
• cc-pr-review — AI-assisted pull request reviews with GitHub integration
• cc-ai-scripts — Catalog of AI automation scripts
• cc-contentful — Contentful CMS management interface
• lighthouse — Lighthouse performance audits across all apps
• ux-review — UX audit tracking and improvement suggestions

Team & Culture

• superstars — Team recognition and kudos board
• cc-team-usf — Team directory for USF collaborators
• cc-concerts — Team concert/event calendar
• cc-recipes — Shared recipe collection (yes, really)
• dad-joke-of-the-day — Exactly what it sounds like
• cc-meme-generator — Because morale matters

Content & Fun

• gen-alpha through gen-silent — Six generational culture guides
• slang-translator — Translate between generational slang
• cringe-rizzler — Gen Alpha slang decoder
• age-of-apes — Team-built game
• roblox-dances — Dance move reference guide (for the parents)
• proper-wine-pour — A wine education app
• soccer-training — Youth soccer drill library

How Alpha Agent Builds an App

When a new app is requested — whether by a team member in Slack or through a scheduled task — the agent follows a consistent workflow:

1. Scaffold. Create the directory, generate index.html with the shared theme and component imports.
2. Build. Write the app-specific HTML, JavaScript, and any custom styles. Pull in the right <cc-*> components.
3. Database (if needed). Create Supabase tables, set up RLS policies, wire the frontend to the API.
4. Deploy. The app is instantly live at <app-name>.adam-harris.alphaclaw.app — no CI/CD pipeline, no deploy step. Static hosting means the file system is the deployment.
5. Register. Add the app to the central registry so it appears in the command center.

Total time from request to live URL: 5–15 minutes for a typical app. Complex apps with database integration and multiple pages take 20–30 minutes.

The Nightly Code Review

Every night, Alpha Agent runs an automated review across all 53 apps. It checks for:

• Broken links and missing assets
• Console errors in headless browser tests
• Accessibility issues (contrast ratios, ARIA labels, semantic HTML)
• Component version drift (are all apps using the latest shared components?)
• Security issues (exposed API keys, XSS vectors)
• Performance regressions (file sizes, load times)

Issues get logged, prioritized, and — in many cases — auto-fixed. The agent commits the fixes with detailed messages explaining what changed and why. When a fix requires human judgment, it creates a summary in the daily updates.

Why Not React? Why Not a "Real" Framework?

We get this question a lot. The answer is pragmatic:

• AI agents are better at generating vanilla HTML than React. No JSX compilation, no hook dependency arrays, no state management libraries. The gap between what the agent writes and what runs in the browser is zero.
• No build step means instant deploys. Write a file, it's live. No CI pipeline, no build cache invalidation, no "works locally but fails in CI."
• Web components are native. They work in every browser without polyfills or transpilation. They'll work in 10 years. Try saying that about your React version.
• The apps are internal. We don't need SSR, SEO optimization, or complex client-side routing. A single index.html per app is the right level of complexity.

This isn't an argument against React for customer-facing products — that's a different conversation. For internal tools, the simplicity advantage of static HTML is massive, especially when an AI agent is doing the writing.

The Numbers

What We Learned

1. Constraints enable velocity

The decision to use static HTML and web components felt limiting at first. In practice, it's what made the 53-app velocity possible. Every constraint we added (no build step, shared theme, component library) removed a decision the agent had to make and a failure mode it had to handle.

2. A shared design system is non-negotiable

Without theme.css and the shared component library, we'd have 53 apps that all look different and none of them would look good. The design system turns every app into a first-class citizen from the moment it's created.

3. AI agents need guardrails, not freedom

An agent with access to React, Vue, Svelte, and vanilla JS will make inconsistent choices. An agent that can only use web components and a shared theme will produce consistent, high-quality output every time. Reduce the solution space and the agent gets dramatically better.

4. Internal tools compound

The first 10 apps were interesting. At 30 apps, something shifted — the team started expecting that any workflow could become an app. "Can we get an app for tracking client sentiment?" "Can the meeting notes become a searchable app?" When the answer is always yes and the turnaround is 10 minutes, the entire team's relationship with tooling changes.

5. Fun apps build adoption

The dad joke app and meme generator aren't ROI-positive. But they got people clicking around, discovering the real tools, and internalizing that this app ecosystem exists. Culture apps are adoption engines.

What's Next

We're continuing to expand the library — both apps and components. The current focus areas:

• More shared components — charting (cc-chart), Kanban boards (cc-kanban), and rich text editing
• Cross-app search — A unified search that spans all 53 apps
• AI-powered insights — The agent analyzes usage patterns and proactively suggests new apps or improvements
• Client-facing apps — Extending the pattern to client dashboards and portals

The Takeaway for Engineering Leaders

You don't need a frontend team to have great internal tools. You need:

1. A constrained architecture that an AI agent can operate within reliably
2. A shared design system that makes every output look professional
3. A component library that provides building blocks, not boilerplate
4. A deployment model with zero friction (static hosting wins)
5. An AI agent that can scaffold, build, test, and maintain apps autonomously

We went from zero to 53 apps in under two weeks. The apps are in use daily. The team loves them. And we never hired a frontend developer.

The economics of internal tooling just fundamentally changed. The question isn't whether you can build that internal app — it's why you haven't already.

Adam Harris is VP of Engineering at Last Rev, where he leads AI-augmented engineering practices. Alpha Agent is Last Rev's AI agent platform for engineering teams.