Ambasdr

A person isn't just a job title, a resume, or a single profile anymore. Someone can be a designer, a founder, a photographer, an investor, and a community builder all at once, and each of those usually lives in a different place.

LinkedIn favors work history, Instagram a visual identity, TikTok personality, a portfolio a few projects, GitHub code, Calendly your calendar. There was never a shortage of information. The problem was that every platform flattened someone into a narrow slice, and none of them explained how the slices fit together. A designer who's also a founder can't show both without looking unfocused. A founder misses inbound because there's no single place that tells the whole story.

The opportunity was never to replace those platforms. It was to build a layer above them: one place that pulls the fragments together and can actually be talked to. Ambasdr sits between a person and everyone trying to understand them.

The direction came out of conversations with recruiters, creators, professionals, influencers, hiring managers, VCs, beta testers, and waitlist users, not one narrow persona. The same pattern showed up across all of them: people weren't struggling to present information, they were struggling because it was scattered across too many places.

Plenty of them juggled several resumes, portfolios, and audiences at once. Those sides of a person aren't separate in real life, but the tools made them separate online. People wanted to be understood without shrinking down to a single title.

A résumé summarizes, a portfolio displays, a link-in-bio organizes, but each still leaves the visitor to interpret the person manually: open links, read documents, decide what matters. Ambasdr's job was to make an approved version of that information explorable through conversation.

That meant separating three things cleanly: the structured identity that establishes who someone is, the approved knowledge that gives the AI something real to represent, and the conversation through which a visitor explores it. Keeping those layers distinct is what let one product stay coherent across responsive web, iOS, and Android.

Most AI interfaces just answer prompts. Ambasdr had a touchier job: it was speaking for a real person, which raised the stakes on trust. Visitors had to trust the answers were useful. Owners had to trust the AI wasn't putting words in their mouth. And the product had to make clear the person always had the final say.

Every major feature traces back to four questions: Can the AI represent me accurately? Can I control what it knows? Can visitors trust the answers? Can I keep improving how I come across?

The hardest part was never model selection. It was defining what the system should know and how it should ground an answer: ingest the identity, résumé, portfolio, files, and links; keep that source material attached to the right person; separate public from private; then answer from the owner's actual material, surfacing the supporting file, link, or highlight, rather than from generic model knowledge. I treated prompts, identity fields, content structure, retrieval surfaces, and response behavior as one product architecture, and directed the implementation through that spec.

Across roughly 15 versions of onboarding, tested with a community of 50 to 100 people, it became clear a setup flow wasn't enough. Ambasdr wasn't collecting information. It was learning how to represent someone.

So onboarding had to get at deeper questions: what does this person want to be known for, what topics should the AI understand, which resources matter most and why, what should it avoid saying, what tone should it strike, and what should visitors be prompted to ask. That's why Teach Your Ambasdr became one of the most important parts of the product.

The toughest problem was working out how all these documents relate, and how each should shape the AI behind the scenes. Ambasdr ties together profile data, files, links, resource context, instructions, tone, visitor questions, AI responses, conversation summaries, and signals about what's missing.

A visitor asks a question. The AI answers if it has enough to go on. If it doesn't, that gap becomes feedback. The owner adds context, uploads a resource, or updates instructions, and the profile gets better the more it's used.

Those conversations are designed to run both ways. The most important product evolution was realizing conversations weren't only a visitor experience; they were owner intelligence. When visitors ask questions, they reveal what people want to know.

The same question asked repeatedly becomes a signal. A question the AI can't answer becomes a knowledge gap. Questions about collaboration, booking, hiring, press, or pricing become intent. Designed this way, the profile can tell its owner how they're being perceived and what context their audience needs most, a capability the model supports, not yet a loop proven at scale.

A surprising beta insight was that people still valued familiar, link-based behavior. They wanted to connect the platforms they'd already built, such as social profiles, a store, a channel, or a portfolio, so Ambasdr didn't reject that. It added context around it.

So the public profile carried two layers: a familiar surface of identity, links, and proof, and a conversational layer that helps a visitor understand what any of it means. Rather than search a resume, open five links, and guess, a visitor can just ask. Questions became the interface.

