ClearPath Cards

The interesting constraint

A business card has to keep working and it has to be correctable, and those requirements pull against each other. So a card is a plain JSON object with two storage paths: a Postgres row behind a short link, which gives clean URLs, real Open Graph previews, a view counter and editing in place - or the same JSON LZ-compressed into a URL fragment, which needs no database, no row and no server, and keeps working regardless. The fragment card cannot be edited, because it has no row to update; the stored card can. Nothing about the product hard-depends on the database.

Graceful degradation as a feature

If the database is unreachable or unconfigured, publish does not error - it falls back to the fragment path and hands the user a longer link that works permanently, and says which one it gave them. Photos are downscaled to 320px and inlined as data URLs, so a card is fully self-contained with no external image dependency. This is the same instinct as the REST fallback behind the ML platform ingestion: assume the dependency will fail, and decide now what happens when it does.

Choosing the database on its failure mode

The obvious managed Postgres pauses a project after roughly seven quiet days and needs a human to click Resume in a dashboard. For a tool whose promise is that a link keeps working, that is the exact failure it exists to prevent - a card nobody opens for a fortnight would quietly stop resolving. The storage is Neon instead, which scales compute to zero when idle and wakes itself on the next query in a few hundred milliseconds. Same price, same Postgres; the difference is whether recovery needs a person.

Editing is a capability, not an account

The product promises no signup, so editing cannot depend on a login. Publishing returns a secret token and stores only its SHA-256, compared in constant time; whoever holds the edit link may rewrite or delete that card and nobody else can, and a wrong token is indistinguishable from a card that does not exist, so the endpoint cannot be used to discover which cards are real. The token travels in the URL fragment, which browsers never transmit, so it reaches the server only on the request that spends it.

Recovery without an account

Capability tokens have one failure that matters: the token lives in one browser, so clearing it or changing phones freezes the card forever. The answer is a four-digit PIN chosen at publish. Four digits is 10,000 guesses, so two things make it safe enough - five wrong attempts lock that card for fifteen minutes, and the stored form is PBKDF2 at 150,000 iterations with a per-card salt, so a leaked table costs real compute per card rather than one rainbow table for all of them. A correct PIN mints a new token and retires the old one, which also revokes the device that was lost.

One screen, measured rather than assumed

The brief was that a recipient sees everything without scrolling. The first version met that for the cards I happened to test; a card with a long name, four credentials and seven links ran 175px past the fold on a small Android, because nothing in the layout could see how much card there was. It now lays out against the small-viewport height unit rather than the one iOS Safari inflates by about 100px, trims the least load-bearing lines on short screens, and measures what is left and scales it with a floor - past which the card scrolls rather than becoming unreadable, and if the reader has enlarged their system text no scaling happens at all. Verified across eight viewports and three card weights: 23 of 24 combinations fit exactly.

Three jobs, one codebase

The landing page shows a prospect what ClearPath can build. The builder at /new is a genuinely free tool, and every card handed to a stranger carries a "Build your own card" button and a line pointing back here - so the product markets itself to exactly the people already holding it. A private dashboard counts what actually happens: cards made, cards edited twice, contacts saved, and the taps that cross from a free card into a conversation. A demo, a lead-gen funnel and a real product in the same deployment.

Built with