Next.js app needs its backend built — Postgres, auth, payment integration

WHAT EXISTS We have a complete, working web application built in Next.js 16 / React 19 / TypeScript / Tailwind 4. Around 16,500 lines of TypeScript across 21 routes and 45 distinct screens — every state finished and designed, including the awkward ones: funded on one side only, expired, disputed, drawn, voided, settled. It runs, and you can click through the entire product end to end. Underneath the screens sits a domain layer of about 5,600 lines in plain TypeScript with no React in it: the state machine, all the money and payout calculations, and the business rules. It has 62 automated assertions covering every settlement path, and it imports nothing from the interface — so it moves independently of the frontend. What it does NOT have is anything that touches the real world. Data is held in memory rather than a database, sign-in is a demo account picker rather than real authentication, and all third-party services are mocked at the network layer behind a single transport module. The mocks were written to mirror the real API shapes — correct OAuth flows, correct endpoints, correct rate-limit handling — so they should be close to a drop-in replacement. The codebase includes a README, a developer handover document, and a written list of exactly what is not built and where each gap sits in the code. WHAT WE NEED Take it to production. We've broken this into ten areas and we'd like your estimate against these specific headings: 1. Database — design and build a proper Postgres schema and replace the in-memory store. All reads and writes already go through one repository-shaped module. 2. Authentication — real signup, login, sessions, email verification, password reset. 3. Money-path hardening — every balance movement inside one database transaction, protection against a repeated request paying out twice, and server-side authorization on every action. The places this matters are already identified and commented in the code. 4. Payment processor integration — deposits and withdrawals via a third-party processor. Withdrawals go direct to the end user; we are not custodial. Includes webhook handling and reversals. 5. Identity verification — integrating a third-party KYC provider, including the asynchronous review states. 6. Eligibility checks — age and location verification via a provider, checked at the point of use rather than self-declared. 7. Two consumer API integrations — OAuth 2.0 in both cases; one uses webhook subscriptions and event ingestion, the other polls for results under strict rate limits with required backoff. The flows, scopes and edge cases are already specified and mocked. 8. Transactional email and scheduled jobs — verification, invitations, notifications, plus a job queue and secured cron endpoints. 9. Admin and support tooling — issuing refunds, correcting a balance by hand, and an audit trail. 10. Deployment and operations — hosting, staging and production environments, CI, error monitoring, backups with a tested restore, and end-to-end testing with real funds before launch. ABOUT THE PRODUCT A consumer web platform where users hold a balance, transact with each other, and are paid out according to outcomes. It handles real money in the US market. The company is incorporated, has legal counsel engaged, and the compliance work is complete. We'll describe the product properly to shortlisted candidates under a simple mutual NDA. If you aren't comfortable working on a product that moves real money between users, this isn't the right fit. WHAT WE'RE LOOKING FOR - Strong Next.js (App Router) and TypeScript - Real production Postgres experience, especially transactions and concurrency - Payment processor or fintech integration experience - OAuth 2.0 and webhook handling - Someone comfortable working WITH an existing codebase rather than rewriting it. The frontend and the domain logic are settled. We are not looking for a redesign or a re-architecture. YOUR PROPOSAL Please don't send a generic proposal — we'll only read ones that answer these: 1. An hours estimate broken down by the ten areas above. A single total isn't useful to us; we want to see where you think the time actually goes. 2. What you see as the biggest technical risk in this project, and how you'd handle it. 3. One example of a project where you took over an existing codebase, and what you did first. 4. Would you recommend Supabase, plain Postgres, or something else — and why? 5. Your weekly availability. We can share the full codebase and documentation with shortlisted candidates under NDA, so you can estimate properly rather than guess.