ShipKeeper: a standalone shipping protection product.

The challenge

Shipping protection is a category dominated by a few large incumbents. The economics are real: customers want recourse when packages get lost or stolen, merchants want to absorb fewer support tickets and refunds, and a per-order premium creates a clean revenue model.

The challenge was to build a complete competitor: marketing site, customer portal, claims workflow, billing, fraud detection, all of it. Not a feature inside another platform. A standalone product with its own domain, its own brand, its own sign-up flow, and its own operational backbone.

The solution

We built ShipKeeper as a separate Next.js app on the same shared infrastructure pattern we use across our portfolio. Marketing pages, customer portal, and admin tooling live in one app with role-based routes. The backend reuses the AVNZ platform's core modules: auth, customers, audit logging, billing, integrations. The ShipKeeper-specific logic (policies, claims, risk scoring) lives in dedicated modules on top.

Stripe handles the billing side. Each merchant signs up, adds a payment method, and gets billed monthly based on the number of orders covered. The claims workflow is a state machine: filed, under review, approved or denied, paid out. Every transition is audited. Every payout is reconciled against the policy and the claim documentation.

Fraud risk scoring runs on every claim before approval. The model considers claim velocity per customer, claim value relative to order value, time since order, and shipment status from the carrier API. Low-risk claims get auto-approved within configured limits. High-risk claims get queued for human review with the risk factors annotated so the reviewer understands why.

What we built

The customer-facing site (shipkeeper.io) is the marketing surface: how it works, pricing, sign-up. Below the marketing line is the customer portal where merchants manage policies, file claims, see payout history, and configure their account. Below that is the admin panel for the operations team: reviewing flagged claims, adjusting risk thresholds, running payouts, handling exceptions.

The infrastructure is AWS ECS Fargate with an ALB in front, PostgreSQL in RDS, and Stripe webhooks routed through a dedicated ingest path with HMAC verification. The deployment pipeline runs through GitHub Actions with environment protections so production deploys require an approval gate.

Phase one was the marketing site and merchant sign-up. Phase two was the claims workflow and customer portal. Phase three was billing automation and fraud scoring. Each phase shipped to production before the next one started, which is the only way to keep a multi-phase build honest about what works and what does not.

Hard problems we solved

Claim eligibility logic is more nuanced than it looks. A package can be "delivered" by the carrier and still missing from the customer's porch. A package can be marked "in transit" for two weeks legitimately during peak season. The rules for "this claim is valid" have to encode that nuance without becoming a maintenance nightmare. We use a rules engine that operators can adjust as they learn.

Stripe webhook reliability matters when money is involved. We process every Stripe event through an idempotent handler keyed on the event ID, so a duplicate webhook never produces a duplicate side effect. Failed handlers retry through a BullMQ queue with exponential backoff. Permanently failed events page the on-call engineer rather than disappearing into a log somewhere.

Domain and DNS for a brand-new product is a small problem that can derail a launch if it is not handled carefully. We registered shipkeeper.io, set up Route 53, configured ACM certificates, and wired the ALB before the marketing site was even feature-complete. That order matters: by the time the site was ready to go live, the certificate had already propagated and the domain just worked.

The result

ShipKeeper is live at shipkeeper.io. The full product is shipping: merchants can sign up, add a payment method, configure policies, file claims, and get paid. The operations team can review flagged claims, adjust risk thresholds, and run reconciliation reports. The backend is stable, the billing is automated, and the risk model is tuned through real data.

The interesting metric is not feature count. It is that this product went from empty repo to live, billable product on a real domain in three phases, with each phase deployed to production before the next began. That is the tempo we aim for, and that is the proof point this case delivers.

Why this case matters

ShipKeeper is the proof that "we ship full products, not just features" is a real claim. A standalone insurance-style product with billing, claims, fraud scoring, and a public domain is not a small thing. The reason it was possible in the timeline we shipped it in is that we had a platform spine to build on (auth, audit, billing, integrations) and a senior engineer end-to-end. Same playbook, new product.