Inreachly OS: an independent look at the system before you sell it to other people

Any customer can read every other customer's prospect list

Three tables holding prospect emails and mobile numbers are readable by any logged-in user of any workspace. This is not an exploit — it is the normal database API doing exactly what its rules permit.

Supabase publishes your database directly to the internet as an API. There is no server code standing in front of it. The only thing that stops customer A reading customer B's rows is a set of per-table rules called Row Level Security — think of a doorman standing on each table, checking every row before handing it over.

On three of your tables the doorman has been told to let everyone through. The rule literally reads USING (true), which means "yes, to anyone who is logged in". The tables are pipeline_businesses, pipeline_contacts and pipeline_owners. Between them they hold email, mobile_phone, store_phone, owner_name, first_name and last_name.

There is a second problem underneath the first, and it is the one that actually matters. None of those three tables has a workspace_id column. There is no field on the row saying which customer it belongs to. So this is not a case of someone writing a lazy rule that can be tightened in an afternoon — a correct rule *cannot be written* until the column exists. The permissive rule and the missing column are the same defect wearing two hats.

The same pattern appears on api_usage_tracking, where the rule is auth.role() = 'authenticated'. That checks the visitor is logged in and then treats being logged in as permission. Every customer can see every other customer's API consumption — a direct read on a competitor's volume and spend.

The check that decides whether a change is safe to merge examines nothing, and says yes

You built a merge-readiness gate. Because of one line, it filters its list of required checks down to empty for almost every kind of change — and an empty list counts as everything passing.

The script that decides whether a change is ready to merge holds a list of the checks it considers its responsibility. That list contains exactly one item: Supabase Preview.

For any change that is not a database migration, the gate takes the checks that ought to apply, keeps only the ones on its own list, and is left with nothing. It then asks "did anything fail?", finds nothing, and reports success.

This is not a theory. The reviewer ran your own script against a simulated live-send change with every routed check explicitly failing, and got back:

{"ready": true,
 "reason": "all required checks passed",
 "required_checks": [],
 "failed_checks": []}

There is a second, independent proof that costs nothing to check. The gate is configured to wait up to 40 minutes for checks to settle. Its actual median runtime is 25 seconds, with 99 of the last 100 runs finishing in under two minutes. It is not waiting for your tests. It has nothing to wait for.

The reason this happened is visible in a comment in the file: the author assumed the real enforcement lived in GitHub's branch protection settings, and that this script only needed to cover the one check protection did not. That assumption may even have been true once. Nothing verifies it now.

Your database cannot record that someone unsubscribed

There is no do-not-contact list anywhere in the system, and the lead table is configured in a way that physically rejects the value "unsubscribed". A prospect who opts out still has their remaining follow-ups queued.

This is the most serious finding in the review, and it is not a bug in the ordinary sense — it is a missing part.

Across all 176 tables there is no suppression list, no do-not-contact table, no blocklist. The word does not appear in your schema once.

Worse, the lead record has a rule listing the statuses a lead is allowed to have. That list contains seventeen values. unsubscribed and do_not_contact are not among them — attempting to store either is rejected by the database.

So when someone unsubscribes, here is what actually happens: a counter on the campaign is incremented, a daily metric is updated, and a row appears in the inbox so an operator could filter for it. The lead itself is not touched. Their queued follow-ups remain approved, with send times in the future.

The code says so itself: *"Bison already unsubscribed the lead on its side; this gives operators a filterable tag in the inbox."* The whole design assumes your sending provider is handling it.

And that assumption has a hole in it that nobody can close from inside this repository. Your follow-ups are not sent through the campaign channel. They are sent as threaded replies to a different endpoint. Whether your provider applies its unsubscribe list to *that* endpoint is not documented anywhere in your code.

There is a knock-on effect too: because these statuses cannot exist, a recovery guard that filters on them is checking for values that can never be present — dead code that reads as a safety check.

You built the safe sending path, and then left it switched off by default

There are two send paths. One is genuinely excellent. The other can send the same email twice after a dropped connection — and it is the one every new customer gets.

