Building ScopeCheck
in public.

The first /demo layout put the score at the top of the right column. But an empty donut at 0/100 tells a founder nothing. They have to figure out they need to scroll down and start typing before anything happens.

Redesigned around one principle: act first, see reward second. The form is now at the top of the right column — you land on the page and can immediately start filling in your startup. The fit score moves to a full-width panel below both columns. It bridges the two sides visually, because that's what it does functionally: it's the relationship between the investor criteria and your passport.

Other polish: investor name is now inline with firm at 14px ("Alex Farcet · Raspberry Ventures") — less prominent, and generalises correctly whether the investor is an individual, a syndicate, or a fund. The CTA button is locked/grey until name, company, one-liner, and stage are filled — then flips to amber and unlocks. The hero subtitle changed to: "Complete your passport, get your live matching score." — instructional, not descriptive.

The grey box that was appearing at the bottom left (grid background showing through when the right column was shorter) is fixed — right column is now flex column, CTA pins to bottom.

Entry #021 ended with a question: how do you show the inline apply flow is the killer feature before someone clicks?

The answer isn't an animation or a video — it's a page where you can experience it yourself. /demo puts a real investor scope (Raspberry Ventures) on the left and a founder form on the right. As you fill in your startup, a fit score reacts in real time — sector match, stage, geography, traction — broken into six categories with a donut and progress bars.

The score is mocked for now. Sector match against "ClimateTech / Applied AI" lifts it. Seed/Early-A stage lifts it. European geography lifts it. Wrong answers show amber or grey bars honestly — it doesn't pretend everything fits. The label says "★ AI scoring · coming soon" because that's the truth.

When name, company, one-liner, and stage are filled, the CTA unlocks: "send real intro to Alex Farcet →". It takes you to the live scope. Founders who complete the demo have already drafted their intro — clicking through takes 10 seconds.

The passport URL previews live in the header as the company name is typed. Small detail, but it makes the "you're building something" feeling immediate.

Tested the full founder journey as af@rainmaking.io and found three bugs.

First: upsert was throwing a constraint error on return visits. The founders table had no unique constraint on user_id, so ON CONFLICT (user_id) had nothing to conflict on. Fix: ALTER TABLE founders ADD CONSTRAINT founders_user_id_key UNIQUE (user_id). One line of SQL.

Second: the nav on /i/[handle] was showing "dashboard" regardless of who was signed in. A founder who's never created an investor scope shouldn't see a pipeline link. Fixed loadUserContext() to detect investor/founder/both role using the same email fallback pattern as the homepage. The nav now renders the right button for the right person.

Third: returning founders saw a blank form. The form was always initialised to empty state — it never fetched the existing passport. Now loadUserContext() pulls the full founder record from Supabase on session load and populates every field. The button label changes to "send intro (pre-filled) →" when you're signed in. Second visit is genuinely faster than the first.

Two bugs discovered in the same session.

Bug 1: the homepage nav was showing "define scope →" instead of "pipeline →" even when signed in as the investor. Root cause: resolveSession was querying the investors table by user_id only. The raspberrysyndicate row in Supabase was created before user_id was stored — so the lookup returned null, role resolved to null, wrong button appeared. Fix: added email fallback — if user_id lookup returns nothing, try matching by email. Also found three duplicate rows in the investors table from earlier iterations; cleaned to one.

Bug 2: founder applications were landing in email but not in the database. The send-intro API route was sending the notification email but had no Supabase write. The dashboard was displaying MOCK_APPLICATIONS — a constant that was never replaced with a real query. Fix: send-intro now inserts to an intros table (new, with RLS). Dashboard fetches real data. The mock constant is gone.

Both bugs were invisible in normal use — the email notification made it feel like things were working. The database was the silent gap.

Ended today's session with a clear product question for tomorrow: how do you show that a founder can apply to an investor directly from their scope page?

Right now the homepage explains what the product does, but doesn't demonstrate the moment of value. That moment is: a founder lands on an investor's scope, sees that they match, and hits send — without leaving the page, without signing up first, without a separate application form.

That's not a feature. That's the product. Everything else — passports, kanban, /for-llm — is infrastructure that makes that moment better over time.

The homepage currently treats investors and founders symmetrically. The inline apply flow breaks that symmetry in the most useful way: it makes the investor's scope page the acquisition channel for founders. Every scope is a landing page. Every send intro is a founder onboarded.

The question for Monday: how do you make that visible before someone clicks.

A focused session on the logged-in experience:

Sign out: added to the homepage nav and both dashboards. Previously you had to clear cookies to switch accounts.

Copy icon: replaced the text-label "copy" button with a Google-style two-stacked-pages SVG icon. Flips to a checkmark (amber) for 2 seconds on click. Clean, no label needed.

