I built this on nights and weekends to learn a stack I keep making decisions about but rarely touch with my own hands. Sharing what I learned in case it's useful to anyone doing the same.

I'm a principal product manager, and I've spent more nights than I'd like on incident bridges — watching a service degrade in real time, then writing the document that goes to the customer afterward: here's what broke, here's how long, here's what we're doing so it doesn't happen again. Owning that accountability up close teaches you something the dashboards don't: the hardest question isn't "what happened" — it's "what do we owe, and can we prove it?"

Building integrations is my actual job, which means I spend a lot of time thinking about the teams on the other side of an outage — the people who have to turn an incident into a number a customer will accept. And the same pains kept showing up. Getting the data is a scavenger hunt across systems that were never built to agree. Asking "what if we'd classified this differently" means re-running everything by hand, so nobody does until they're forced to. When a customer disputes the number, "I think so" is the most honest answer anyone can give — on the one topic where you can least afford it: money owed. And when a contract or a severity turns out to have been wrong, correcting a credit you already settled is a mess nobody wants to touch.

None of those are calculation problems. They're proof problems. So on nights and weekends, I built a system of record designed to solve them.

The result is Attest — a system of record for the SLA credits a B2B company owes its customers. Not a calculator, not a monitoring dashboard. The thing that can answer, with a receipt, "how much do we owe this customer, and can you prove it?"

Here's what I learned making PostgreSQL — on Amazon Aurora — the actual product, with Vercel as a thin layer in front of it.

The problem, briefly

When a service misses its SLA, the customer is owed a credit. Sounds like arithmetic. It isn't. The number depends on: how long the outage really lasted, which minutes the contract excludes (scheduled maintenance), how severe the incident was classified, which contract version was in force at the time, where the month's total downtime lands against a tiered schedule, and the customer's monthly charge. Those inputs live in five different systems that were never built to talk to each other. The number is one value; assembling it by hand takes days, and when a customer disputes it, nobody can prove it in the room.

The interesting realization: the hard part isn't the math. It's the proof. And proof is an architecture decision.

The core decision: the app computes nothing

Most apps treat the database as a place to store rows and do the real work in application code. I inverted that. In Attest, the Next.js layer on Vercel passes parameters, renders rows, and does no credit math at all — no tier lookups, no severity weighting, no downtime subtraction. A credit lookup is literally:

SELECT * FROM compute_credit($1, $2::date);

The route returns that row as-is. Everything that produces the number lives in the database.

Why bother? Because "the database computed it" is verifiable in a way "the app computed it" never is. If the math lives in TypeScript scattered across handlers, proving a number is correct means auditing code paths. If it lives in one SQL function, the derivation is a single, inspectable source of truth. For a product whose entire value is defensibility, that's not a purity exercise — it's the feature.

Where PostgreSQL earns its keep: range types

The piece I'd never used before and now love: range and multirange types.

The "credited downtime" for an incident is the outage minus the maintenance windows the contract excludes. That's set subtraction over time intervals — exactly what tstzmultirange is for. The heart of the whole system is one expression:

tstzmultirange(ii.impact_window)
  - COALESCE(
      range_agg(mw.maint_window * ii.impact_window),
      '{}'::tstzmultirange
    )

Read it left to right: take the incident's impact window as a multirange, subtract the union of every maintenance window clipped to that incident (* is range intersection, range_agg folds the windows together, - is multirange difference). What comes back is the non-contiguous set of minutes that actually count — maybe two separate segments with a 14-minute hole carved out of the middle. No loops, no manual interval-merging in app code, no off-by-one bugs reconstructing intervals by hand. The database models time intervals as first-class values, and the subtraction is one operator.

This matters more than it looks, because that credited-minutes number feeds everything downstream: it sets the month's total downtime, which sets the uptime percentage, which determines the tier, which sets the dollar amount. A few minutes of error in the subtraction can move the total across a tier boundary and change the credit by thousands. Getting that exactly right — and having it reconcile end to end — was the part that took the most iteration.

The payoff is the most dramatic moment in the product: toggle whether one 14-minute maintenance window is excluded, and a credit steps from $2,400 to $6,000 — a $3,600 swing — because those minutes push the month across the 99.0% line into a worse tier. The whole thing is a single judgment call about whether maintenance was scheduled, and the range math makes the consequence visible.

The right index for the job: GiST on ranges