Start with the good news, because it is substantial. Your newer sending path — the "spine" — does this properly. It claims the send in the database in a way that can only succeed once, so a retry physically cannot reach the provider a second time. It takes a fingerprint of the email body and refuses to send if anything changed. When an outcome is genuinely unknown, it stops rather than guessing. That is textbook, and it is better than most platforms manage.

The problem is that this path only runs for workspaces on an allow-list, and the allow-list defaults to empty. A new customer is on the older path until somebody edits an environment variable and redeploys. There is nothing in the product that makes this visible.

On that older path, the send function is called without the idempotency key it accepts — so the safety header is never sent. And its error handling catches everything and treats it all the same way.

That last part matters more than it sounds. Your codebase already draws the correct distinction: it has one error type meaning *the provider definitely rejected this*, and another meaning *we do not know whether it went out*. Lost connections, timeouts and server errors are all correctly classified as unknown. The older path checks for neither. It reverts the email to "ready to send" and reports that you can retry.

The background job then retries, five seconds later, and because nothing about the record changed, it claims it again and sends again.

When bounce rates spike, the system sends a Slack message and keeps going

There is no automatic pause anywhere. Spam complaints are not even subscribed to. The bounce check runs once a day, at eleven at night.

Two related gaps here.

Spam complaints do not reach you at all. The list of events subscribed to from your provider covers replies, sends, bounces, unsubscribes and account changes. Spam reports are not on it. There is code elsewhere that handles a complaint category — but it can never run, because no complaint event ever arrives. Unrecognised events are logged and answered with success.

Bounces arrive, but nothing acts on them. The handler increments counters and files an inbox row. The bounced recipient is never marked. Then a separate daily job checks whether the bounce rate crossed 2%, and if it has, it posts to Slack and applies a tag reading Monitor to the affected mailboxes.

A tag is a label. It changes nothing. Searching the entire alerting module for anything that pauses, stops, disables or deactivates returns two results: a log line, and the text of the Slack message itself, which reads *"Consider pausing affected accounts"*.

The one function in the codebase that can pause a campaign creates a recommendation that requires human approval.

The timing compounds it. The check runs at 23:00, once per day.

370MB of fourteen clients' real prospect data is committed in your repository, permanently

Tens of thousands of real people's names, emails, phone numbers and addresses are in the code repository — including two clients you offboarded four months ago. Anyone who has ever cloned it holds a full copy.

The clients/ folder holds 653 files and around 370MB of real production lead data across fourteen named client folders. One client alone accounts for 348MB.

The fields are unambiguous personal data: owner first and last names, email addresses, store and mobile phone numbers, business addresses, Facebook profile URLs, job titles and locations.

Two of those fourteen clients were offboarded four months ago. Their prospect databases are still in your repository, and will remain there permanently regardless of what you delete today, because git keeps everything.

One genuinely important mitigation, which was checked rather than assumed: your .railwayignore excludes clients/, so your production containers do not carry this data. The exposure is people who clone the repository, not your live application. That is a meaningful difference and it lowers the severity from what it first appears.

But the set of people who clone it is growing. It now includes an external contractor added last week, and it will include every developer you hire. None of that leaves an audit trail on the client side.

You are generating claims about named businesses' regulatory violations with a language model

Campaign copy references specific FDA enforcement actions and state penalties against named businesses, as a pressure hook. In the current pipeline those sentences are written by a model, not looked up — and the technique has been generalised into your reusable skill library.

The lead records pair named businesses with regulatory enforcement detail — fda_charges, fda_outcome, FDA_VIOLATION_TYPE, fda_inspection_date — and campaign variables named STATE_LAW_HOOK, STATE_PENALTY_DETAIL and FDA_TIMING_PHRASE place them into outreach copy. The resulting message tells a business owner about their own violation and what it might cost them.

Two things make this materially worse than it first looks, and one of them is a correction to an earlier read of the code.

First: these sentences are now generated by a language model. The original pipeline built them with deterministic string matching — a lookup table, effectively. The newer manifest-driven pipeline defines three blocks of type ai-personalise producing exactly those three variables, which resolve to a GPT-4o-mini call. So the sentence asserting a named business committed a specific regulatory offence is written by a model rather than read from a record.

