Full-stack TypeScript Engineer : Take an E-commerce Storefront builder to Production (Cloudflare)

WHAT WE'RE BUILDING A subscription business that builds, hosts and maintains websites for small businesses in South Africa. A customer signs up, describes what they want, and sees a working draft before paying anything. When they approve it, we take the first payment, start a monthly subscription, and put the site live on their own domain. After that we host it, patch it and handle changes. The pitch is "no upfront investment". That only works if the build is mostly automated, which is the engineering problem underneath everything below. WHERE IT ACTUALLY IS The applications are built and heavily tested. Customer portal, composition engine, marketing site, and a full subscription engine with proration, dunning, invoicing and VAT. Buyer-side checkout works. None of it has been deployed yet. Payments are built against PayFast and proven in sandbox, but have never run against a live merchant account. THIS ENGAGEMENT: THE STOREFRONT We are starting with one thing. Get the online store working properly as a product, so it can be sold and attached to sites we already run. That means: take the existing code to production on real infrastructure, walk a detailed go-live runbook, fix what real deployment exposes, and make the storefront something an operator can attach without engineering help. Additional phases to this project: domain registrar automation, mailbox provisioning, and cloud orchestration. WHERE IT IS HEADING The direction is full automation: a customer approves, and the platform registers the domain, provisions hosting, creates mailboxes and publishes with nobody involved. Three gaps stand in the way today. (Depending on what they select as a product) 1. No cloud provider API automation. Publishing currently flips a database flag and runs a build. Creating the worker, attaching the custom domain and writing DNS records is a person at a dashboard. 2. No domain registrar integration. The port and a fake exist, so the shape is defined and the calling code is tested. The real implementation is missing. 3. No mailbox provisioning. We sell email seats and cannot create one. That is later work with its own budget. It is here so you know what you are building toward, and so you can tell me how the storefront work should be sequenced to make it easier rather than harder. STACK - TypeScript throughout - Cloudflare Workers, Hono, D1, KV, R2, Durable Objects, Queues - React Router 7, server-rendered, no client state layer - Firebase auth verified in-worker - PayFast for payments, Amazon SES for transactional email - Tailwind, shadcn, Base UI on a versioned design system - Astro for the marketing site - Vitest (Workers pool) and Playwright REQUIRED - Strong TypeScript in a codebase with real type discipline and a strict gate. - You have shipped AND operated something on serverless infrastructure. Cloudflare Workers specifically is a strong plus. - SQL you can reason about. The data layer is hand-written, not behind an ORM. - You write tests without being asked and can say what each would catch. - You can follow a runbook literally and report the difference between what it said and what happened. - Written English good enough that a stranger can act on your notes. VALUABLE - Recurring payments: subscriptions, proration, dunning. PayFast especially. - E-commerce checkout, carts, shipping rates, order state. - Cloudflare Workers in production, especially Durable Objects or Queues. - South African vendor context: local registrars, mailbox providers, ZAR. HOW WE WORK - Tests first. Write the failing test, make it pass, refactor. - Prove it, do not assert it. Paste the command and its output. If you did not run something, say so. Unrun is not passed. - Money paths are guarded: no refunds, no manual retry, cancellation at period end. Those guards are binding. - The system must fail safe. A half-provisioned customer is worse than a failed one, and refunds are not available to us by policy. - Stay in the files the task names. Report anything else, do not fix it in passing. NOT A FIT IF - You need a fully specified ticket before you can start. - You would rather rewrite than understand. - You report work as done that you have not run. First engagement is one small paid task before any ongoing commitment. It will be scoped, it will have a test, and it will be reviewed like everything else.