The design-team case for a lightweight local backend

TL;DR

• Design QA against real data is more talked about than practiced, because the backend won't run on a design laptop
• A Docker-based local stack costs more than the discipline can pay
• A lightweight single-binary backend makes "log into the real app with seeded data" a designer-run step
• Our loop: seeded fixtures in the morning, review on a physical iPhone, annotated tickets by lunch
• Four months in: post-launch UX regression tickets down 60%, design-to-validated same-day

Most design teams working on data-driven products live in a strange half-world: designs are validated in Figma with mocked content, then shipped, then user-tested against real data, and only then discovered to break. The empty state Figma didn't show. The long username that wraps to three lines. The bulk-import screen that looks fine with 3 fixture rows and terrifying with 1,500.

The standard rebuttal is "design should QA against real data before launch." Sure. In practice, that requires the designer to be able to run the app with real data. Which requires the backend to be runnable. Which, if you're on a hosted Supabase or a Docker-based stack, means running a dozen containers on a design laptop with 8GB RAM. Which fails.

That failure mode is why design QA against real data is more talked about than practiced. And it's the failure Tinbase solves for us.

The Docker-Supabase anti-pattern for design

We used to run local Supabase for the app I lead design on. The docker-compose stack pulled 12 images, allocated 2.3 GB of disk, consumed 1.6 GB of RAM when idle, and spun the fan on my M2 Air whenever I opened Figma at the same time.

What actually happened:

• I stopped starting local Supabase before design reviews.
• I reviewed against Figma prototypes with lorem-ipsum content.
• Real-data UX bugs shipped to production and surfaced in user testing 3 weeks later.
• Post-launch redesign cycles cost far more than design-QA-against-real-data would have.

The root cause wasn't discipline. It was that the tool cost more than the discipline could pay.

The lightweight-backend change

Tinbase is a 100MB single binary that runs the full Supabase-compatible stack (Postgres, auth, realtime, edge functions, webhooks) with around 100 MB of RAM and a cold boot measured in seconds. Same SDK calls, same RLS behavior, same auth flows as hosted Supabase. From the app's perspective, indistinguishable.

From my perspective as a design lead: it runs while I design.

My laptop now has the browser with Figma open, Cursor with the RN codebase, the Expo dev-client on a physical iPhone, and Tinbase serving the backend. Total system RAM usage around 4.5 GB, which leaves 3.5 GB free on my 8 GB machine. Fan silent. Battery lasts the day.

A workflow: seeded fixtures + Figma + real device

Here's what our design-review loop looks like now:

1. Morning: eng runs tinbase seed dev, a script that populates 500 realistic fixture rows across our main tables (users with real names, orders with realistic amounts, images with actual JPEG data from an Unsplash seed).
2. Design review: I log into the app on my iPhone (dev-client pointing at local Tinbase), navigate through the flows in scope, and screenshot anything that looks off.
3. Bug ticket: annotated screenshots go into Linear with the seed-data reference so eng can reproduce.

That loop used to be impossible because step 1 required an eng to spin up Docker for me, and step 2 required me to keep asking "is the backend still running?" Now step 1 runs on my laptop and step 2 is just "is the app running?"

Measurable outcome

We've been on this workflow for 4 months. Compared to the 4 months before:

• Post-launch UX regression tickets down 60%.
• Time from "design change" to "validated against real data" down from roughly 2 weeks to same-day.
• Zero "3-week-post-launch surprise" incidents (previously about 1 per quarter).

None of that is because the design team got better. It's because the tool got out of the way.

Where a lightweight backend won't help

• If your data model requires real production data (medical records, financial ledgers with realistic distributions), seeded fixtures are still a compromise.
• If your app has non-Postgres backing services (Elasticsearch, Redis-only features), those still need to run somewhere.
• If your UX depends on multi-region latency behavior, local can't simulate that faithfully.

For most consumer and SaaS apps though, the local Postgres + auth stack IS the backend that matters.

The takeaway for design leads

If you're frustrated by the "designs look fine in Figma, break in production" cycle, take a hard look at whether your local backend is runnable on a design laptop. If it isn't, you're being asked to guess at real-data UX, and the guesses miss. A lightweight backend that gets Docker out of your loop is not just an eng-ergonomics tool. It's a design-quality tool.

Can your designers run your backend today? If not, what's the blocker: RAM, Docker, or permissions? Curious what the distribution looks like in the comments.