Second: the record it draws on is matched by fuzzy comparison. Records are joined to FDA data by a similarity score with a 0.6 threshold, and the cleaning step has a default fallback. Between a loose match and a generative sentence, there is no remaining guarantee that the violation described actually belongs to the business receiving the email.

Third, and this is the part that changes its nature: the technique is not confined to one client. It has been written up and generalised into your shipped skill library, which means it is a documented, reusable play in the platform you are about to sell to twenty to fifty other companies.

On one table, a customer can change another customer's records

ai_recommendations allows any logged-in user to update any row belonging to anyone. Unlike the previous finding, the tenant column here already exists — it simply was not used.

The rule on this table is USING (true) WITH CHECK (true) for updates. In plain terms: any logged-in person may change any row, and may change it to anything.

What makes this worse than the read problem is that the table does have a workspace_id column. The information needed to write a correct rule was sitting right there. This was not a structural impossibility, it was an omission.

The columns involved are not cosmetic. Alongside status there is an action_payload field, and the table carries executed_at, executed_by and execution_result. Those names describe something that gets acted upon.

Your billing code queries a table that no migration creates

Eight tables are queried by running code but are created by none of your 75 live migrations. One of them is subscriptions. Whichever explanation is true, it is worth knowing today.

The eight are teams, team_members, team_invitations, team_member_permissions, subscriptions, google_accounts, campaign_analytics and sales_calls. They appear only in the abandoned migrations/ folder, and are absent from the production snapshot your current migration history is built on.

Meanwhile live code queries them for real — src/routers/billing/subscribe.py and src/routers/billing/webhooks.py against subscriptions, src/routers/teams/members.py against the team tables, and nine separate calls in src/database_google_accounts.py.

One line in that last file is the most revealing thing in the whole repository:

logger.warning(f"Error fetching google_accounts (table may not exist): {e}")

The application does not know whether its own table exists, and has been written to carry on regardless.

For twenty-nine days, every workspace's API keys were readable by any logged-in user

The rule protecting your credentials table checked only that a workspace was active, not who was asking. It was corrected on 30 August. Fixing the rule does not un-disclose the keys.

workspace_config has 109 columns, around 35 of which hold credentials for other services — Bison, GoHighLevel, OpenAI, Anthropic, Slack, Telnyx, Calendly, HubSpot, Apollo, Apify, Instantly and more.

The rule shipped in the August baseline read USING (is_active = true). That asks "is this workspace switched on?" — not "does this person belong to it?". Any logged-in user could read every active workspace's row.

It was fixed on 30 August by a migration that replaced the rule with a proper membership check. The fix is correct and I have confirmed the old rule is gone.

The exposure window was 1 to 30 August at minimum. It is likely longer, because the August baseline was a snapshot of a rule that already existed.

A bot merges your highest-risk changes, including database migrations, with no human involved

The auto-merge classifier sorts changes into risk tiers and then approves every tier for automatic merging. A database migration went in unreviewed in sixteen minutes.

You have a script that classifies each proposed change by risk, based on which files it touches. The classification itself is well built — deterministic, based on file paths, read from the trusted branch rather than the change itself. That is the right design.

The problem is what it does with the answer. Run across all 576 combinations of file paths, the classifier returns "merge automatically: yes" in every single one. Tier 3 — your highest-risk category — merges automatically just like tier 0.

The tier label is applied, and then ignored. There is a step designed to escalate to a human, but the condition that triggers it can never be true, so it is unreachable code.

In your actual history: across 93 merged changes, a human was requested zero times. 36 were tier 3. Pull request #1005 — a database migration — was merged by the bot 16 minutes after it was opened, with no reviews. #952 merged 1.4 minutes after creation. 70% of changes close within 15 minutes.

Your test router skips the deepest tests on exactly the changes that most need them

Changes to the live sending path, to database migrations, and to security policies are all marked as not requiring end-to-end tests. Adding risk to a change can remove its tests.