Owner view on scope page: when you visit your own /i/handle signed in, you no longer see the "send intro" button. Instead you see your profile URL with a copy icon, plus pipeline and edit scope links. The page now knows if you're the owner.

Nav identity: email and sign out are now grouped as a single bordered unit — `email | sign out`. Cleaner than having the email floating between two buttons.

Edit scope pre-fills: clicking "edit scope" now loads your existing data into the form. Previously it showed a blank form.

The example investor card on the homepage was pointing to a static demo. Replaced with the live /i/raspberrysyndicate scope — Alex Farcet / Raspberry Ventures.

The reasoning: a demo that works is better than a demo that looks like it works. A founder landing on the homepage can now click "send intro" on the example card and actually send an intro. That intro will land in the real kanban. The demo is the product.

Also replaced the dead QR and /for-llm buttons with live versions. The QR renders the actual URL. The /for-llm link opens the machine-readable criteria page. Both are real infrastructure, not mockups.

Small copy change in "how it works": removed the line about finding investors on ScopeCheck. Founders share their passport — they don't need to find investors here first. The product works when founders bring the link to investors, not just the other way round.

The killer insight from today's product session: a founder visiting an investor scope shouldn't have to navigate away to apply. The scope page is now a complete transaction.

Click "send intro", a form slides open inline. Investor criteria on one side, your response fields on the other. Hit send — three things happen simultaneously: intro lands in the investor's kanban, investor gets notified, and your startup passport is created at scopecheck.ai/f/yourcompany.

You get the passport link right there to copy and share with the next investor. Fields pre-fill on every subsequent scope you visit.

The passport isn't a prerequisite for applying. It's the reward for applying.

A cynical view of the MVP: this is a lot of infrastructure for something you could do with a Google Form.

The answer: Google Forms can't score fit. Can't pre-fill fields from a saved passport. Can't build match intelligence from structured data over time. The schema is the moat.

But the more important reframe is the multiplier. A founder doesn't send one intro — they send thirty. A good investor scope doesn't filter one founder — it filters two hundred. The value is in the one-to-many, on both sides simultaneously.

This also clarifies the product arc: structured data now → fit scoring next → proactive matching later. Each layer is only possible because the previous one exists.

Spent time today on language. The original CTAs said "create investor profile" and "create founder passport" — both used "create", which is neutral to the point of saying nothing.

Investors define. They're drawing a boundary around what they look for. It's a filtering act.
Founders build. They're assembling a story, putting together something that represents them.

Different verbs, different audiences, same rhythm. "Define your scope. Build your passport." That became the new tagline — and it writes the CTAs for free.

Three things in one build session:

/i/ prefix added for investors (scopecheck.ai/i/handle), mirroring /f/ for founders. Old URLs redirect automatically — no broken links.

Kanban cards: the left-border colour accent was disappearing on expand/collapse due to conditional border logic. Fixed to always show the column colour. Also added full bidirectional movement — you can move a startup back from Considering to New if you change your mind.

Dashboard auth guard: the kanban was accessible without being signed in. Now redirects to /scope if no active session.

