Projects using TypeScript in BansteadProjects using TypeScript in BansteadExcited to share some of the backend work I've been doing lately with Supabase! 🚀
Here's a look at what went into building a production-ready backend from scratch:
🗄️ Database Schema Design
Designed a relational schema with multiple interconnected tables: profiles, notes, reminders, conflicts, and a dedicated user_keys table for encryption key management. Every table has proper foreign key relationships, timestamps, and nullable/non-nullable constraints enforced at the DB level.
🔒 Row Level Security (RLS)
Every single table has RLS enabled with two policies: users can only access their own rows, and anonymous access is blocked entirely. No exceptions. Security is enforced at the database layer, not just the application layer.
🔑 Auth & Email Flows
Set up Supabase Auth with email + OAuth support, including full PKCE flow for secure token exchange. Configured deep link redirects for email confirmation and password reset flows, all tested end to end.
⚡ Edge Functions
Built and deployed multiple Supabase Edge Functions handling AI processing pipelines, including JWT validation at the top of every function before any processing begins. The OpenAI API key lives exclusively in Supabase secrets, never in the app or any config file.
🔄 Merge Pipeline
Built a follow-up note merge pipeline as an Edge Function. New facts are appended to existing profiles, duplicates are detected and skipped, conflicts are logged, and resolved reminders are handled gracefully.
📦 Migrations
All schema changes go through versioned migration files under source control. No manual dashboard changes. CI/CD triggers migrations automatically on merge to main.
🔐 Encryption Architecture
Client-side AES-GCM encryption via CryptoKit. Plaintext never sits in the database. Encryption keys are stored in a dedicated RLS-scoped table, fetched after login, and held in memory only for the session duration.
Still a lot more to share about this project. Excited to talk about it publicly when it launches! 👀 I built a working AI recruitment screening demo that shows how a hiring team can use AI without handing over the final decision.
The flow is simple:
A job spec goes in.
Candidate profiles are screened against a weighted guideline.
Each candidate gets a score, band, evidence quotes, and risk flags.
Then everything stops at a human review queue.
No auto-rejects. No silent ATS updates. No “AI decided this person is out”.
The system includes:
Candidate pipeline table
Evidence-based screening view
Human review queue
Approve / reject / snooze decisions
ATS deployment plan
Audit log for compliance
n8n workflow export with a human-in-the-loop Wait node
Optional live Claude screening path
The important part is the architecture: deterministic logic owns the workflow, gating, state and audit trail. The AI helps with judgement and screening, but the human owns the final decision.
Built with Next.js, TypeScript, Claude API, n8n workflow architecture, and a gated ATS sync pattern.
This is the kind of system I like building: AI that makes the work faster, but still respects the places where people need control.
Shorter Version
I built an AI recruitment screening pipeline with a human approval gate.
It screens candidates against a rubric, shows evidence quotes and risk flags, then routes every candidate into a review queue before anything reaches the ATS.
No auto-rejects. No silent updates. Human-in-the-loop by design.
Built with Next.js, TypeScript, Claude API and n8n workflow architecture. Hunter
Automate anything with a UI · structured actions at scale against no-API platforms
Half the platforms that matter to a business have no public API. Indeed, LinkedIn, Companies House, supplier portals, council planning sites, competitor dashboards. The data is right there on the screen, the action you need to take is a click away, but you can't get to it programmatically without scraping, and scraping breaks every time the platform updates.
Hunter solves that, properly.
It drives the real browser against the real API behind the UI, using the real session cookies. Same calls the platform's own frontend makes. Drift-resistant by construction. Built originally as a self-hosted Indeed controller running 1,000+ applications a week, the same pattern is live against LinkedIn and Contra, and works against any platform with a JS frontend and a backend API.
What you get
Programmatic access to any web product, including ones with no public API
Drift detection that alerts you before changes upstream break the flow
A pipeline rather than a spreadsheet: every action tracked, retried, audited
Native rate limiting and session handling so the platform doesn't notice
A general capability layer rather than a one-off scraper
Who it's for
Recruitment teams sourcing or applying at scale. Lead-gen teams hitting platforms that won't sell API access. Compliance, planning, or research teams pulling from government and corporate portals. Any operation where "we'd love to automate X but the vendor doesn't support it" is the blocker.
What it replaces
A team of VAs clicking through portals, a brittle scraper that breaks every fortnight, or a project that never got started because "there's no API." Hunter ships the capability and survives the platform's next UI change.
Production reality
The Indeed deployment runs 1,000+ structured applications a week with cover letters generated per posting. Same controller pattern is live against LinkedIn and Contra in parallel. Drift on the backend is detected at the schema layer, not the rendered HTML, so a Contra UI redesign doesn't break the integration.