You have a router that decides which tests to run based on what a change touches. Sensible idea. But three of the four highest-risk categories are configured with end-to-end testing switched off:

Because the router stops at the first category that matches, and the risky ones are checked first, there is a perverse effect: **a change that touches the send path *and* the sales screens is classified as live-send risk, and therefore loses the routine test it would have had if it were less risky.** Adding danger removes testing.

This is not hypothetical — seven changes to the live sending path have already merged with no end-to-end tests at all.

And the one send-related test that does exist cannot see a send. The test environment sets a flag that makes the code return early, before it ever schedules the send. So no send is scheduled, and the cancellation test's central line — "if there is no scheduled send, skip" — is always taken. The test proves that a row gets *marked* as cancelled. It cannot prove a send was *stopped*, because there was never a send.

Overall, 12 of the last 100 test runs actually ran any browser tests. The other 88 checked out the code, printed a message, and reported green.

Your post-deploy check failed 95% of the time for a month, and its alarm could not fire

The workflow that verifies a deployment actually worked has been failing since mid-August. It is supposed to raise an issue when that happens. It cannot, because the labels it uses do not exist.

After each deployment a smoke check runs against the live site. Over the sampled window it failed 58 times out of 61 — every completed run between 13 August and 31 August failed, with the first green in four weeks landing on 10 September.

The failure is always the same shape: a version endpoint poll fails, which means the actual health assertion is never reached.

When it fails, the workflow is meant to open an issue so somebody notices. That step runs a command tagging the issue with two labels — and neither label exists in your repository, so the command errors. There are zero such issues. The alarm has never once made a sound.

One clarifying detail, and it is reassuring: every failure on your default branch in this window was *after* merge — the smoke check and one deploy. Your main CI run is 20 for 20 green. Your branch is not red because bad code slips past the tests. It is red because the one workflow that checks the deployed result was broken, and nothing depends on it.

Two live Google credentials are committed in your repository, and git never forgets

Not one, but two. Different Google Cloud projects, both with a working secret, both permanently in the repository's history — including in every copy anyone has ever taken.

A credential is any string that grants power. These two grant the ability to act as your Google applications.

Your .gitignore lists credentials.json. That is why this is easy to miss and worth explaining: adding a file to .gitignore stops it being added in future. It does nothing at all about a file already tracked. Somebody added the ignore rule believing it fixed the problem. It never did, and no warning was ever shown.

The second one is in a folder called public/, which is alarming at a glance. It was checked: that folder is not served to the internet — the Python app uses a different static directory, and the Next.js app serves only its own frontend/public/. So the exposure is "anyone with access to this repository", not "anyone with a browser". That is a meaningful difference and it is worth knowing before anyone panics.

Both are desktop-application credentials, which Google itself treats as less confidential than server credentials. That lowers the severity. It does not make it fine.

Three endpoints act on whatever record you name, without checking it is yours

Most of your endpoints get this exactly right. Three do not — and on one of them, a customer can change another customer's data.

I want to start with what is right, because it is most of it. The strong pattern in your code takes the workspace the caller claims, looks up whether that person actually belongs to it, and refuses with a 403 if not. Twenty-two endpoints do this correctly. Your login layer also rejects unauthenticated calls before they reach any endpoint at all. This is a well-built system and the exceptions are exceptions.

Three endpoints break the pattern in the same way. Each one authenticates the caller, then uses an administrative database connection that ignores all row-level rules, then fetches or changes a record by an id the caller supplied — without ever checking who owns it.

The second is the most commercially sensitive: it returns the actual text of a follow-up email plus who it is aimed at. That is a competitor reading your customer's outreach copy and target list.

The third is the most serious in kind, because it is a write. One customer can silently degrade another customer's product experience, and nothing in the record shows it happened.

You are running two complete backends at once, and neither one is scheduled to stop

The migration in your architecture document is not a plan — it is half-finished and both halves are live. That is the most expensive state a system can be in, and nothing currently defines when it ends.

Your architecture document proposes adopting Next.js, TypeScript, Trigger.dev and Mastra. All four are already installed and running. What it does not describe clearly is that the system they were meant to replace is also still running.

