Fixed-price project: $7,250 — Estate financial reconciliation platform (FastAPI + Postgres)

Fixed-price project: $7,250 — Estate financial reconciliation platform (FastAPI + Postgres) Timeline: 5–7 weeks from spec freeze Payment: 4 milestones — $1,250 / $2,000 / $2,000 / $2,000 Team required: Two people — one senior lead, one implementer. Solo bids will not be considered. Location: Remote, any timezone The project A web service that helps estate executors and small law firms reconcile bank statements and produce factual financial workpapers. Phase 1 of a real business with pricing set, positioning done, and legal review underway. It is scoped to be sellable end to end on delivery. The design work is finished. At kickoff you receive a written spec, a UX prototype, an authentication spec, a payments and tax spec, and a typed API contract for the owner console. What I need is a competent team to build it. Team structure — read this before bidding Two people, clearly separated. Not a solo developer. Not an agency assigning four part-time people. The senior lead is accountable for the build and is my counterparty. They personally write the database schema and row-level security policies, the deterministic reconciliation engine, all cryptography, the authentication and session layer, the payment adapter boundary, the approval gate, and the owner console aggregation endpoint. They also review 100% of the implementer's work and sign off on every milestone. The implementer builds to that architecture and is reviewed on everything: the React SPA screens against the supplied prototype, resumable multi-file upload, the firm dashboard, the extraction correction UI, PDF and CSV generation, transactional email, Stripe catalog wiring behind the adapter, and the intake flow. How I verify the senior is real The common failure is a senior who appears on the proposal and never touches the repository. Three checks, non-negotiable: The senior lead personally attends the technical screen. Not a salesperson, not the implementer. I get repository read access from day one. The senior lead's name must appear as commit author on the reconciliation engine, the security work, and the schema. Both people are named at signing. Substitution mid-project requires my written approval. If the senior lead's commits stop appearing, that is a milestone failure, not a staffing detail. Tech stack — frozen, do not propose alternatives Python 3.11 / FastAPI (single service) · Postgres via Supabase with row-level security · private S3 with a 7-day lifecycle delete rule · Cloudflare · Stripe · React SPA (Vite) · deployed to Render · LLM document extraction (OpenAI or Anthropic, your choice) with deterministic Python for all reconciliation arithmetic. Frozen because this is architected as the foundation for a much larger v2 build later, not a throwaway MVP. Scope — frozen Products Eight SKUs total: two consumer, six firm. They cover a workpaper PDF, a transaction-level CSV, a bundle, a mail-in scanning add-on, a tokenized client-upload link, Maryland probate form population, and additional forms. Pricing mechanics that affect the build: All prices tax-exclusive, displayed as "plus tax" Sales tax applied at checkout from a configurable rate, stored as its own field and never merged into revenue. Additional states must be addable without a deploy. Firm volume discount on a rolling 30-day matter count, three tiers, auto-applied at checkout. Stripe does not do this natively — it is server-side logic against order history. Deferred unlocking: a customer buys one deliverable and later pays to unlock another on the same matter Platform foundation Role-based access — consumer, firm, owner — enforced with Postgres row-level security Server-side scoping on every read and write. Client-supplied IDs are never trusted. Audit log as a first-class table: consent, PII access, share events, deletion Async processing queue, malware and format scan on upload, AES-256-GCM at rest Deterministic reconciliation engine — sole checking and savings accounts, reconciled to $0.00 tolerance, passing a test suite I supply LLM extraction pipeline turning bank statement PDFs into structured transactions PDF report generation and importable transaction-level CSV export Two exception types: one returned to the customer, one routed to admin Tokenized share link so a customer can send their report to an attorney or CPA, plus a one-time recipient welcome token Transactional email: completion, deletion warning, share confirmation Authentication — full spec supplied at kickoff Email address plus password, then a 6-digit code emailed at sign-in. Not magic links. Password captured during purchase, not deferred to an activation email Length-only password rules. No composition requirements, no rotation, no expiry. Paste must work. "Remember this device" suppresses the code, never the password Rate limiting on code requests and code attempts No SMS anywhere. Do not build a phone number field for authentication. Passkeys offered to all users, required of none Self-service account recovery completing in a single session. There is no support staff to run a manual review queue. Authentication must never gate delivery of a paid deliverable. The workpaper is delivered by a signed, time-limited link that opens with no session. A customer locked out of their account still receives what they paid for. Email deliverability is a build requirement. Sign-in codes, resets, and delivery links all travel by email, so a message in a spam folder is indistinguishable from a broken product. Transactional provider on a subdomain separate from marketing mail, SPF/DKIM/DMARC verified before launch, plain message bodies with no tracking pixels or link shorteners, bounce and complaint logging. Payments architecture One module imports the Stripe SDK. Everything else speaks to a processor-neutral adapter in integer cents. Verifiable by grepping for stripe and finding exactly one file. Hard acceptance criterion. Our database is the system of record for orders. Stripe stays system of record for money movement. Sales history must be reconstructable without logging into a vendor. Every order records the buyer's state, required and not nullable from the first order. This supports future sales-tax nexus tracking and cannot be reconstructed retroactively. No dollar amount is written into any component, page, or template. Every price renders from one catalog source, including build-time injection into the static marketing pages. A page advertising a price that differs from what is charged is a legal exposure, not a cosmetic bug. Stripe products referenced by lookup key, never price ID, so a reprice is a dashboard action rather than a deploy Owner console — backend only, frontend is supplied The React console is built and handed to you complete, along with contract.ts — a typed, commented specification of the single endpoint that feeds it. You implement that contract; you do not design it. One authenticated endpoint returning the typed shape exactly, an owner role enforced at the same RLS layer as everything else, a Stripe webhook mirror for charges/refunds/disputes into local tables, and all aggregation server-side. Revenue net of tax, broken out by period, channel, and SKU. Tax and order counts per state. Test coverage on the aggregation against a fixture supplied with the contract. UX Static HTML marketing site (already built) linking into the React SPA portal Multi-file resumable uploads, drag and drop Intake questions covering account titling. Answers tag report sections and never gate uploads. Firm-branded reports — firm name as a text field, no logo uploads Extraction correction workflow: firm reviews and corrects extracted values, every edit audited, forms generated from a frozen snapshot after approval "For Attorney Review" draft state with watermark, cleared on approval The constraint that governs the whole product The software may extract, calculate, categorize and present. It must never conclude, determine, exclude, advise or recommend. This is an unauthorized-practice-of-law boundary. It shapes UI copy, PDF section headings, and the approval gate. Where the software suggests a value, a human must confirm it and the confirmation must be recorded. The senior lead owns this boundary and signs off on it. Explicitly out of scope Multi-user firm accounts, seat management, invitations, per-seat billing · firm logo uploads · bar number API verification (format-check regex only) · trust, brokerage, retirement and credit card reconciliation · court forms beyond the two named at kickoff · mail-in workflow for firms · lead-generation integrations · native mobile apps · customer service chatbot · SMS of any kind. Anything on this list becomes a change order at additional cost, scoped and approved in writing before work begins. Milestones # Payment Gate # Payment Gate 1 $1,250 Signing and spec freeze. Architecture and schema documented by the senior lead and approved by me before implementation starts. 2 $2,000 Foundation — auth per spec, database with RLS, S3 with lifecycle rule, audit log table, payment adapter in place, one working upload → parse → store flow end to end 3 $2,000 Reconciliation — deterministic engine passing the test suite I supply, against synthetic bank statement data 4 $2,000 Delivery — all 8 SKUs live in Stripe, both portals functional, report and CSV generation working, share flow and recipient tokens working, deferred unlock working, volume discount auto-applied, tax applied and stored separately, owner console endpoint returning live figures against the supplied contract 15% of the total is held back until the acceptance criteria in the supplied specs pass. Released within 5 business days of sign-off. Each milestone submission must include a statement from the senior lead confirming they reviewed the work in it. Change orders: any addition or modification to frozen scope requires a written change order with a delta price before work begins. Bug fixes and clarifications on already-scoped items are your responsibility, not a change order. Overruns: overruns on frozen scope are yours. Overruns caused by my written change orders are mine. Requirements A 30-minute technical screen before signing, answered personally by the senior lead. It covers reconciliation logic, async handling of large file uploads in FastAPI, and applied cryptography at the code level. Reconciliation reviewed by someone with financial software experience. "The model said the numbers add up" is not validation. The arithmetic is deterministic Python. The LLM extracts; it never calculates. One week of post-delivery support for bug fixes on scoped items, included in the fixed price. At signing: both team member profiles, a sample of prior FastAPI or backend Python work, repository read access, and a proposed schedule with milestone dates. About me A solo business owner in Maryland building this as a real product. Legal review is underway with counsel, vendor research is complete, pricing is set, and the portal prototype, authentication spec, and payments spec are written and waiting for you at kickoff. I make decisions quickly, I pay milestones on time, and my specs are unusually detailed — you will not be guessing what I want. In exchange I expect the scope discipline described above. I am not selecting on price. Every bid is evaluated on the senior lead's experience and the technical screen, whether it comes in at $7,250, under it, or above it. If your number is above it, say what the extra buys. In your proposal, name the single highest-risk item in this scope and why. One paragraph. I read that paragraph first.