Error tracking for your live v1 (UK SaaS, Claude Code 2026)

You scaffolded the skeleton, wired Supabase auth and Stripe billing, shipped the v1 to three founding members, and built the first feature they asked for. The product is live and being used by people who paid you in pounds. Which means the next thing to plan for is the one nobody enjoys: something is going to break.

The launch checklist listed "errors visible to you" as a pre-launch check and moved on. This post is that line, expanded - the observability layer for a brand-new SaaS, sized for three customers, wired with Claude Code. The whole point is one outcome: you find out something is broken before your customer emails you. Get that, and a v1 outage becomes a quiet fix instead of a refund.

The three things worth watching (and the long list to ignore)

Open any guide to observability and you get the enterprise version: dashboards, distributed tracing, service-level objectives, latency percentiles, an on-call rota. All real, all genuinely useful - at scale. At three customers, building any of it is procrastination dressed as engineering.

For a v1, there are exactly three things worth watching:

1. Errors - did your code throw an unhandled exception in production, and which user hit it.
2. The money path - did a payment or a Stripe webhook fail, silently, without crashing anything.
3. Uptime - is the site even answering, right now.

That is the entire layer. Three alarms, routed to one place you actually look. Everything past it is for a future where aggregate numbers start carrying information - which, at three customers, they do not. A conversion rate from three people is noise; a latency percentile across a handful of requests is noise. The job today is not to measure your app, it is to never be surprised by it.

Error tracking: wire it in one session with Claude Code

Error tracking is the first alarm and the easiest win. The standard choice is a hosted tracker like Sentry, whose free tier comfortably covers a v1, and wiring it into a Next.js app is close to a single-session job with Claude Code.

Ask Claude Code to:

• Install and configure the tracker for your Next.js app, capturing both server-side and client-side errors.
• Attach user context to each error - the Supabase user id or email - so an alert tells you not just what broke but who hit it. At three customers, "who" is half the diagnosis.
• Configure source map upload on deploy, so a stack trace points at your real TypeScript rather than minified production bundle gibberish. This is the difference between an error you can read and one you have to reverse-engineer; let Claude Code wire it into the build step.

Then do the step everyone skips: test it. Add a throwaway route that deliberately throws, deploy, hit it, and confirm the alert lands in your channel with a readable trace. An error tracker you have not fired once is a dependency, not a safety net. Once you have seen a test error arrive cleanly, delete the route and trust it.

One rule on where alerts go: route them to a channel you check by reflex, not a dashboard you have to remember to open. A small Slack or Discord, an email that hits your phone, anything that reaches you in seconds. The best error tracker in the world is useless if its alerts sit unseen in a console you visit twice a week.

The money-path alarm: the one error you cannot miss

Generic error tracking catches crashes. But the error that actually costs you a customer often is not a crash at all - it is a silent business-logic failure, and it deserves its own alarm.

Picture the worst case. A founding member's card succeeds at Stripe. But your webhook handler errors out before it marks their account active in Supabase. No page crashed. No red screen. From your error tracker's point of view, nothing obviously broke. Meanwhile your customer just paid you and got locked out - the single worst experience a paying user can have, and you would not even know.

So you alarm the money path specifically. Ask Claude Code to alert you when:

• A Stripe webhook returns a non-2xx or throws while processing.
• A payment succeeds but the account does not flip to active within a short window - a reconciliation check, not just an exception.
• A subscription event fails to process - renewals, cancellations, upgrades.

These are the failures generic tracking misses because nothing technically "errored" in a way it recognises. The blast radius of one missed payment is a refund and a lost founder, so be paranoid here: wire the alarm, test it with a real GBP test payment the same way you tested billing at launch, and make it loud. This is the one alarm where a false positive is fine and a false negative is a disaster.

Structured logs: the floor you never go below

Below the alarms sits the floor: structured logging. If you do nothing else, log with context.

Not this:

payment failed

But this:

payment_failed user=abc123 amount_gbp=12.00 stripe_event=evt_xxx ts=2026-06-03T11:04:22Z

The difference is whether, when something goes wrong, you can follow the thread or are left guessing. Logs are reactive - they let you reconstruct what happened after you already know something went wrong. That is exactly why they are the floor and not the whole story: pair them with the proactive alarm above, so you are told there is a problem rather than discovering it.

The good news for a Vercel-hosted Next.js app: your logs are already captured and searchable out of the box, so you may not need a separate paid logging service at v1 at all. The shape is floor plus alarm - the logs your host already keeps are the record, and a free-tier error tracker plus the money-path alarm are what wake you up. You need both, but at three customers neither has to cost you anything.

Ask Claude Code to add structured logging at the points that matter - auth, the payment webhook, the core feature's critical path - with consistent context fields. Consistency is what makes logs searchable later; a tidy log line you can grep beats a verbose one you cannot.

Uptime: find out before your founder does

The last alarm is the simplest. Errors and the money path tell you when something inside the app misbehaves. Uptime tells you when the app is not answering at all - a bad deploy, an expired credential, a provider outage.

You do not need anything heavy. A simple external uptime check - a service that pings your site every few minutes and messages you if it stops responding - is enough. Many have free tiers that cover a single site comfortably. Point it at a real URL (ideally a lightweight health route, which Claude Code can add in a couple of minutes), set the alert to the same channel as everything else, and forget about it until it shouts.

The value is entirely in the timing. Without it, you find out the site is down when a founder messages "is it just me, or is it broken?" - a small trust hit every time. With it, you usually know first, and can be fixing it before anyone asks. At three customers, being the one who noticed first is worth a lot.

The discipline: stop here

Here is the hard part, and it is not technical. Once you have these three alarms wired, stop. Resist the pull to build more, because more feels like progress and at this stage it is not.

You do not need, for three customers:

• Dashboards and charts - a conversion rate from three people tells you nothing, and you can answer "did each founder reach the core value" by looking, because there are three of them.
• Distributed tracing - you have one app, not a mesh of services.
• Service-level objectives and error budgets - real tools for teams with traffic, pure ceremony for a solo founder with three users.
• An on-call rota - it is you, and you have a phone.

Every hour spent on a monitoring dashboard for three customers is an hour not spent making the product worth paying for. The honest signal to upgrade is friction: when errors arrive faster than you can read them one by one, when you have enough customers that "who hit this" stops being obvious, when you genuinely cannot tell whether a slowdown is real. That is when dashboards, tracing, and SLOs start earning their keep. Build the heavy monitoring the day it solves a problem you actually have - not the day you imagine having it.

The same discipline runs through this whole build arc, and it is worth naming. When Claude Code lets you ship almost anything in an afternoon, the constraint is never capability - it is judgement about what not to build. Observability is the cleanest example: the temptation to over-engineer is strongest precisely where the payoff is lowest.

The whole layer, in one afternoon

None of this is a project. It is an afternoon with Claude Code:

1. Wire an error tracker into Next.js - server and client, user context, source maps - and fire a test error to prove it.
2. Add a money-path alarm on the Stripe webhook and the payment-to-active reconciliation, and test it with a real GBP payment.
3. Add structured logging with context at auth, the webhook, and the core flow.
4. Point an external uptime check at a health route.
5. Route every alert to one channel you check by reflex.

Do that, and your live v1 has exactly the observability a three-customer SaaS needs: you find out before they do, the money path is guarded, and you have spent your judgement on the product instead of on a dashboard. The next break is no longer a surprise - it is a quiet fix and a "you asked, I shipped it" message to a founder who trusts you a little more for it.

---

Building your validated idea? IdeaStack publishes one deeply-researched, UK-specific business opportunity every week - real keyword volumes, competitor analysis, SERP landscape, and copy-paste builder prompts. Read this week's free report and find the next one worth shipping.