Your document describes the Python side as "some important working functionality" to be kept "behind clear boundaries". That undersells it considerably. It is a second application with its own scheduler, its own webhooks, its own admin pages and its own billing routes.

And there is no boundary. A boundary would mean one side owns a set of tables and the other asks it for things. Instead both write the same tables directly — the follow-up queue is referenced 7 times in the Python code and 92 times in the TypeScript. Two codebases, two languages, two schedulers, one set of rows, no owner.

The six reconcilers are the tell. A reconciler is a job that exists purely to check whether reality matches what the database believes, and repair it when it does not. You have six, split across both stacks. Nobody writes six reconcilers by choice. They are the system telling you, in its own handwriting, exactly where it does not trust itself.

One person holds the whole system, and the guide for new developers describes a different product

4,484 of 5,129 commits are yours. The onboarding document a new developer would read first describes software this repository no longer contains.

The commit history has exactly one human in it. The only other contributor is an automated error-reporting bot. That is normal for a founder-built product and it is not a criticism — but it is the single largest risk to the business, and it is the one you are actively trying to solve by hiring.

The problem is what a new developer finds when they arrive. Your README.md describes Inreachly OS as *"a multi-tenant MCP platform connecting Claude Desktop to Gmail, Calendar, Docs, Slack — 106 tools across 10 platforms"*. Your DEVELOPER-HANDOFF.md states the backend is FastAPI and Uvicorn.

Neither describes the product you are selling. The cold-email platform, the Next.js application, Trigger.dev, Mastra, the sending engine — none of it appears in either document. A developer reads these on day one and builds an entirely wrong mental model, then spends their first fortnight discovering it is wrong.

There is a second, subtler version of the same problem. The repository contains around 1,827 files across thirteen different AI-assistant configuration folders, and 1,197 date-stamped planning documents — docs/superpowers/ alone holds 1,024 files. These are the by-products of building with AI assistance, committed and never cleared.

That produces an unusual kind of knowledge debt. With ordinary legacy code, the reasoning is at least reconstructable from the code. Here much of the reasoning lived in AI conversations that no longer exist, and what was written down is a thousand superseded plans with nothing marking which ones still apply.

One customer's big import can hold up everyone else's sending

You asked about this exact scenario on the call. It can happen — and the same twenty-slot limit is also why a bad hour at your email provider can freeze sending for every customer at once.

Picture a shop with twenty tills. Every customer queues for the same twenty. Normally that's plenty — until one customer wheels in five hundred trolleys. They're not doing anything wrong, and the tills aren't broken. But every other customer now waits behind them.

That's your sending system. Each of your four sending tasks allows twenty jobs at once, on a queue shared by the whole platform. One job sends one email — the code confirms it, each job handles a single follow-up rather than a batch.

Trigger.dev can give each customer their own till. The setting is called a concurrency key, and it appears zero times in your codebase.

You do attach the workspace to every job, but as a *tag*. A tag is a name badge on the trolley: handy for finding things afterwards, no help at all in the queue.

### Twenty at once is not twenty per minute

Worth being precise, because it's the number you'll want to test against. Twenty is a limit on jobs running at the same moment, not a rate. You could queue fifty thousand emails in one second — twenty send, the rest wait. A slot frees the moment a job finishes.

Which means your actual sending speed is not something anyone configured. It falls out of how long each send takes:

So your capacity is set by your email provider's response time, and nobody chose it. When they slow down, your throughput drops by the same proportion, for every customer simultaneously, and nothing in your dashboard says so.

### The part that turns slow into stuck

Now the compounding problem, and it's the reason this matters more than a queueing inconvenience.

Your provider client has no timeout. None of the calls set one, and the underlying tool doesn't add one by default. Your job platform will eventually kill a run, but not for five minutes.

Back to the shop: the card machine at a till hangs. The till isn't closed — there's still a customer standing at it, going nowhere, for five minutes. Multiply by twenty and the shop has twenty tills and zero throughput.

