OpenProfile Update: The First Launch Proved It Worked. This Pass Makes It Trustworthy.
- Rich Washburn
- 12 hours ago
- 6 min read
OpenProfile Update: The First Launch Proved It Worked. This Pass Makes It Trustworthy.
There is a version of a product launch article I could write that focuses on the new feature count, the lines changed, the surfaces touched. I'm not going to write that one.
What I actually did since the OpenProfile launch was less exciting and more important. I made the thing stable.
When you launch something real — not a demo, not a pitch deck, but an actual product with real users opening it from NFC taps, QR codes, and direct messages — you find out what you missed. Not the big things. The big things get caught before you ship. The things you find post-launch are the small ones that don't show up until a stranger on an iPhone 13 in a coffee shop taps your card for the first time and the page drifts slightly sideways. That's the kind of problem I've been fixing.
The Public Experience Was the Priority
OpenProfile's core job is to make the moment someone taps or scans a card feel instant and credible. If that moment is slow, wobbly, or broken, nothing else matters. No one cares how good the lead capture is if the page loads sideways.
So that's where I started.
The public profile page was rebuilt around dedicated public endpoints. Previously, public requests were pulling more application data than they needed — processing overhead that showed up as latency, and a blurrier boundary between what was intended for the public and what was intended for the application internals. Now a public request gets exactly what it needs to render the profile: name, title, company, bio, contact links, colors, photo. That's it. Internal ownership fields, system metadata, deletion state, administrative timestamps — none of that travels through the public API anymore.
The result is a leaner response and a cleaner privacy boundary. Public means public. Internal means internal. The line is now enforced by the data contract, not convention.
Mobile Was Broken in Ways That Only Show Up on Phones
Here's the thing about testing a mobile experience on your laptop: you're not actually testing it. There were two mobile problems I found that I'm not proud of shipping, but I'm glad I found them.
The first: decorative landing-page elements were extending a few pixels past the viewport width. Just a few pixels. Invisible on desktop. On mobile it made the entire page feel like it was slightly wrong — like it was about to slide sideways. Testing confirmed the scroll width didn't match the usable width. It's fixed now. The viewport stays locked.
The second was more significant: external websites and project pages embedded in card blocks were being placed in a fixed 16:9 container. On a phone, that container collapsed to roughly 155 pixels tall. Technically functional. Practically useless. The kind of thing that makes you look at a live production URL and feel a specific kind of embarrassment.
Those embeds now use a responsive viewport-based height — full available width, approximately 70% of the screen height, a sensible mobile minimum, a capped maximum on larger screens. In the production test, that same embed went from 155 pixels to more than 465 pixels tall. That's the difference between something a visitor closes immediately and something they actually use. You can see the live result on the Projects page at OpenProfile.space.
The URL Got Cleaned Up
Small thing. Matters more than you'd expect...The dashboard now shows and copies the direct public URL — https://openprofile.space/rich — instead of an internal function path or redirect URL. The clean URL is what goes on your card, in your email signature, in your bio. It should look like your address, not like a system call.
The server-side sharing bridge still exists behind the scenes for bot and crawler handling — that's still how LinkedIn, WhatsApp, Slack, and Discord get the proper branded preview when someone pastes your link. But humans see the clean URL. That's how it should work.
What Changed Behind the Scenes That You'll Never See
Most of this work is invisible when it's done correctly.
Reserved route protection: you can no longer create a profile slug that conflicts with application routes. No /login, no /dashboard, no /api. The editor catches it and the backend rejects it independently. This sounds obvious in retrospect. It wasn't enforced before.
Custom HTML sandboxing: user-supplied HTML embeds are now more strictly isolated from the host application. External sites and custom HTML embeds were previously treated with similar permissions. They're not the same thing. An external trusted site needs certain permissions to function. User-supplied HTML doesn't get the same access. That distinction is now enforced.
Public error isolation: a component failure on a public profile page no longer takes down the entire public rendering tree. There's a proper error boundary now. If someone opens your card via NFC at 2am from a slow connection and one block fails to load, they get a controlled fallback — not a blank screen with no explanation and no way back.
Better 404 handling: invalid or deleted profile links now resolve to a real message. "Card not found. This card doesn't exist or was removed." With a route back to OpenProfile. Not an error screen designed for developers. An actual response designed for strangers.
Crawler controls: robots.txt now blocks crawlers from dashboard, editing, analytics, leads, settings, auth, and API routes. The public homepage, Store, Terms, Privacy, and profile pages remain open. This is basic hygiene. It wasn't in place before.
What Changed for Card Owners
The editor now has persistent Save and Cancel controls. You no longer need to scroll to find the action buttons while editing. It also warns you if you try to leave with unsaved changes — not perfectly, because intercepting every browser-back scenario in a single-page application cleanly would require a deeper router refactor, but the common cases where people accidentally lose work are now covered.
Card selectors across the dashboard, leads, and analytics now show enough information to actually distinguish between cards. Instead of just a name, you get: Full Name — /slug (Company). Obvious once you see it. Necessary if you're managing more than one card.
Analytics controls got better mobile tap targets, improved spacing, and cleaner chart contrast. Lead and analytics navigation received the same card-identification upgrade. Share links now consistently show the clean public URL.
Signup got small but real improvements: a visible password hint, working Terms and Privacy links, better accessibility semantics.
The legal pages — Terms and Privacy — were cleaned up structurally: duplicate headings removed, cross-references turned into actual links, a "You Content" typo corrected. One important note I want to be clear about: this was a presentation and wiring cleanup, not legal review. The Terms and Privacy pages are now fully linked into signup and cleaned up for readability. The next step before the beta expands is substantive review of the underlying policy language by an attorney. I'm not going to describe a cleanup pass as legal finalization.
What's Still Honest Work-In-Progress
The original article was honest about what wasn't finished. This one will be too.
The sitemap is partly outside my control. Base44's generated sitemap still lists some application routes that aren't useful public search results. robots.txt now blocks crawlers from those routes, but the sitemap itself is platform-generated and doesn't enumerate every public profile slug. That's a platform-level gap, not something I can fully resolve from inside the app.
Social previews still route through the server bridge. The clean URL is what humans see, but JavaScript-only pages can't serve unique Open Graph metadata to crawlers that don't execute JavaScript. LinkedIn, Slack, WhatsApp, iMessage, Discord — they all still go through the server-rendered sharing endpoint to get the proper branded preview. The clean URL and the server bridge coexist. That's the right architecture, it's just worth being transparent about.
Browser-back protection could go further. The common accidental-loss cases are covered. Perfect interception would require a router refactor I'm not ready to do yet.
Payment certification is still a separate gate. This optimization pass didn't include a complete real-money end-to-end transaction test. That disclosure from the original article stands.
Why This Pass Matters More Than It Looks
The beta metrics from the launch post were real when I wrote them. Refresh them at openprofile.space/analytics if you want current numbers — I'd rather not reprint them here as present-day figures.
What I can say is that the product is materially more defensible now than it was at launch. Not because I added features — I didn't. Because I did the unglamorous pass that most solo builders skip because it doesn't make for a good screenshot.
Public APIs now expose only what they're supposed to expose. The mobile page doesn't drift. Embeds are usable on a phone. Error states give visitors something to work with. URLs look like URLs. Reserved routes are protected. The crawler sees what it should see and nothing else.
None of that makes for the same kind of demo as an AI concierge or a live video room. But this is the pass that makes the beta real. The initial launch proved OpenProfile could work. This update is about making it stable, safer, and easier to trust. That's a different kind of milestone. It's the one that actually matters before you put it in front of more people.
Rich Washburn is a technologist and strategist working at the intersection of AI, infrastructure, and capital. He is Managing Partner and Chief AI Officer at Eliakim Capital and CIO of Data Power Supply.
Comments