Hashorn

Case study · Fintech · Pre-seed

From whiteboard to live cards in six weeks

A pre-seed fintech founder needed a working card-issuing product to demo to investors. We delivered it in six weeks, including the ledger, admin tools, and a regression suite that runs on every PR.

Case studyFintech · Pre-seed

Rivermint

MVP shipped in 6 weeks

Client

Rivermint

Engagement

Project · fixed scope, fixed timeline

Duration

6 weeks (Q1 2026)

Team

3 engineers + 1 QA lead, 1 PM (Hashorn side)

ServicesAI Software DevelopmentQuality Assurance

Outcomes at a glance

Time to first live transaction

6 weeks

Test paths covered before launch

14 critical flows

Production incidents in the first 30 days

0

Sprint timeline

How the engagement unfolded

  1. Wk 0

    Brief, risk register, ledger model

    One call to lock scope and demo path. We modelled the double-entry ledger first because financial correctness is everything in fintech.

    One-page brief · ledger schema

  2. Wk 1

    Multi-tenant skeleton + Stripe wiring

    Auth, RBAC, audit logs, and the first idempotent webhook handler for Stripe Issuing. Friday demo: a card created in sandbox.

    First card provisioned

  3. Wk 2

    Ledger primitives + reconciliation

    Database-level double-entry constraints, daily reconciliation job, and the financial-correctness test suite that everything else runs through.

    Correctness suite green on CI

  4. Wk 3

    Cardholder dashboard + real-time feed

    Customer-facing app: balance, transaction history, card management. Stripe webhook to SSE to the client for sub-second updates.

    Cardholder dashboard live

  5. Wk 4

    First live transaction

    First real card swipe processed end-to-end. Founder watched the webhook arrive, the ledger update, and the dashboard refresh in real time.

    Live transaction confirmed

  6. Wk 5

    Admin console + runbook

    Ops tools: card freeze, manual review, refund initiation. 12-page operations runbook covering on-call, incidents, and Stripe escalations.

    Runbook signed off

  7. Wk 6

    Hardening + production launch

    Blue/green deploy on AWS, Datadog alerting on ledger imbalance, security review, demo-day handover.

    Live in production · zero defects at launch

Architecture

The stack we shipped on

Frontend

  • Next.js 15
  • App Router
  • TypeScript
  • Tailwind

API

  • Node.js
  • Fastify
  • Zod
  • TypeScript

Data

Double-entry constraints enforced at DB level

  • PostgreSQL 16
  • Prisma
  • Append-only audit log

Card rails

PCI scope kept entirely out of Rivermint's environment

  • Stripe Issuing
  • KYC vendor

Cloud

  • AWS ECS
  • RDS
  • Datadog
  • GitHub Actions

Risks we actively managed

  • Off-by-one in fee calculation — caught by financial-correctness suite before it reached customer-facing code.
  • Concurrent webhook race condition — idempotency keys plus row-level locking on ledger writes.
  • PCI scope creep — card data never crossed our environment; Stripe Issuing held the full PAN.
  • Investor scrutiny at demo — pre-recorded backup demo build kept on a separate laptop in case of network failure on stage.
Workflow

Tracked end-to-end in BuildOS.

Every meeting summary, requirement, sprint, task, and metric in this case study was rendered in BuildOS during the engagement. The customer's team had read-only access to the same workspace from week one, they saw Friday demos, weekly velocity, and AI-generated checklists without us sending status emails.

The challenge

Rivermint had a card-issuing thesis, no engineers, and an eight-week fundraise window. They needed software that could process a real transaction, on real cards, by demo day, and stand up to investor scrutiny. A typical agency timeline of three to four months would have missed the round entirely.

Three constraints shaped the engagement:

  • Financial correctness. Anything touching the ledger had to be verifiable, auditable, and free from the kind of off-by-one rounding bugs that get fintechs in trouble.
  • PCI scope. We had to keep card data out of Rivermint's environment entirely, Stripe Issuing was the right call, but the integration had to be clean.
  • Demo-day proof. Investors weren't going to read a Figma. They needed to swipe a card and see it work.

How we approached it

A 3-engineer pod paired with our QA lead, with a Hashorn PM coordinating across founder, engineering, and external (Stripe, KYC vendor). Week zero: a one-page product brief and a risk register. We modeled the ledger first, financial correctness above all, picked Stripe Issuing for the rails, and committed to a weekly Friday demo cadence.

AI handled scaffolding, type generation, and PR review. Humans owned the architecture, the financial-correctness tests, and every line that touched money.

What we shipped

Week 1–2, Foundation

  • Multi-tenant SaaS skeleton with auth, RBAC, and audit logs
  • Postgres ledger primitives with double-entry constraints enforced at the database level
  • Stripe Issuing integration with idempotent webhook processing

Week 3–4, Customer surface

  • Cardholder dashboard (transactions, balance, card management)
  • Real-time transaction feed via Stripe webhooks → Postgres → SSE to the client
  • Card creation flow with KYC vendor integration

Week 5, Operations

  • Admin console: card freeze/unfreeze, manual transaction review, refund initiation
  • 12-page operations runbook covering on-call, incident response, and Stripe escalation paths
  • Playwright regression suite covering 14 critical flows; runs on every PR

Week 6, Hardening + launch

  • Production deploy to AWS (ECS + RDS); blue/green rollout for the API
  • Monitoring (Datadog) with alerts on ledger imbalance, webhook failure, and authentication anomalies
  • Internal security review + handover

Outcomes

  • Six weeks from kickoff to live card-issuing product. Demo day featured a live transaction processed end-to-end on stage.
  • Zero production incidents in the first 30 days post-launch.
  • Rivermint closed their seed round on time with the working demo as the centerpiece.
  • Financial-correctness tests caught two real bugs that AI-generated code introduced, one off-by-one in fee calculation, one race condition on concurrent webhook processing. AI-augmented didn't mean AI-trusted.

What we'd repeat

The financial-correctness suite was the single highest-leverage decision of the engagement. Writing it before any business logic meant every change had to prove correctness, not just compile. AI is fast at generating code that compiles; only humans can write the assertions that actually catch financial bugs.

Six weeks felt impossible until week four, when we ran our first live transaction. Hashorn turned our deck into a product investors could actually click on.
AP

Aarav Patel

Founder & CEO, Rivermint

Want a result like this?

Tell us what you're building, we'll tell you how we'd ship it.

Book an intro call →