A few naming and navigation fixes from user testing (user #001 = me):

"Founder passport" → "startup passport". The passport belongs to the startup and its fundraising round, not the individual founder. Subtle but it matters for Series A+ where there are multiple co-founders.

"Create investor profile" → "Define your investor scope". The button now says what the action actually does.

Nav: when signed in, the top nav now shows Dashboard and My Scope links. Previously you had to scroll to section 03 to find your way back in. Obvious in retrospect.

Sign out: added to /scope and /passport so you can switch accounts without clearing cookies manually.

Classic OAuth gotcha. After setting up Google Sign-In, successful auth was bouncing users back to localhost instead of scopecheck.ai.

Two fixes: set Site URL in Supabase to https://scopecheck.ai, and add it to the allowed redirect URLs. Thirty seconds once you know where to look.

Also caught a subtler bug — session detection on /scope and /passport was using useState instead of useEffect, so the post-OAuth redirect wasn't being caught. Swapped in useEffect with onAuthStateChange. Clean flow now.

Proper Google Sign-In requires touching four systems: Google Cloud Console (project, consent screen, OAuth credentials), Supabase (enable provider, paste credentials), DNS (done), and codebase (done).

The consent screen setup has four steps and asks Internal vs External. External is right — you want any Google account to work, not just raspberry.ventures users.

One gotcha: the Supabase callback URL must be registered in Google Cloud, otherwise auth silently fails. Worth noting for anyone setting this up.

Early version had a waitlist gate — submit your email, wait to be let in. Classic early-stage instinct: control quality, avoid spam.

But at zero users, that logic is backwards. Every extra step is a reason to leave. The waitlist implied scarcity we didn't have yet.

Replaced both CTAs with direct onboarding: /scope for investors, /passport for founders. No gate. Sign in with Google, fill in your criteria, get your link.

The word "join" was also wrong for investors. Busy, senior people don't join things. They define their scope. Hence /scope.

Deployed. GitHub to Vercel to Cloudflare DNS to SSL certificate generated. The full chain in under an hour.

Vercel auto-detects Next.js, pulls from GitHub on every push, redeploys in ~60 seconds. Cloudflare holds the domain — key thing is setting DNS records to proxy-off (grey cloud, not orange) so Vercel handles SSL itself. Orange cloud breaks the SSL handshake.

At this point profiles are static demo data. The next session makes them data-driven so real users see their own content.

The first design pass used terminal green — the kind you see on dev tools everywhere. Looked right technically, but felt wrong. Too generic. Then it clicked: I run Raspberry Ventures. Raspberry is literally my favourite fruit. The brand colour was sitting right there the whole time.

So we switched. Dark background, raspberry #d4286a as primary, warm amber for data highlights. The blinking cursor at the terminal prompt is raspberry-coloured. Small detail, but it makes me smile every time I look at it.

Phase 0 through Phase 4 is coded and building clean. Next.js app router, Supabase schema ready to run, all routes stubbed:

/[handle] — investor profile with QR
/[handle]/apply — founder application form
/[handle]/for-llm — machine readable criteria
/f/[handle] — founder passport
/dashboard — investor kanban
/log — this page

The kanban triage is satisfying. Thumbs up moves a deal to considering, thumbs down fires a rejection email using the investor's own template. Simple and fast.

Stack: Next.js 15 + Supabase + Vercel. No native app — QR display is a full-screen tap on the mobile web page. That's 90% of the value for near-zero build cost.

Every investor and founder profile auto-generates a plain-text machine-readable version at /for-llm. No HTML, no styling — just clean key: value pairs that any LLM or search crawler can parse without effort.

This is the AI-native angle made tangible. Right now it's just a page. In two years, it's how AI deal-sourcing agents discover and match investors with founders without anyone filling in a form.

We build it now because retrofitting AI readability later is always harder. And honestly, the /for-llm link at the bottom of every profile is a small signal that tells the right kind of person: this was built by someone who thinks about where this is going.

Someone asked if this needs a native app. It doesn't — and building one would be a mistake at this stage.

Here's the use case: founder is at a networking event, meets an investor. They want to share their passport instantly. Pulling up scopecheck.ai/f/yourcompany on your phone and tapping "Show QR" fills the screen with a scannable code. The investor's phone camera reads it, lands on the passport page.

That interaction takes 4 seconds. A native app would take 4 minutes to explain and install.

PWA (installable web app) comes later. For now, mobile-optimised web + a full-screen QR tap is everything the use case needs.

The honest tension in this product: founders have the most pain (filling in the same info 50 times, applying into black boxes) but they're notoriously hard to monetise. Investors have a real operational pain too but they're slower to adopt new tools.

The answer: build for founders first because they drive the flywheel. A founder creates their passport, shares scopecheck.ai/f/theircompany with investors, an investor clicks it and thinks "I want one of these for my inbound." That's a product-led growth loop that doesn't require cold sales.

The "what we're looking for in an investor" field on the founder passport is a deliberate choice. Most tools don't ask founders what they want. That signal — this product respects you — is what makes founders share it enthusiastically.

The positioning clicked when I stopped thinking about this as a platform and started thinking about it as a smarter link.

bit.ly shortens URLs. ScopeCheck makes URLs carry structured context. An investor's link isn't just a webpage — it's a machine-readable description of exactly what they're looking for. A founder's link isn't just a profile — it's a portable pitch that pre-fills application forms anywhere.

This framing changes what you build. You're not building a marketplace. You're building infrastructure. The difference matters for how you talk about it, how you distribute it, and what success looks like in year 3.

I get 20+ founder messages a week. Every single one lands differently — LinkedIn DM, WhatsApp forward, cold email, intro from a mutual connection. There's no structure. No memory. No way to triage efficiently.

Meanwhile I watch founders spend hours crafting cold outreach into black boxes. They don't know if they fit. They don't know if anyone read it. They fill in the same information 50 different times.

The weird thing: every investor builds the same intake process from scratch. Every syndicate lead has the same "we invest in world-changing founders" page that says nothing. Every solo GP is drowning in WhatsApp deal flow with no infrastructure to handle it.

I already built a manual version of this on my own site — my Scope Check page. Today I bought scopecheck.ai. Let's build it properly.