Overlap queries — "which impacts fall in this month?", "which maintenance windows touch this incident?" — are the access pattern this whole system runs on. So the range columns (incident windows, impact windows, maintenance windows, classification valid-time, contract effective-ranges) get GiST indexes, the index type built for range/geometric overlap.

The win: an overlap query resolves through a GiST index scan rather than a sequential scan over the whole table — the access path that holds as incident history grows. EXPLAIN ANALYZE shows the planner choosing the index rather than reading every row. GiST is also doing double duty: EXCLUDE USING gist constraints enforce that contract versions and maintenance windows can't overlap at write time, so the data can't get into an inconsistent state in the first place.

Multi-tenancy I didn't have to hand-roll: Row-Level Security

This is the one that most changed how I think. Tenant isolation — making sure company A can never see company B's data — is usually app-layer logic: every query carries a WHERE account_id = ? and you pray no handler forgets it.

PostgreSQL Row-Level Security moves that guarantee into the database. One policy:

account_id = current_setting('app.tenant_id', true)

applied to every tenant-facing table, plus a read-only role (attest_tenant) with no write grants. The app sets app.tenant_id for the session and then queries normally — the policy filters automatically. Run a query as the wrong tenant and you get zero rows, not an error and not a leak. Isolation isn't something the application promises; it's something the database enforces. As a PM who's sat through more than one "how do we guarantee tenant isolation" conversation, seeing it become a database property instead of a code-review discipline was genuinely clarifying.

Keeping the record honest: append-only + signed certificates

A "system of record" that can quietly edit a settled number isn't one. So mutation is blocked at the database level: triggers make settled credits immutable, and classifications and corrections are append-only — you supersede by inserting a new row, never by updating or deleting. When a contract gets renegotiated and uploaded late (it happens), you can't rewrite history; you issue a signed correction that links to the original, which stays on the record — superseded, not erased.

Each credit also exports as an Ed25519-signed certificate. The signature covers a canonical payload embedded in the document, and verification only needs the embedded public key — no database lookup required. The artifact carries its own proof. Signing happens in the app layer with Node's crypto, and the signing key lives in AWS Secrets Manager — fetched at invocation and cached in the warm instance, so the raw private key is never a plaintext environment variable in the deployed function. (The key does pass through app memory at sign time; KMS's signing API would avoid that but doesn't support Ed25519.) The record the certificate attests to is entirely the database's.

The AI part, kept honest: Amazon Bedrock suggests, a human decides

Incident severity drives the credit, and classifying severity from a noisy signal is a judgment call — a good fit for a model, a terrible fit for a model acting alone. So I used Amazon Bedrock to suggest a severity from the incident signal, and made the human override the real, recorded decision. Both live in the append-only classification history: the AI suggestion and the human's call, side by side, with provenance. Bedrock never writes to the database — the app inserts its suggestion as one row; a human override is a separate row. AI suggests, a person decides, the record captures both. For anything that touches money owed, that felt like the only honest pattern.

Why this stack, specifically

The hackathon constraint was Vercel for the frontend and a designated AWS database for the backend. What surprised me is how well that "thin app, heavy database" shape fit the problem. Aurora PostgreSQL gave me the range math, the GiST scaling, the RLS isolation, and the append-only integrity out of the box — these aren't libraries I bolted on, they're native database capabilities. Vercel made the front end a deploy-and-forget concern so I could spend my limited nights-and-weekends time on the part that mattered: the record. (The connection to Aurora uses short-lived IAM tokens via rds-signer.) The "zero stack" wasn't a limitation I worked around — it was the architecture that made the core claim true.

What I actually learned (as a PM)

• The hard problem usually isn't the calculation; it's the inputs and the proof. I'd have scoped this product wrong a year ago — I'd have prioritized the math and under-invested in defensibility. Defensibility is the product.
• Pushing logic into the database is a real strategy, not just a preference. "The database computed it, and here's the function" is a different trust posture than "the app computed it." I'll ask different questions in design reviews now.
• The most trustworthy system isn't the one that's never wrong — it's the one that can make a wrong thing right, on the record. An append-only ledger that issues honest corrections beats one that pretends settled numbers never change.

I learned more about Postgres, AWS, and Vercel building this one thing on weekends than I would have from a quarter of reading docs. If you're in product and you keep making calls about systems you've never built — pick a real problem and build it. It changes how you see the work.

I created this content for the purposes of entering the H0 Hackathon. Built with Amazon Aurora (PostgreSQL) and Vercel. #H0Hackathon