Rent your home to people you actually trust. A private, invitation-only rental platform built on real social networks — not anonymous reviews.
One Degree BNB is a private, invitation-only rental platform for your actual home — not a vacation unit. You only rent to people vouched for by someone you personally trust. No strangers. No platform guarantees. No 18% service fees. Just a simple tool to find great guests through your real network, handle the paperwork yourself, and keep more of what you earn.
Airbnb was built for strangers. That's fine for vacation rentals — but most people won't rent out their actual home, with their stuff in it, to a random person from the internet. The platform fees, regulations, and host anxiety all exist because there's no underlying trust.
Meanwhile, informal rentals between friends-of-friends happen all the time — over text, Facebook groups, and email lists. They work because trust is already there. One Degree BNB is the tool that makes those arrangements easier, not a platform that replaces them with algorithms.
You vouch for people you personally know. Guests can only be someone vouched for by a person you've already vouched for — one degree only.
Bad experience? The person who vouched takes a credibility hit — creating real social accountability before a rental ever happens.
Like Craigslist, but with trust baked in. One Degree doesn't guarantee the stay or mediate disputes — trust is doing the work Airbnb's fees pay for.
Private, invitation-only listings exist in a different legal category than public STR platforms. NYC, SF, and other regulated markets have minimum stay rules that apply to public listings. A closed vouch network likely falls outside those requirements — meaning hosts who can't list on Airbnb may be able to use One Degree. Verify with a real estate attorney.
One Degree BNB occupies a distinct position no existing platform has claimed — monetized, primary-home rental with trust as the core product.
| Dimension | Airbnb | Home Exchange | One Degree BNB |
|---|---|---|---|
| Trust model | Stranger + reviews | Mutual exchange | Vouched network |
| Home type | Vacation unit | Primary home | Primary home |
| Monetization | Yes | No (swap only) | Yes |
| STR regulations | Subject to rules | Usually exempt | Likely exempt |
| Platform fees | 18%+ service fee | Membership | Low / flexible |
| Mediation | Platform guarantees | Platform involved | DIY / none |
Sequenced to prove the network before building the marketplace. Each phase has a clear gate — don't proceed until it validates.
Talk to 20 potential hosts. Understand the pain, test the trust concept, find the seed community. Your Putnam Valley house and Brooklyn apartment are live testing grounds.
Gate: 8+ of 20 interviewees express strong intent. 5+ give referrals unprompted.
One page explaining the concept with host/guest segmented email capture. Start building the network before the product exists.
100+ waitlist signups in 30 days. Majority are hosts.
Private listings, invite codes, basic profiles, contact flow. No booking engine — prove the network works before building marketplace infrastructure.
10 active listings. 3+ completed rentals facilitated through the platform.
The vouch system becomes queryable, DIY toolkit reduces friction, trust graph generates network effects.
25+ active hosts. Organic referrals without prompting. At least one user unknown to you before they signed up.
Only after the network is self-sustaining. Monetization before PMF kills early marketplaces.
The trust graph has value beyond rentals. A verified vouched network could power neighbor lending, service referrals, or peer transactions. Phase 4 is when you decide: stay niche and profitable, or raise and scale.
| Layer | Tool | Why |
|---|---|---|
| Frontend + API | Next.js | Full-stack, real codebase you own, Cloudflare Pages deploy |
| Database + Auth | Supabase | Relational DB (required for trust graph), auth, file storage, real-time |
| Identity | Clerk | Social login + user management without building auth from scratch |
| Payments | Stripe | Deposit holds, payment links, eventual subscriptions |
| AI features | Claude API | Contract generation, insurance guidance, onboarding flows |
| Deploy | Cloudflare Pages | Already in your pipeline — push to deploy on bbase.ai |
| Build tool | Claude Code + Cursor | Vibe-code the structure; Claude Code for complex multi-file work |
A trust graph with user auth, relational vouching data, and payment flows needs a real schema from day one. Lovable-style tools produce a black-box codebase you can't extend cleanly past Phase 2. Next.js + Supabase means every phase builds on what came before.
The goal of Phase 0 isn't to validate the tech — it's to validate the network. Find people already doing informal rentals and understand what's stopping them.
You have a house upstate and are getting a city apartment — both are live testing grounds. Start with who you'd personally vouch for in those rentals. Those people are your first interviews and your first nodes in the trust graph.
Someone who stopped hosting on Airbnb due to regulations or a bad experience and is now managing rentals informally over text. They already know the problem you're solving.
Two goals: validate the problem, understand the trust dynamic. You're not pitching — you're listening. Record with permission.
Give the 30-second elevator pitch. Then:
After 10 interviews, pause and look for patterns before the next 10. The second batch should go deeper on what you learned in the first.
| Question | How to Answer |
|---|---|
| Does NYC's STR law exempt private, invite-only listings? | STR attorney consultation |
| What do standard leases say about subletting to personal friends? | Legal research + interviews |
| How did Couchsurfing's vouch system work — and why did it decline? | Desk research + CS forums |
| What fee model would hosts actually pay? | Direct question in interviews (Q7–8) |
| What's the minimum viable DIY toolkit? | Ask hosts what they'd need (Q8) |
| How many degrees before trust breaks down? | Test in interviews (Q5) |
Everything Claude Code needs to start building. Context, architecture decisions, Phase 1 prompt, and known issues to fix first.
One Degree BNB is a private, invitation-only home rental platform where you can only rent to people vouched for by someone you personally trust — one degree of separation only. It's being built by Loren Polster, founder of Brightbase, a B2B SaaS creative agency based in Brooklyn, NY.
| Item | Status |
|---|---|
| Concept | Defined — see Doc 1 |
| Phase 0 research | Not yet started — interviews to begin |
| Landing page | Not built — Phase 1 task |
| This Phase 0 HTML doc | Anchor links broken — fix needed (see Section 02) |
| Domain | TBD — onedegreebnb.com or subdomain on bbase.ai |
| Codebase | Not started — greenfield |
projectname.bbase.aiThe Phase 0 HTML doc (Doc 1 in this file) has broken TOC anchor links. Clicking a link scrolls to the section but it remains invisible. This needs to be fixed before this file is shared with interviewees.
Sections use a .fade-in class that starts at opacity: 0; transform: translateY(12px). The IntersectionObserver approach was attempted but the threshold isn't triggering reliably when navigating via anchor link (the section is already in view but was never "intersected" from off-screen). The browser scrolls to the element, but it stays invisible.
Simplest and most reliable approach — remove the IntersectionObserver entirely and handle it one of two ways:
/* Remove JS observer entirely. Use CSS animation on sections */
.section {
animation: fadeUp 0.4s ease both;
}
.section:nth-child(2) { animation-delay: 0.05s; }
.section:nth-child(3) { animation-delay: 0.10s; }
/* etc... or just remove animation entirely for a document */
@keyframes fadeUp {
from { opacity: 0; transform: translateY(8px); }
to { opacity: 1; transform: translateY(0); }
}This is a reference document, not a landing page. Remove .fade-in from all section containers and delete the JS observer. Clean, fast, no issues.
Once Phase 0 research validates the concept, use this prompt in Claude Code to kick off the landing page build.
Create a new GitHub repo under bbagent-01, clone it into VS Code, and connect it to a new Cloudflare Pages project pointed at bbase.ai. Then open Claude Code in the VS Code sidebar and paste the prompt below.
| Layer | Choice | Notes |
|---|---|---|
| Framework | Next.js 14 (App Router) | Full-stack, real codebase, Cloudflare Pages compatible via next-on-pages |
| Database | Supabase (PostgreSQL) | Relational is required — the trust graph is a graph traversal query on a relational schema, not a document store |
| Auth | Clerk | Handles social login, session management, webhooks to sync users to Supabase |
| Storage | Supabase Storage | Listing photos, profile photos — keep in same infra as DB |
| Payments | Stripe | Phase 3+ only — deposit holds via PaymentIntents with capture later |
| AI | Claude API (Sonnet) | Contract generation (Phase 3), insurance guidance, onboarding flows |
| Styling | Tailwind CSS | BB Base Theme palette configured in tailwind.config — no gradients, no dark mode |
| Deploy | Cloudflare Pages | Auto-deploy on push to main via GitHub (bbagent-01). Custom domain on bbase.ai |
| Resend | Transactional email (vouch requests, booking confirmations) — add in Phase 2 |
A dedicated graph DB (Neo4j, etc.) is overkill for 1-degree queries. Supabase with a properly indexed vouches table and a recursive CTE query will handle "who has vouched for this person, and who vouched for the voucher" efficiently at the scale this will reach before needing to revisit.
Every listing route checks auth + vouch relationship before rendering. There is no public listing index. No SEO, no robots.txt entry for listing pages. This is both the product differentiator and the regulatory protection.
Guests cannot self-register. A host generates an invite link (signed JWT with host_id, expires in 7 days) and shares it. The recipient clicks it, creates an account, and is automatically connected to the host's trust network. This enforces the 1-degree rule at the infrastructure level, not just the UI level.
Phase 2 provides a contact form that emails the host. Payment (Venmo/Zelle/etc.) and contract (their own or generated template) happen outside the app. This ships faster and keeps liability off the platform while the model is being validated. Stripe + in-app booking are Phase 3.
Supabase migration to create at project init. Designed to support the trust graph from day one — don't simplify this or you'll need a painful migration at Phase 3.
-- Users (synced from Clerk via webhook)
create table users (
id uuid primary key default gen_random_uuid(),
clerk_id text unique not null,
name text not null,
email text unique not null,
avatar_url text,
bio text,
role text check (role in ('host', 'guest', 'both')),
created_at timestamptz default now()
);
-- Vouches (the trust graph edges)
create table vouches (
id uuid primary key default gen_random_uuid(),
voucher_id uuid references users(id) on delete cascade,
vouchee_id uuid references users(id) on delete cascade,
strength text check (strength in ('very_close', 'close', 'acquaintance')),
note text,
created_at timestamptz default now(),
unique (voucher_id, vouchee_id)
);
-- Listings
create table listings (
id uuid primary key default gen_random_uuid(),
host_id uuid references users(id) on delete cascade,
title text not null,
description text,
location_city text,
location_state text,
nightly_rate integer, -- cents
min_vouch_strength text check (min_vouch_strength in ('very_close', 'close', 'acquaintance')),
available_from date,
available_to date,
is_active boolean default true,
created_at timestamptz default now()
);
-- Listing photos
create table listing_photos (
id uuid primary key default gen_random_uuid(),
listing_id uuid references listings(id) on delete cascade,
url text not null,
sort_order integer default 0
);
-- Invite links (signed tokens for guest onboarding)
create table invite_links (
id uuid primary key default gen_random_uuid(),
host_id uuid references users(id) on delete cascade,
token text unique not null,
used_by uuid references users(id),
expires_at timestamptz,
created_at timestamptz default now()
);
-- Contact requests (Phase 2 — no booking engine yet)
create table contact_requests (
id uuid primary key default gen_random_uuid(),
listing_id uuid references listings(id),
guest_id uuid references users(id),
message text,
check_in date,
check_out date,
status text check (status in ('pending', 'accepted', 'declined')) default 'pending',
created_at timestamptz default now()
);
-- Indexes for trust graph queries
create index idx_vouches_voucher on vouches(voucher_id);
create index idx_vouches_vouchee on vouches(vouchee_id);
create index idx_listings_host on listings(host_id);Use this pattern to check if a viewer can see a listing. Run server-side in a Supabase RPC or Next.js API route.
-- Can user :viewer_id see listing owned by :host_id?
-- Yes if: viewer has been vouched for by someone host has vouched for
select exists (
select 1
from vouches v1 -- host vouches for person X
join vouches v2 -- person X vouches for viewer
on v2.voucher_id = v1.vouchee_id
and v2.vouchee_id = :viewer_id
where v1.voucher_id = :host_id
) as can_view;Loren's standard pipeline — already working for other projects. Replicate this pattern for One Degree BNB.
bbagent-01onedegree-bnbonedegree-bnb reponpx @cloudflare/next-on-pages.vercel/output/staticonedegree.bbase.ai (or final domain later)NEXT_PUBLIC_SUPABASE_URLNEXT_PUBLIC_SUPABASE_ANON_KEYSUPABASE_SERVICE_ROLE_KEY (server only — do NOT prefix with NEXT_PUBLIC)NEXT_PUBLIC_CLERK_PUBLISHABLE_KEYCLERK_SECRET_KEYmain → Cloudflare Pages auto-deploys in ~60 secondsonedegree.bbase.aiLoren's standing rules for any Claude Code or automation work. These apply to all builds.
A broken loop cost $92 in one morning on 3/20/26. For any automation, agent, or script that calls a paid API: (1) hard loop counter that kills after N iterations, (2) estimate and confirm max cost before execution, (3) never silence errors on paid API calls during testing, (4) test with ONE item first, not full dataset. Budget ceiling: $2/run, $15/month for any single agent.
scroll-padding-top on html must account for the sticky nav height.