Build Features With AI That Don't Need Rewrites

The beautiful feature built on sand

You prompt: "add a feedback board with votes."

The agent builds a gorgeous board.

Voting buttons.

Comments.

Optimistic UI.

You click vote. Nothing persists. The state lives in a component, "temporarily", and the table was never designed.

Round two rebuilds half the feature around a schema invented mid-flight. Round three migrates Friday's data into it.

The demo looked done on day one. The feature ships on day nine.

An agent builds right when it meets the data before the pixels.

UI first or data first

UI-first costs twice what it looks like.

Mock shapes fossilize. The screen hardcodes a vote count. Three sessions later the real schema stores votes as rows in their own table. Every consumer of the mock needs surgery.

Engines diverge silently. One engine gets one field name, another gets a different spelling, a third gets nothing until week three.

Access arrives last, and breaks most. The board has no paywall because "we'll add access later." Later means threading a check through screens that assumed public.

Data first is not a throwback. It is giving the fastest builder in history a foundation before the facade.

What to do

Define the entity first, in one session, on every database.

For votes: who voted, on what, and when.

Decide it before any screen exists. The prompt is small and the review takes minutes. Schema sessions are the cheapest sessions, so schedule them first.

Give every engine the same set of actions.

Create a vote.

List votes for a post.

Remove a vote.

Each returns plain data, never something tied to one database.

Then build the thin route.

Validate.

Check access.

Make one call.

Return JSON.

Build it before the screen, so the screen arrives to a working contract. Components stay presentational. The agent cannot smuggle persistence back into pixels.

What changes for you

The demo that looked done on day one is done for real on day three.

Data designed at a desk. UI approved from a phone.

The itch to see pixels

Data-first feels slower on day one. No screenshots for the first two sessions.

Scratch the itch with an end-to-end test that creates a vote for real. Invisible to users. Proof to builders.

Pixels are the last mile, not the first impression.

Know this first

Data-first feels slower on day one. No screenshots for the first sessions.

The payoff arrives on day three, with nothing to rewrite.

Why BoringPush is the way to do this

Great features start with the data.

BoringPush defines every entity the same way on SQLite, Supabase and MongoDB.

Your agent builds the data, then the route, then the screen.

No rebuilds. No drift between databases.

FAQ

Does data-first slow down prototyping?

Only the screenshot-deep kind, the kind with no substance behind it. Working prototypes arrive at the same speed or faster, because no session rebuilds another's foundation. If you truly need a throwaway mock for tomorrow's demo, say so and keep it outside the real data model.

What if I don't know the schema yet?

Discover it in the schema session, not the UI session. Ask the agent to design the table for three named behaviors and iterate there, where changes cost lines instead of files. Uncertainty argues for earlier data design, not later.

How small should the first schema session be?

One entity, its fields and its lookups, on every engine. Resist bundling "while we're here, add comments and flags". One entity per session keeps review honest and lets the next step start immediately.

Do thin routes really stay short with real validation?

Yes, because validation and business rules live outside the route. The route is four movements: validate, check access, call, respond.

When a route swells, the fix is extraction, not a bigger allowance. Some older routes in the kit are longer than the target, so treat it as the rule for new work.

Can the UI session run in parallel with the data session?

Carefully, yes. One agent builds the data actions against the finished schema while another drafts the UI against the agreed contract, and a third session integrates.

It works because the schema froze the interface first. Without that frozen contract, parallel agents build two apps that share a name.

When is UI-first actually right?

For pages with no state, such as landing, pricing and docs. No schema exists to design first, so pixels lead.

Stateful features go data-first; stateless pages go pixels-first. Most agent pain comes from treating a stateful feature like a landing page.

Keep reading

• OpenCode SaaS Starter: Stop the Every-Session Redesign — the file this pipeline obeys
• Mobile AI Guardrails: Couch Fixes That Can't Break Prod — the same pipeline at phone scale
• Will Claude Code Respect Your Boilerplate? 6 Tests — the scorecard this pipeline satisfies