That's not hypothetical, because these failures arrive together. A provider incident doesn't hang one call, it hangs everything in flight. Twenty stalled calls and that task is frozen platform-wide for five minutes.

And it doesn't end cleanly. When the platform finally kills those runs, they die mid-flight — after the send may have gone out, before anything was recorded. Those rows sit in sending forever, and the job that finds them counts them and moves on.

So one hung connection produces three separate symptoms you'd otherwise investigate separately: sending stalls for everyone, some customers' sequences stop dead, and nobody can tell whether those emails went out.

### Where the chain breaks

All of it starts at the same missing line:

no timeout  →  slots held for 5 min  →  queue starves for everyone  →  runs killed mid-send  →  rows stuck forever

Set a fifteen-second timeout on the provider calls and the chain breaks at the first link. A slow call fails fast, frees its till, and retries — instead of holding a slot hostage and stranding a record.

The pattern already exists in your own codebase — bison-active-accounts.ts sets exactly this. It just wasn't applied to the sending path.

Every weekend follow-up, for every customer, is scheduled for the same instant

Follow-ups landing on a Saturday or Sunday are all moved to Monday at exactly 13:00 UTC — the same millisecond — with no randomisation anywhere.

When a follow-up would fall on a weekend, the scheduler moves it to the next weekday and sets the time to nine in the morning, US Eastern. It does this by setting the hour, minute, second and millisecond to fixed values.

The result is that every weekend-deferred follow-up, across every lead and every customer, carries an identical timestamp.

There is no jitter — no small random offset to spread sends out. The function that would generate one appears zero times across the entire background-job codebase.

Two related gaps sit alongside it. Sending windows are computed when a follow-up is planned and never checked again before it goes out, so anything delayed sends outside its window. And the daily send caps that exist in your configuration are read by nothing at all — the enforcement relies entirely on your provider.

One more detail worth knowing: this path hardcodes US Eastern time rather than using the prospect's timezone, even though timezone handling exists elsewhere in the system.

When a send outcome is unknown, nothing ever resolves it

The system correctly refuses to guess when it does not know whether an email went out. It then has no way to find out, and no way for a person to decide.

This is a case where the careful half was built and the follow-through was not.

When the outcome of a send is genuinely ambiguous, the newer path records that fact and stops. It will not retry, because retrying might duplicate. That is the right call.

But nothing resolves the record afterwards. The reconciler that examines these simply counts them. There is no check against your provider to ask what actually happened — and the database has a field for exactly that, with three permitted values: the provider's response, an authoritative lookup, or an operator confirming manually. Two of those three are never used anywhere in the code. Only the provider's own response is ever recorded.

The operator interface is read-only about it. It displays: *"remains unresolved and will not be resent"* and *"Provider confirmation is still required; automatic resend is blocked"*. There is no button.

A related version affects the older path: records that get stuck mid-send are found by a reconciler every ten minutes, counted, and left alone. The classification is literally named "needs audit". Combined with the absence of any timeout on provider calls, a hung connection leaves a record stuck permanently and that lead's sequence stops dead.

Prospect names, emails and entire conversations are sent to two US AI vendors, undocumented

There is no data-processing agreement, no sub-processor list and no filtering at the point where personal data enters a model prompt. Your own internal audit flagged this in April as blocking launch.

Personal data reaches OpenAI and Anthropic across at least six distinct places in the code:

• Every inbound reply goes to both vendors. The classifier sends it to OpenAI; a second quality-judge step then sends the same text to Anthropic. One prospect email, two vendors, per reply cycle.
• Reply drafting sends the entire thread plus identity — first name, company, job title, industry, location, timezone, website, and every message body verbatim, including both parties' email addresses.
• Owner identification sends named individuals to OpenAI. Text scraped from state corporate registries, Yelp, the Better Business Bureau and LinkedIn is sent to a model to extract *"the owner, founder, or principal's name"* and their phone number — for the purpose of cold-calling them.
• There is no filtering at the boundary. The prompt builder concatenates whatever columns a campaign config names, with no allow-list and no personal-data filter. Today's configs happen to be restrained; a config change is all that stands between that and sending email addresses and phone numbers.

