Senior Full-Stack / Platform Engineer or Small Team for Production-Grade Flutter Web Platform

We are looking for a highly experienced Senior Full-Stack/Platform Engineer, Technical Lead, or small delivery team to bring an existing Custom Development Studio and Flutter full-stack application builder to production readiness. The platform already has an established codebase and supports AI-assisted code generation, repository workflows, live previews, Flutter/FastAPI/PostgreSQL application generation, authentication, RBAC, Git integration, deployments, rollback, secrets, and usage metering. This is not a greenfield MVP or a simple Flutter application. The objective is to harden and complete the existing system so it can support a controlled beta release followed by General Availability. The first production target is: Flutter Web frontend Python/FastAPI backend PostgreSQL database React/Vite platform interface Native Android and iOS store releases are outside the initial scope. Core Responsibilities The selected contractor will contribute across the following workstreams: Architecture, CI/CD and Release Governance Review the existing architecture and codebase. Define and document the supported product and technology matrix. Establish reproducible CI pipelines using pinned containers and dependencies. Ensure clean checkout, installation, testing, and build execution. Create traceable release evidence linked to commits and release IDs. Maintain implementation, rollback, testing, and operational documentation. Flutter Full-Stack Generator Improve deterministic generation of Flutter Web, FastAPI, PostgreSQL, migrations, authentication, RBAC, organisation scoping, relations, rich fields, validation, and commerce workflows. Version generator inputs, templates, schemas, and output contracts. Ensure identical inputs and generator versions produce reproducible output. Build and maintain at least eight representative acceptance fixtures. Execute Flutter analysis, tests, release builds, backend tests, migrations, OpenAPI export, and browser-to-API-to-database smoke tests. Produce self-contained generated repositories with pinned dependencies, CI, Docker, Compose, health checks, migrations, seed data, runtime configuration, and documentation. Runtime Security and Tenant Isolation Design or harden a sandbox or microVM-grade boundary for untrusted tenant code. Implement default-deny outbound networking and allowlisted egress. Enforce CPU, memory, process, disk, execution-time, output, and concurrency limits. Prevent cross-tenant access to processes, filesystems, networks, secrets, databases, logs, and artifacts. Implement vulnerability scanning, secret scanning, SBOM generation, image signing, and provenance controls. Test against fork bombs, disk exhaustion, zip bombs, SSRF, private-network access, path traversal, websocket abuse, and log flooding. Deployment, Domains and Recovery Implement an auditable deployment state machine covering build, migration, verification, cutover, live, failure, and rollback states. Produce immutable release manifests and deploy artifacts without rebuilding. Implement atomic cutover and automatic rollback following failed health checks. Maintain separate secrets and databases per environment. Implement secret rotation, revocation, audit history, and leak prevention. Add DNS ownership verification and managed TLS certificate lifecycle handling. Implement encrypted PostgreSQL backups, integrity checks, restore automation, and recovery rehearsals. Apply safe expand/contract database migration practices. Observability and Operations Implement structured logs, metrics, and distributed traces across generation, builds, sandboxes, previews, deployments, APIs, and databases. Propagate correlation IDs across the complete workflow. Build dashboards for availability, errors, latency, queues, build times, deployments, resource use, and cost. Configure alerts with named owners and operational runbooks. Implement synthetic create-to-generate-to-preview-to-deploy monitoring. Perform load testing, a minimum 24-hour soak test, and controlled failure-injection testing. Metering, Quotas and Stripe Billing Implement an idempotent usage ledger for LLM tokens, embeddings, build minutes, sandbox consumption, storage, deployments, and egress. Add canonical entitlement and quota enforcement. Prevent duplicate charging when events or webhooks are replayed. Support Stripe subscription upgrades, downgrades, cancellations, and payment failures. Reconcile internal usage against provider invoices within the defined tolerance. Add tenant/provider spend alerts and authorised kill switches. Product Readiness and QA Complete user flows for build, retry, cancellation, deployment, failed health checks, and rollback. Ensure actionable and correlated error reporting. Validate organisation-level and project-level RBAC. Improve responsive behaviour and WCAG 2.1 AA accessibility. Build Playwright coverage for the ten highest-priority user journeys on Chromium and WebKit. Implement redacted support bundles and operational support workflows. Produce technical, user, deployment, recovery, and release documentation. Key Acceptance Targets The engagement will be evaluated using objective evidence, including: At least 19 successful clean generation/build runs out of 20. Zero Flutter analyzer errors and zero failing generated tests. Live browser-to-FastAPI-to-PostgreSQL testing across all required fixtures. Zero detected secrets in generated or retained artifacts. Zero unresolved Critical or High security findings. One hundred hostile sandbox runs without cross-tenant impact or host degradation. Thirty successful staging deployments without orphaned resources or ambiguous states. Rollback to the last-known-good release within ten minutes. API and preview availability of at least 99.9% during the canary window. p95 non-LLM/non-build API latency below 500 ms. p95 warm preview start below 90 seconds. p95 Flutter Web release build below five minutes on the approved worker class. At least 95% representative generation/build success. At least 99% deployment success and 100% rollback success during qualification. Successful 24-hour soak test with no resource leaks or unbounded queue growth. Billing reconciliation difference below 2%, excluding documented timing adjustments. No unresolved P0/P1 issues before General Availability. Expected Delivery Milestones M0: Discovery, architecture, reproducible baseline and technical foundation M1: Flutter full-stack generator enhancement M2: Platform security and runtime hardening M3: Deployment automation, secrets, domains, backups and recovery M4: Observability, performance and operational readiness M5: Billing, usage metering, quotas and entitlements M6: UX, accessibility, support tooling and documentation M7: QA, security validation, disaster-recovery rehearsal and release readiness M8: Internal rollout, private canary, beta, GA rollout and hypercare Required Experience Advanced Flutter Web and Dart experience. Strong Python and FastAPI development experience. Strong PostgreSQL schema, migration, performance, backup, and recovery knowledge. Experience with React and Vite. Production CI/CD and containerised build systems. Docker and container orchestration experience. Secure execution of untrusted or tenant-controlled code. Multi-tenant SaaS security and RBAC. Deployment state machines, immutable releases, health checks, and rollback. OpenTelemetry or equivalent logging, metrics, and tracing systems. Stripe subscriptions, webhooks, usage metering, and billing reconciliation. Automated testing with Flutter Test, backend test frameworks, and Playwright. Experience with SLOs, load testing, soak testing, incident response, and operational runbooks. Excellent technical documentation and written English. Strongly Preferred Experience with gVisor, Kata Containers, Firecracker, or comparable isolation technology. Previous work on low-code, no-code, AI code-generation, developer-platform, or PaaS products. Experience producing SBOMs, signing container images, and managing build provenance. Security architecture or independent penetration-testing experience. Previous responsibility for taking a complex SaaS platform through beta and GA. Engagement Structure We expect approximately 40 hours per week. The engagement will be milestone-based, beginning with a paid discovery and technical validation phase. The first milestone should produce: Codebase and architecture assessment Confirmed scope and supported-product matrix Technical risk register Threat-model and isolation recommendation Reproducible CI/build assessment Milestone delivery plan Resource and role recommendation Fixed or estimated pricing for the remaining milestones A single senior engineer may apply, but must clearly identify which areas require additional specialists. Small teams or agencies must identify the proposed lead engineer and the people who will perform the actual work. Application Instructions Please include: A short explanation of the most technically relevant platform you have delivered. Your specific experience with Flutter Web, FastAPI, PostgreSQL, CI/CD, secure sandboxing, observability, and Stripe. Links to relevant products, repositories, case studies, or architecture samples. The proposed delivery team and each person’s role. Your recommended approach for the paid discovery milestone. Your estimated duration and cost for M0. Your initial estimate for the complete M0-M8 programme. Your weekly availability and timezone. Any major technical or delivery risks you identify from this description. Screening Questions How would you safely execute untrusted tenant code while preventing cross-tenant and host impact? How would you make generated Flutter/FastAPI/PostgreSQL applications deterministic and reproducible? Describe a deployment architecture that supports immutable releases, database migrations, atomic cutover, and rollback within ten minutes. How would you test tenant isolation against SSRF, fork bombs, disk exhaustion, path traversal, and leaked resources? How would you design an idempotent usage ledger and reconcile it with Stripe? What evidence would you require before approving a platform like this for General Availability? Which parts of this programme should not be owned by one engineer, and why? Please do not apply if your experience is limited to building standard Flutter mobile applications or basic CRUD websites. This project requires hands-on production platform, infrastructure, security, deployment, and operational experience.