Krishna Bhupathi
Hyderabad 10:30 IST
All work
Concept, self-initiated
A landing page for a tool that checks database migrations before they reach production. Developer tools all look alike, so this one is drawn like an engineering drawing on graphite film.
Role
Positioning, copy, visual identity, design and build
Timeline
1 week
Tools
Figma, Framer, one React code component
Status
Concept. Not a real product or client
The hero. The check on the right is live: the migration types in, the lock is measured, then the safe rewrite is drawn.
The brief
The buyers are backend leads who have been burned by a migration once. They don’t need to be told locks exist. They need to see, in one look, that this tool knows which lock and for how long.
So every Postgres claim on the page had to be correct. An engineer who spots one wrong lock name closes the tab.
The story behind it
A one-line migration on a Friday afternoon. It added a column with a generated default to the orders table, ran in two seconds on staging, and locked checkout for forty minutes in production.
That story is a composite. Teams have written about versions of it for years, and I’ve run enough backend work to know how believable it is. The page tells it as a timeline with clock times, because that’s how an incident is remembered.
What I did
• Wrote the positioning and copy around one promise: know what your migration locks before you merge it.
• Built the identity from engineering drawings: Warm graphite film, chalk linework, registration marks, a title block as the footer, and one amber for anything that blocks.
• Designed and coded the live check in the hero, with a still version for reduced motion.
• Checked every hazard in the “What it catches” table against the Postgres documentation.
• Designed the rest of the page: how it works, the incident story, integrations, pricing, FAQ and the waitlist. Made it responsive down to 390px.
Three decisions
1. The hero measures, it doesn’t describe
A migration types in, an amber bar grows to 38 minutes, then three outlined bars show the safe version. Filled means blocking, outlined means not. The page’s whole argument fits in that one change of shape.
Lock timeline, as drawn in the hero
As written: ~38 min of ACCESS EXCLUSIVE. Suggested: longer overall, no long locks.
2. A drawing, not a terminal
Developer tools default to cold near-black with a neon accent. This page is dark too, but warm graphite like drafting film, with no neon. A migration is a planned change to a structure, so the page borrows from drawings instead: a fine grid, chalk lines and a condensed grotesk. Monospace appears only where there is real SQL.
Palette
Instrument Sans, condensed, headings
Merge on a Friday
3. A table where the content is a table
“What it catches” is a real table: change, lock, what waits, the fix. Engineers scan it like documentation, and it doubles as proof that the product knows Postgres. On a phone, each row becomes a labelled block.
One row of the table
CREATE INDEX
SHARE lock for the whole build
Inserts, updates and deletes wait
Use CREATE INDEX CONCURRENTLY
How it’s built
• Live check: a React code component with three states (type, measure, rewrite) that loops, and a static final frame for reduced motion.
• Drafting grid: a page-level background in Framer, with the sheet border and registration marks as one reusable component.
• Hazards table: a CMS collection, so new hazards can be added without touching the layout.
• Waitlist: a Framer form posting to a webhook. In this concept it only shows the success message.
Result
This is a concept, so there are no customers or numbers to report.
If it shipped, I’d watch how many visitors reach the hazards table and whether they join from there or from the hero. That would show whether proof or the story does more of the persuading.