Senior Full-Stack TypeScript Engineer - Sales Tax Compliance Platform (Hard Deadline Sept 15)

TaxViewr is a sales tax compliance platform for ecommerce sellers. It connects to a merchant's payment platforms, tracks their sales by jurisdiction, and alerts them when they cross an economic nexus threshold in a US state so they can register before the state finds them. I am the founder. I am an Enrolled Agent with 12+ years in tax practice, so I own all tax logic and rule research. I am not looking for someone to figure out sales tax. I need a strong engineer to build the application around a domain core that already exists, is typed, and is tested. This is a well-specified project. You will not be guessing at requirements. ## Hard deadline **Everything must be live and working by September 15, 2026.** This is not a soft target. If you cannot commit to that date, please do not apply. I would rather hear "that timeline is not realistic for this scope" in your proposal than find out in week five. If you think the scope needs to shrink to hit the date, say so and tell me what you would cut. ## What already exists You will receive a working repository containing: - **A pure-function nexus evaluation engine** in TypeScript. No I/O, fully deterministic. Handles measurement basis (gross vs retail vs taxable sales), conjunctive vs disjunctive threshold logic, marketplace facilitator treatment, and rolling vs calendar measurement periods. - **Complete US rule data.** All 48 jurisdictions that enforce economic nexus, effective dated and versioned, plus explicit records for states with no sales tax. - **103 international VAT/GST registration rules** for non-resident digital services sellers, covering the EU, UK, and most major economies. - **A PostgreSQL schema** (Drizzle ORM) with multi-tenant isolation, an append-only transaction ledger with idempotency constraints, and an immutable audit table recording every determination with its rule version. - **86 passing tests**, clean strict-mode TypeScript build. - **A rule verification framework** that refuses to produce a customer-facing determination from unverified rule data. The architecture is deliberately conservative because this is a compliance product. Money is stored as integer cents. The ledger is never updated in place; refunds are new rows referencing the original. Rules are versioned data, not code, so a determination made today can be reproduced in two years when a client gets a state notice. These constraints are not negotiable. If you disagree with any of them, I want to hear it before we start rather than discover you worked around them. ## What you will build **1. Security and architecture review** *(first, before anything else is built)* Review of the schema, tenant data isolation, and the multi-tenant query layer. Written findings. I want problems found before the pipeline is built on top of the schema, not after. **2. Aggregation layer** SQL and repository code that turns the transaction ledger into the aggregate shape the engine consumes. Must correctly handle each measurement period type, split direct from marketplace sales, and split by measurement basis. Tested against a seeded database. **3. Stripe ingestion** OAuth connection flow, historical backfill, live webhook ingestion with signature verification, idempotent upserts, cursor-based incremental sync. **4. Shopify ingestion** Same, including correct extraction of ship-to jurisdiction and correct identification of marketplace-facilitated orders. **5. API and background jobs** REST endpoints for the frontend, scheduled re-evaluation of nexus positions, alerting when a threshold is crossed or approached. **6. Frontend** Next.js. A merchant dashboard showing nexus status by jurisdiction with threshold progress, crossing dates, and registration deadlines. An admin view for support. Clean and functional; this does not need to be a design showcase. **7. Deployment** Render, with migrations, structured logging, and Sentry. Working in production, not just on your machine. ## Requirements - Strong TypeScript, comfortable with strict mode and writing code other people can read - Real production Postgres experience including migrations and query performance - Direct experience integrating a payment or ecommerce platform API (Stripe, Shopify, PayPal, Square, or similar) - Production webhook experience: signature verification, replay handling, idempotency, and backfill that overlaps with live sync - Next.js - You write tests. Not optional on this project. - Clear written English and a habit of flagging problems early rather than late **Nice to have:** Inngest or Trigger.dev, prior fintech/accounting/compliance work, Drizzle ORM. ## How I work - I read the code. If I cannot follow it, I will ask you to explain or simplify. I am accountable for what this software tells clients, so I do not ship code I do not understand. - If you think something in the existing codebase is wrong, tell me early. - Milestones are defined and paid through Upwork escrow, funded before you start each one. - I do not work off-platform. ## To apply Generic proposals will not get a response. Please answer these directly: 1. **Describe a webhook integration you have built.** Specifically: how did you guarantee a duplicate delivery did not create a duplicate record? 2. **In a multi-tenant Postgres application, how do you prevent one tenant from reading another tenant's rows?** What are the tradeoffs of the approach you chose? 3. **You need to backfill two years of historical Stripe charges while live webhooks are arriving.** How do you sequence this so nothing is lost or counted twice? 4. **Given the scope above and a September 15 deadline, what is your milestone breakdown, price per milestone, and hours per week?** If you think the scope is too large for the date, tell me what you would cut. Include a link to code you have written that I can read.