Nowhere in the repository is there a data-processing agreement, a sub-processor list, a privacy policy, or a zero-retention configuration with either vendor.

Your own team already found this. An internal audit note from April names the required sub-processor list and records it as blocking a Phase 2 launch. It has not been done. And the draft sub-processor list that does exist omits OpenAI — the vendor on the majority of these paths.

One smaller item in the same family: one email-verification vendor is called with the address in the URL query string rather than the request body. Query strings get written to access logs at every hop between you and them. Two comparable vendors in your own codebase do it correctly by POST body, so this is a one-line fix.

Your customer-separation check runs once per row, and does two database lookups each time

Someone on your team knew the optimisation that avoids this — it is applied to one part of the rule and not the part that costs the most. Invisible today; it arrives as a cliff, not a slope.

Your main separation rule has four tests, joined by "or". They behave very differently:

The third one is the problem, and it is structural rather than careless. It takes the row's own workspace as an input, so the database cannot work it out in advance — it has to ask again for every row it considers.

Two details make it heavier than it looks. It is written in a language the database cannot fold into the surrounding query, so each call carries real overhead. And inside it, it first checks the profiles table, then checks the access table. That is two lookups per row.

The good news, and it is genuinely encouraging: the first test *is* wrapped in the pattern that makes it run once. Somebody knew about this. It just was not applied to the expensive branch — the one that takes a column and therefore cannot be hoisted.

You are using the connection mode that does not share connections, across a lot of separate processes

Supabase offers two pooling modes. You are on the one where each process holds its own database connection for as long as it runs — and you have a lot of processes.

A database can only hold so many connections open at once. It is a hard ceiling, and when you hit it, everything fails at the same moment rather than getting gradually slower.

Supabase gives you two ways to connect. Transaction mode hands a connection back after each query, so hundreds of clients can share a few dozen connections. Session mode gives each client its own connection and keeps it for the whole session.

Your configuration uses session mode. The comment in your own config explains why — it was chosen for network-compatibility reasons, which is a legitimate reason and not a mistake. But it means your connection count scales with how many processes you run, not how busy they are.

And you run a lot of processes: the Python web service, the Next.js application, a fleet of scheduled jobs — you have 31 separate job scripts — and up to 20 simultaneous background runs per sending task.

Idle processes still hold their connections in this mode. A scheduled job that runs for thirty seconds every five minutes may hold a connection the whole time.

You built a credit system that can stop a customer overspending, and it is running in observe mode

The accounting is genuinely well built — reservations, an immutable ledger, whole-number money, idempotent top-ups. Your own runbook confirms the tooling that switches it on cannot set the mode that enforces anything.

Credit first, because this is good work. You have a credit ledger with reservations, immutability rules that block tampering with a paid top-up, idempotency keys so a retry cannot double-charge, and money stored as whole micro-units rather than decimals. There is a reconciliation job for stale reservations. This is better than most billing systems.

The account has a mode setting, and enforce is one of the valid values. The database constraints require an enforcement baseline before that mode can be set, which is careful design.

But your own runbook states plainly that the activation tool "never supports enforce" and defaults to dry-run. The documented mode is observe, which the same document describes as recording usage *"but does not reserve or debit the workspace balance"*.

So the machinery is built, wired and switched off. Today, a customer's spending is measured accurately and capped by nothing.

One related gap: I found no rate limiting on your customer-facing endpoints. Several of those endpoints make AI calls.

Adding a database index can freeze your send queue mid-deploy

725 indexes have been created and not one uses the option that avoids locking the table. Seventy of them are on tables the sending system uses constantly.

An index is the database equivalent of the index at the back of a book — without one, finding a row means reading every row. Adding one is routine.

Postgres offers two ways to add an index. The default takes an exclusive lock on the table and holds it for the whole build, blocking everything else. The alternative, CONCURRENTLY, builds it without blocking, in exchange for taking longer.

Every index in your migration history uses the default. Nine of them are on follow_up_queue — the live send queue — and five on sequence_event_outbox.

