High Tide Capital
Lending / Underwriting
Outcomes
Manual borrower-doc collection and offline contracts replaced with a multi-step intake funnel persisted in Postgres after each step.
Envelope flow runs on DocuSign's webhook with idempotent state transitions plus a reconciliation cron, catching the misses their docs glossed over.
Overview
HiTide Capital needed a modern underwriting platform to manage their lending pipeline. I built the borrower-facing validation and contract flow using Next.js and TypeScript, with DocuSign integration for e-signatures.
The backend uses a PostgreSQL database designed with Prisma ORM to track applicant data, underwriting decisions, and loan status through the full lifecycle, from application to funding.
Challenge
The existing process was manual and fragmented: borrower documents collected via email, contracts signed offline, loan tracking in spreadsheets. The goal was to digitize the entire flow into a single platform that could scale with the business.
Tech Stack
Architecture
Key Features
Borrower Validation
Multi-step borrower intake with identity verification, document upload, and eligibility checks before entering the underwriting pipeline.
Contract Flow
DocuSign integration for e-signature workflows. Contracts are generated, sent, and tracked without leaving the platform.
Loan Tracking
PostgreSQL schema designed to track the full loan lifecycle: applications, underwriting decisions, and funding status with Prisma ORM.
Lessons & tradeoffs
Borrowers see a clean funnel; the underwriting team sees a pipeline. The mistake would have been treating one as the real product and the other as an afterthought. Both had to be first-class, because the funnel earns the application and the pipeline closes the loan.
DocuSign's webhooks are reliable only if you're watching them, and a missed envelope status silently stalls a loan.
I made every state transition idempotent and ran a reconciliation cron alongside the webhook flow.
Treat third-party webhooks as best-effort. Idempotent transitions plus reconciliation caught the misses their docs glossed over.
Borrowers abandon, refresh, lose connection, and come back days later in the middle of an application.
I persisted state to Postgres after each step instead of holding the funnel in client-side state.
Multi-step forms are stateful products, not one-off pages. Server-persist each step and the user can always pick up where they left off.
The flashy part is the borrower funnel, but the people who live in the tool all day are the underwriters.
I designed the underwriter pipeline as a first-class surface against the same schema, not a reporting bolt-on.
The internal workflow is the product too. Build it with the same care as the thing the customer sees.