Builders

The code behind two sites of the swegrowth community, built from one codebase and one Supabase database:

Site	What it is for
builders.swegrowth.id	Products members are building. A directory of every active product, filtered to the ones looking for help (engineer, designer, PM, researcher, writer, QA…); each product's story, stage, journey and open roles; and an activity feed of what those products did, with reactions.
oss.swegrowth.id	Open source. A directory of repositories taking contributors — ones we maintain, ones a member recommends with their reason, and members' products that take pull requests — plus an activity feed of members' pull requests, straight from GitHub.

Which site a deploy is comes from NEXT_PUBLIC_SITE at build time (builders by default, or oss; see app/lib/site.ts). Each site redirects the other's routes to it, and one sign-in works on both.

A profile, on either site, is the work with somebody's name on it: what they build and help build on builders, their open source record on oss.

Next.js on Netlify, with Supabase for both the database and sign-in.

builders.swegrowth.id · oss.swegrowth.id · Report a bug · Suggest an improvement

[!NOTE] Builders is under active development. The database schema and user-facing behavior may change while the project is still young.

Prerequisites

• Node.js >=22.13.0
• A Supabase project (free tier is plenty)

Quick start

npm install
cp .env.example .env.local   # fill in your Supabase URL and anon key
npm run dev                  # http://localhost:3000, the builders site
NEXT_PUBLIC_SITE=oss npm run dev   # the open source site

Without .env.local the site still runs: it serves the read-only seed from app/lib/seed.ts, so you can work on the pages without a database. Signing in and everything that writes will say so rather than failing quietly.

Setting up Supabase

1. Create a project at supabase.com.
2. Apply the files in supabase/migrations/ in filename order — with supabase link then supabase db push, or one by one in the SQL editor. Each file opens with a comment saying what it adds and why. The deploy tolerates running ahead of the database — a page loses the feature a missing table feeds rather than falling over, and says so in the server log — but nothing new works until they are applied. Make yourself a site admin afterwards, in the SQL editor: insert into public.site_admins (user_id) select id from public.profiles where username = '<you>';
3. Copy the project URL and the anon key from Project Settings → API into .env.local. Never put the service_role key in this app; it bypasses every policy.
4. Sign up through the site with your own email.
5. Optional: open supabase/seed.sql, change owner_email at the top to that same address, and run it. That imports the starting projects under your account.

Email confirmation is on by default in Supabase. The link it sends lands on /auth/confirm, which exchanges the PKCE authorization code for a session. The callback also accepts token_hash and type from a custom SSR email template. If you turn confirmation off, sign-up signs people straight in instead.

Google login

1. In Google Auth Platform, configure Branding and Audience, then make sure Data Access includes openid, userinfo.email, and userinfo.profile.
2. Create an OAuth 2.0 Web application client. Add each app origin under Authorized JavaScript origins (for example http://localhost:3000 and the production origin), then add Supabase's callback as an authorized redirect URI: https://<project-ref>.supabase.co/auth/v1/callback.
3. In Supabase, open Authentication → Providers → Google, enable it, then paste the Google client ID and client secret.
4. Under Authentication → URL Configuration, add both app callbacks to the Redirect URLs allow list, for every origin people reach the site on — the custom domain, the deploy URL behind it, and local:
   • <origin>/auth/callback
   • <origin>/auth/confirm

[!IMPORTANT] An empty or incomplete Redirect URLs list is the quietest way to break sign-in. Supabase does not report a rejected redirect_to; it silently falls back to the Site URL, so the authorization code arrives on a page that has no idea what to do with it and the person simply stays signed out. Only /auth/callback and /auth/confirm belong on that list. Nothing else in this app trades a code for a session — /get-started is where a successful sign-in lands, and putting it on the allow list would break the very flow it is meant to finish.

This is the beginning of the README. Read the rest at the original. Read the full README ↗