A related detail: these are written as CREATE INDEX IF NOT EXISTS. If a build fails, that phrasing lets the migration report success anyway, leaving you believing a uniqueness rule is in place when it is not.

Your shareable prospect pages have a weaker lock than the rest of the system

The lead-magnet pages at /r/… are protected only by the web address itself, and that address is largely predictable.

These pages are meant to be shared — you send a prospect a link to a personalised sample of work, and no login is required. That design is fine and common.

The security of that design rests entirely on the address being unguessable. Yours is built as lead-company-prospect-company- followed by five random characters drawn from a 31-character alphabet.

The two company names are not secret — a competitor knows both. So the actual secret is five characters, about 28.6 million combinations. That is a large number for a person and a small one for a script, and the pages sit outside the login layer, where the reviewer found no rate limiting. A wrong guess and a right guess look different, so a script knows when it has succeeded.

Each success returns a full personalised payload: the prospect's company data and a list of candidate leads belonging to that customer.

Your other public page type gets this right. The /lm/… route builds its address from eight characters of a random UUID — around 4 billion combinations — and is not affected. This is one route out of step, not a pattern.

The two database functions that enforce customer separation are missing a standard safety setting

No working exploit was found, and the code is written defensively enough that one may not exist. It is worth fixing because of what these two functions do.

Some database functions run with the permissions of whoever created them rather than whoever calls them. That is a normal and useful feature, and it is also a well-known category of risk — such a function should always be pinned to a fixed set of locations when it looks things up, otherwise a malicious actor could in theory substitute their own objects and have them executed with elevated permissions.

Two of your functions are missing that pinning: is_admin() and user_has_workspace_access(). The second is the function referenced inside your main customer-separation rule, so it runs constantly, on many tables.

No exploit was found and that is not a formality. The function bodies name every object they touch explicitly, which defeats the usual attack, and Supabase does not let ordinary logged-in users create the objects that would be needed. This is a hardening gap flagged by Supabase's own linter, not a demonstrated hole.

What makes it worth doing is that your team already knows the fix. Newer functions written later — is_admin_user() and jwt_tenant_id() — do set the pinning correctly. These two are older and were simply never revisited.

The audit already in your repository was written by the same tool that built the thing

audit-report-20260426 opens by stating it was generated by Claude Code, reviewing configuration Claude Code produced. It concluded "accept as-is". That is not an independent check.

There is an audit report sitting in your repository root from April. Its first line reads: *"Generated by Claude Code reading audit-input-20260426-043017.md"*. It reviewed 51 pipeline configurations, found one cosmetic issue, and recommended accepting everything as-is.

The work itself looks competent. That is not the issue. The issue is that the thing being checked and the thing doing the checking were the same system, so agreement between them proves nothing. A tool cannot independently verify its own output — it will tend to find the code correct for the same reasons it wrote it that way.

This matters because that report is now sitting in your repository looking like assurance. Anyone finding it — a developer, an investor, a customer's technical reviewer — would reasonably read it as "this system has been audited".

It is also worth noticing what it audited: block wiring inside lead pipelines. Narrow and mechanical. None of the thirteen findings on this page would have been visible from that vantage point, because it was never looking at them.

How many customers your sending can actually carry

The arithmetic, so you can substitute your own numbers. The answer is not a customer count — it is a peak-demand number, and your scheduling makes your peaks much worse than your average.

Twenty simultaneous sends per task, one email per send. So capacity depends on how long a send takes:

At a healthy two seconds, 288,000 emails a day is a lot of customers — on paper. If a customer sends 1,000/day, that is roughly 288 customers before the queue is the limit.

But average capacity is the wrong number, and this is the part that matters. Sending is not spread evenly. It clusters into business hours, and your own scheduler makes the clustering far worse: every follow-up that lands on a weekend is moved to Monday at exactly the same instant, with no randomisation.

So the real question is not "how many emails per day" but "how many want to go out in the same minute". Twenty slots is your answer to that, and it does not grow.

What actually binds first, in order: your peak-minute demand exceeding 20 slots, long before your daily volume approaches capacity. Then your provider's own rate limits, which you do not currently handle. Then database connections.