nsso

At a glance

Who it serves

People bringing their profile, work and products into one public identity.

What I owned

Independent product design and implementation, including Deity and commerce integrations.

Key decision

Show before/after review cards before AI changes the owner’s profile.

Current state

Live profile and storefront product with an AI coaching surface.

Evidence and gap

Live product and public profile. Adoption, conversion lift and AI quality results are not published here.

Problem

nsso began from the question people are asked whenever they meet someone new: so, what do you do? Most people answer with a title, employer, or category, compressing years of work and identity into one sentence.

That compression is starting to cost people opportunities. Hobbies become careers, careers expand into side projects, and employers increasingly care about what someone has built outside of work. The world rewards the full picture of a person, but that picture is hard to show.

The average identity is scattered across too many platforms. LinkedIn holds the professional, Instagram holds the personality, a portfolio holds the work, and a link-in-bio holds the links. None of those surfaces explain how the parts connect.

Link-in-bio tools were a start, but a list of links is still just a list of links. It does not help someone understand the relevance of everything you have done, and it does not help you see it clearly yourself.

The product opportunity was Shopify, but the product is you: a surface where building your profile becomes an act of self-clarification, and where all the parts together help answer what makes you, you.

The hard part was not the profile. It was building an AI agent that could read the live profile, write directly into it, and make self-articulation feel like a conversation rather than a form.

Architecture

nsso combines a public profile, structured CV, projects, qualifications, contact methods, social links, product listings, hosted sales pages, referral earnings, PayPal and Polar payment flows, and profile completeness scoring.

The model layer is Deity, the AI profile coach. It uses Gemini 2.0 Flash for streamed profile coaching, tool calling, structured suggestions, profile-section rewrites, and sales-page copy generation.

The context layer gives Deity the live profile, not a blank chat window: name, headline, bio, work experiences, qualifications, projects, products, links, and contact methods. It also connects to a curated knowledge database of investors, grants, accelerators, AI tools, job boards, courses, services, members clubs, business knowledge, pitch decks, films, and creative inspiration.

Retrieval uses Gemini Embedding 001 to create two 768-dimensional embeddings: one for the incoming query and one for the user profile text. A Supabase RPC re-ranks retrieved chunks by query similarity and profile similarity, so different users asking the same question can receive differently ordered guidance.

The knowledge corpus lives in pgvector inside the same Supabase instance as the profile data. That keeps retrieval as a single authenticated SQL call rather than a cross-service request to a separate vector database.

The orchestration layer runs dual-mode intent arbitration before any tool access. If the message signals profile intent, Deity receives tool schemas and can emit profile mutation calls. If it signals a knowledge request, tool schemas are withheld and the system runs RAG instead.

When profile intent is confirmed, Deity emits streaming function calls such as update_bio, add_experience, and add_project. The server parses them into Review Mode confirmation cards showing the field, current value, and proposed value before any Supabase write occurs.

The governance layer treats public identity, money, and AI-generated self-presentation as high-trust surfaces. Deity is instructed to use the live profile as its source for credentials, companies, job titles, projects, and achievements. Review Mode gives the owner a chance to reject an inaccurate proposal before it is saved.

PayPal embeds are treated as a governed security surface. User-authored HTML is parsed, disallowed tags and attributes are stripped, unsafe script patterns are checked, and external domains are validated against a PayPal allowlist. The UI shows scanning, secure, or unsafe before saving.

The human/product layer is a fixed identity architecture: Links consolidate the digital footprint, Experiences and Qualifications form the proof layer, Projects show what someone has built, and Products & Services make the profile commercially actionable.

The visual language, liquid glass design system, public profile structure, and monetisation layer all serve the same brief: nsso should make someone feel clearer, more future-proofed, and more proud to share themselves with the world.

Why this approach

The defining product choice was to treat nsso as an identity operating system, not a prettier link page. If the promise is all of you, all in one place, the product cannot stop at links.

Streaming tool calls were chosen over a request-response loop. A standard chat assistant can suggest copy, but Deity can propose exact profile changes mid-stream, which the server turns into reviewable confirmation cards.

Review Mode is deliberate friction. A wrong public bio, invented achievement, or accidental profile change is a credibility problem, so the product shows before/after cards before anything writes to Supabase.

Dual-mode intent arbitration keeps search and write authority separate. Knowledge requests run retrieval with tools withheld; profile-editing requests receive tool schemas. That reduces ambiguity when the user asks something that sounds partly like advice and partly like an edit.

Profile-aware RAG was chosen because generic retrieval produces generic advice. A designer and a startup founder asking about investors, courses, or positioning should not receive the same documents.

Supabase pgvector was chosen over a dedicated vector database because the corpus is curated and relatively static. Keeping profile data and vector search in one Supabase environment reduces auth complexity, cold starts, and operational overhead.

The PayPal sanitisation approach was a product decision, not just an engineering precaution. nsso accepts full PayPal embed code, then sanitises and verifies it, because the storefront layer needs real payment flexibility without silently compromising security.

Tradeoffs

No social layer. nsso has no feeds, followers, or engagement mechanics. That probably makes growth harder, but it protects the honesty of the profile from performance incentives.

Review Mode over full autonomy. Auto-applying changes would feel faster and more impressive, but public identity changes are high-trust. The review card adds friction deliberately.

Gemini Flash over a larger-context model. Flash keeps the product responsive and affordable, but richer cross-corpus synthesis would need a slower, larger-context model.

Fixed profile structure over unlimited flexibility. Users cannot invent every possible section type, but Links, Experiences, Qualifications, Projects, and Products & Services create a coherent identity architecture.

Dual-mode routing adds complexity. Separating knowledge and mutation paths reduces unsafe tool calls, but the arbitration layer becomes a critical component that needs measurement and classifier support.

The sales page CRO schema is a strong prior rather than a measured result. Fields such as value proposition, benefits, testimonials, and video embed are based on conversion-rate best practice, but no A/B test on the nsso user base has proved which combination converts best.

Demo / proof

The product is public, with Ramin's profile live as a working example of the identity surface.

The public profile demonstrates the identity surface, storefront-style project listings, and the guest-facing Deity entry point.

The live product includes the landing page username claim flow, public profile route, profile storefront surface, Deity guest access, payment/product surfaces, and the public Ramin profile as a working example.

The write-up points to concrete implementation evidence: Supabase profile context, Gemini 2.0 Flash, Gemini Embedding 001, Deity tool declarations, DOMPurify PayPal sanitation, @dnd-kit reordering, PayPal/Polar monetisation, and profile-aware retrieval.

This case documents Deity's runtime controls. The nsso Intros evaluation example used in teaching has a separate scope; production coverage for each Deity route needs its own evidence.

What I would improve

The intent router should be evaluated on labelled nsso queries before replacing the keyword switch. A classifier could distinguish profile edits from knowledge requests, with confidence thresholds calibrated on those examples and uncertain cases routed to a clarification.

The Deity turn pipeline needs structured observability: intent classification, retrieval hit rate, tool-call count, accepted actions, rejected actions, latency, confidence, and fallback path.

The tool-call parsing path needs regression coverage so a model output-format change cannot silently remove the profile-mutation layer while leaving normal chat responses intact.

The sales page CRO schema should be validated through analytics and A/B testing. Meta Pixel, Hotjar, Google Analytics, and similar integrations would help users understand how people interact with their profile and product pages.

The knowledge ingestion pipeline needs idempotency. Re-running context ingestion should upsert chunks rather than duplicating near-identical records in agent_knowledge.