Chat couldn't become the entire product, though. Four modes (Chat, Highlights, Files, and Links) each serve a different visitor, and all four stay inside the same profile: selecting Files or Links switches the content beneath the tabs rather than throwing the visitor into an unrelated page.

The mobile redesign spanned two technically distinct surfaces: the native iOS and Android app, and the responsive public-profile website opened from a shared URL. Treating them as related but different mattered. A responsive site has different constraints from a native screen, even when the final feel should be cohesive.

Rather than treat every request as a new component, I ran an audit first: existing code, Storybook, the design system, Figma direction, and engineering conventions, to identify the approved source of truth, then reuse, restyle, or repair. For the main cards, the updated web app was the source of truth; the mobile task was parity, not a second design language. Work was prioritized by product risk: functional and identity integrity first, consistency next, polish last.

The most important strategic call was how to describe the product. Framed as an AI business card, Ambasdr competes with NFC-card and link apps. Framed as an AI identity and knowledge layer that turns a static profile into an interactive representation of a person, it becomes infrastructure, a partner to distribution platforms rather than a competitor, with several routes to market.

Pricing followed the same logic. The product had to stay accessible for individuals while being valuable enough for creators, professionals, and founders building a serious personal brand. We explored Free, Pro, and Premium tiers with a trial, so people could experience being represented before paying for depth.

The architecture call mattered as much as the price: keep plan management primarily on the web to sidestep App Store and Play Store payment cuts. Where money changed hands shaped where parts of the product could live.

Ambasdr wasn't only an AI product. It was designed and prototyped through an AI-assisted workflow. Across web and mobile I moved between Figma and Figma Make for design; v0, Claude Code, Codex, and Cursor for prototyping and implementation; and React Native with Expo/EAS for mobile, letting a three-person team explore more directions and ship across platforms faster than a team that size normally could.

The operating model mattered more than any single tool: prototype quickly, validate direction, translate patterns into implementation, and keep learning. We even ran automated flow walkthroughs (Playwright-style click-throughs of real product flows) to catch broken states during rapid iteration.

As a co-founder on a three-person team, I became the connective layer between the business idea, the product experience, and the team's ability to ship, carrying work usually split across a product, design, and technology lead. Engineering was a shared, founding-team effort; my lane was the product model, the AI's behavior spec, and cross-platform UX, which I drove into implementation through detailed technical and design specs and by auditing what already existed before proposing anything new, while sharing strategy, pricing, and go-to-market with my co-founders.

The defining founder skill wasn't producing more screens. It was repeatedly reducing ambiguity so design, engineering, and business decisions could move in the same direction, and, often, deciding what not to build. The clearest example was voice: users liked it, but a structured profile proved more useful day to day, so we pulled voice back from a core interaction to an enhancement instead of building the product around it.

After about a year, Ambasdr grew from an early hiring hypothesis into a broader platform for professional and creative representation: 500 on the waitlist, around 20 beta users, 450+ research conversations, 15 onboarding iterations, a test community of 50 to 100 people, and a product spanning web, iOS, and Android.

The direction is sharper now. Ambasdr isn't about making another profile. It's about giving people a living representation of who they are, what they do, and why it matters.

The hardest part of Ambasdr wasn't getting the AI to respond. It was making sure each response felt accurate, controlled, and true to the person behind it. AI usually gets talked about in terms of speed and automation. But once it's speaking for someone, the real question is trust.

If Ambasdr works ten years from now, the proof won't be that everyone uses AI. It'll be that people can show up as their full professional, creative, and entrepreneurial selves in one place, instead of being boxed in by LinkedIn, Linktree, resumes, portfolios, or a pile of context-free links.

The bigger lesson: AI product design isn't primarily about adding a chat interface. It's about defining what the system knows, where that knowledge comes from, who controls it, how identity is represented, and how one product stays coherent across platforms. My job was to connect those decisions across strategy, architecture, interface, and implementation, because the product couldn't be solved inside a single discipline.