Bhavesh Narsai

AI's role

Built with AI coding assistants throughout. The commit history shows the webhook engine, invites, auth and Stripe billing landing over two days of sprints in February 2026. A hardening pass in May went back over all of it, and that is where most of the fixes below came from.

My role

Setting the constraints: one service, no queues or extra infrastructure, tenant isolation on every query, and a webhook that must never fail loudly. I wrote those down as project rules for the AI assistant, so every change starts from them.

Challenges

• Twilio can deliver the same event more than once. A database function now acquires a per-caller cooldown atomically, so a caller cannot be texted twice in quick succession.
• A route ordering bug where /contacts/all was being matched as a phone number by /contacts/{phone_number}.
• The admin basic-auth check was not actually rejecting bad credentials. Admin routes are now gated at Nginx instead.

Security and quality

• Twilio signatures validated per tenant, with that tenant's own token.
• Row level security on every table. Anonymous access denied; signed-in users read only their own business's rows.
• Stripe webhook idempotency, a CSRF origin check on checkout, phone numbers masked in logs.
• A pytest suite covering the webhook's short-circuit paths and helpers.

AI's role

Built in short sprints with AI assistance. Auth, settings, the webhook engine and the full Stripe subscription lifecycle came together in the first week of March 2026. Later work was mostly refactoring and review: pulling duplicated send logic out of two route handlers into one tested path.

My role

Product and compliance decisions. Who can send, to whom, how often, and what happens when someone says stop. The project rules tell the assistant which parts are off limits: auth, signature checks, rate limits and the opt-out path.

Challenges

• The quota check had a race: two concurrent sends could both slip under the limit. Replaced with a single conditional UPDATE that reserves the slot before sending and releases it if Twilio fails.
• The plan limit was defined in two places with two different values. Consolidated to one source of truth.
• UK alphanumeric sender IDs are one way, so "Reply STOP" cannot work. Branded messages now link to a web opt-out page instead, backed by a platform-wide suppression list checked before every send.

Security and quality

• Clerk middleware on the dashboard, settings and admin routes.
• Rate limiting on the webhook and send API, in case a secret URL leaks.
• Stripe and Twilio signature verification; zod validation on input.
• Critical auth-bypass CVEs in the auth and framework packages patched, and key dependencies pinned, with a written dependency update routine.

AI's role

AI helped build it. It is deliberately not inside it. Every finding is a deterministic check over pages that were actually fetched, and the checks stay quiet when unsure rather than guess. A language model writing the findings would have been quicker to build and harder to trust.

My role

The scoring model and the honesty rules. Findability and contact count for most because those decide whether an enquiry happens. The report never implies it tested live rankings or what an AI assistant says about the business.

Challenges

• Discovery accuracy: matching the right business among similar names took several rounds of name matching, URL normalisation and validating local listings.
• Discovery moved search providers part way through, and scoring moved onto real Google review data.
• The discovery step costs money per call, so it is rate limited per IP in Postgres.

Security and quality

• No customer accounts: the full report needs both an unguessable token and a paid status.
• Admin by Google sign-in, restricted to one account, signed httpOnly session cookie.
• Machine endpoints behind separate secrets.
• A daily job deletes audits after 12 months, plus per-record deletion for erasure requests.

AI's role

Built with AI from a written specification rather than a loose prompt. The spec covers cadence, cost per check, what an alert says and what the product must never do, and the assistant works inside it.

My role

Product boundaries. It reuses the check engine behind the free website tools instead of forking it, it never crawls, never stores page HTML, and treats alert fatigue as the biggest product risk: any new check defaults to quiet.

Challenges

• Scheduling without a queue: one hourly cron drains whichever sites are due, with uptime checked more often than full content.
• Deciding what counts as a change worth an email, which is a product question more than a code one.

Security and quality

• Fetching arbitrary URLs safely: timeouts, size caps, SSRF guards and re-validation of every redirect.
• Admin behind Cloudflare Access; subscribers use magic links.
• Zero-dependency Node test scripts covering the checks, the diffing and the domain logic.

AI's role

Built with AI assistance on top of the existing scanner. The commit history shows the audit, its landing page, the print view, refunds and promotion codes landing over two days in August 2026, followed by a pass to make the report consistent and credible.

My role

Separating evidence from judgement. One phase drives the browser and records raw facts, judging nothing. A second phase turns stored facts into findings and can re-run without a browser. Every finding traces back to a measurement, a screenshot or a recorded outcome, and the report never estimates what a fix would earn, because that number would be invented.

Challenges

• Keeping the paid audit and the free scan from ever disagreeing. Both now run the same scoring code over the same parse of the page.
• Deciding when a buyer gets their money back. Automatic refund when the audit failed to collect evidence; never because the page turned out to be broken, since finding that is the product.
• Cloudflare's rate limiting is per location and approximate. Documented and proven with a diagnostic rather than assumed.

Security and quality

• Stripe webhook signatures verified; jobs deduplicated on the checkout session, so a redelivered event cannot run twice.
• Reports and screenshots served only behind unguessable tokens.
• Hard caps on every run: a 120 second deadline with the browser always closed, plus limits on steps, screenshots and screenshot size.
• Checkout rate limited, and only reachable from a valid free-scan token.