DEV Community: David R I

The design-team case for a lightweight local backend

David R I — Wed, 02 Sep 2026 11:54:50 +0000

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:

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).
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.
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.

The Privacy Summary Screen — 60 Minutes of Design With Outsized Impact

David R I — Wed, 02 Sep 2026 11:54:41 +0000

Most mobile apps ship a privacy policy as a link that opens Safari. A smaller number ship an in-app rendered policy. A tiny minority ship what I think is the single highest-leverage privacy screen: a summary that mirrors your Nutrition Label in plain language, designed to be read.

Why it's high-leverage

The privacy summary sits at the intersection of three concerns:

Users read it before granting sensitive permissions. Especially for camera, contacts, location, and health data.
App Store reviewers check it exists and matches your store listing.
Regulators (GDPR, CCPA) reward it. Clarity is a compliance signal, not a legal defense — but it's what an investigator asks for first.

Sixty minutes of design work. Meaningful trust dividends. Often the difference between first-submission approval and a rejection loop.

What to include

The privacy summary should mirror your Privacy Nutrition Label but with real language humans can parse:

Each data category you collect — displayed as a card or a row, with a clear icon.
Why you collect it — one line, plain language. "So you can log in on another device," not "for authentication purposes."
Where it's used — is it stored on our servers, shared with third parties, only on your device? Be specific.
How to opt out or delete it — a link or a button to the settings page where the user can act on that category.

Six to eight cards, one per data category. No more.

Visual patterns that read as trustworthy

Design choices that consistently score high in user-testing for trust signal:

Real language, not legalese. "We store your email address so you can log in" beats "Personal identifiers are retained for authentication purposes."
Muted, confident colors. No warning reds, no compliance yellows. A neutral surface with soft accent for the data-category icons.
Readable typography. 16pt body, generous line-height (1.5x), enough paragraph spacing that scanning is easy.
Icons per category (not just text). A camera icon for camera data, a location pin for location. Recognizable at a glance.
A single primary action at the bottom — usually "Manage my data" that takes the user to a settings screen with real controls.
A last-updated date — small, but present. Signals a living document.

Testing the summary

The 20-minute usability test that works:

Show the summary to someone who hasn't seen the app.
Ask them to explain, in their own words, what data the app collects.
Ask them what they'd want to change.

If they can name most of the data categories correctly, the summary is doing its job. If they say "I don't know, it was too long," redesign shorter. If they say "I don't trust this app," look at the visual language — usually the problem is too many warning colors or too many disclaimers.

Where it fits in the permission flow

The summary shouldn't only live in Settings. It should appear:

At signup, before the user provides their first personal data (email, name).
Before major permission prompts — camera, location, contacts, health.
In Settings, always reachable.
On policy update, as a first-launch modal or toast.

Placement matters as much as content. A summary buried in Settings doesn't help. A summary shown at the right moments builds trust as the user progresses through the app.
[7:02 AM]## The RapidNative / letsdeploy.it opinion

At letsdeploy.it, we treat the privacy summary as part of the pre-submit check — does the app have one, is it reachable from settings in 2 taps, does it match the Nutrition Label. It's not required by Apple, but it correlates strongly with first-submission approvals.

If you design nothing else this sprint, design the privacy summary. Sixty minutes of work. The trust returns compound for the life of the app.