Why ShellUI?

From building to shipping

• Developers love to build — but struggle to ship
• AI changed that: agents let you turn ideas into code very quickly
• Every new product still reimplements the same general features
• Those features deserve a shared codebase — that’s what I’ve been building with ShellUI

Disclaimer

What ShellUI is

• Today it’s a proof of concept — a one-person project, still taking shape
• Experimental — expect breaking changes
• Not in production — nothing is battle-tested yet
• Aiming for a first release later this year — with serious ambition
• But it already looks pretty cool… I think

Microfrontend shell

What ShellUI is

ShellUI is a microfrontend — a wrapper around your app with an opinionated take on basic product features.

• The shell is built with React and shadcn/ui
• Your app runs in an iframe and communicates with the shell through the postMessage API
• Your embed can use any stack — Angular, React, plain HTML, …

Features

What ShellUI is

Honestly? A two-minute demo beats this slide every time.

Shell UI today

What ShellUI is

Needs a backend

What ShellUI is

• The shell is the UI — you still need a backend for real products
• Supabase is the popular default — ShellUI supports it out of the box
• We also ship a self-hosted Django backend for teams that need deeper, custom integrations

Backend APIs

What ShellUI is

Shared product features as APIs — so every app does not rebuild the same plumbing.

File storage & LLM Gateway — coming soon

Same rule as before — let’s look at auth in the demo, not on this slide.

Shell UI today

What ShellUI is

All open source — https://github.com/shellui

Architecture

The philosophy

• Microservices + micro-frontends
• Every service exposes a clear, defined interface — I know what it does, and that's the only surface I need to care about
• Those APIs are versioned, tested, and not supposed to break

Pros

The philosophy

• Smaller codebases — easier to review and for AI context
• Limited blast radius when something goes wrong
• Deploy and iterate on one service without touching the rest
• Clear boundaries — fewer surprise side effects

Cons

The philosophy

• More moving parts — ops, networking, observability
• Harder to trace bugs across service boundaries
• Integration and contract testing take more work
• Some duplication — types, auth, shared UI patterns

Separation of concerns

The philosophy

• Main goal: embrace clear boundaries between pieces
• Vibe-coding in one area shouldn’t break code somewhere else
• Work inside a slice — frontend, API, or worker — with confidence
• Room for trash code in a slice — easy to drop when it’s done

Vibe-coding it

The code

• Goal: spend time on the code, not on the AI
• One feature at a time
• Know the code structure — understand it all
• Review, test, and document every result — pretty aggressive micromanagement

Vibe-coding it

The AI

• Cheap Cursor plan only — ~20 CHF/month
• Didn’t write a single line — all done by prompting
• Even typos, color tweaks, and minor fixes went through the agent

Room for improvement

Vibe-coding it

• Still plenty to optimise in how I work with the agent
• Add skills — encode conventions and workflows for the project
• Add MCPs for backend services — safer context, fewer wrong guesses

Conclusion

Takeaways

• Not for everyone — strict process and real ownership of the code
• Not for every project — the extra structure has to earn its keep
• Still worth knowing: microservices + micro-frontends brought me peace of mind