Senior Full-Stack Lead to Build Production-Ready B2B SaaS

# Senior Full-Stack Technical Lead or Product Team to Build Production B2B SaaS KINSTALL is a pre-launch B2B SaaS product for independent kitchen installers and small installation businesses in the UK. We are seeking either: * One highly experienced Senior Full-Stack Developer / Technical Lead capable of taking end-to-end ownership; or * A small, established product-development team with a clearly identified Technical Lead and implementation team. Candidates and teams based in Romania are preferred because of language, timezone and direct-collaboration advantages. However, exceptional candidates and established teams from other countries will also be considered where their experience, communication, availability, delivery controls and commercial offer are compelling. This is not a prototype, disposable MVP, generic quoting tool or visual redesign of an existing application. The required deliverable is a secure, tested, documented and production-ready public V1. The public V1 must be built as a complete, monetisable quote-first SaaS on durable platform foundations. It must support controlled future evolution from KINSTALL Solo to multi-user installation businesses and, following commercial validation, future B2B installation infrastructure—without requiring replacement of the core identity, tenancy, authorization, calculation, versioning, snapshot, ownership or audit foundations. Future KINSTALL Teams and KINSTALL Pro capabilities are architectural-continuity requirements, not automatic V1 implementation scope. Candidates must review this complete job description together with both attached documents: * KINSTALL V2 Technical Vendor Brief; and * KINSTALL Public V1 – Durable Platform Foundations and Architectural Continuity Requirements. Any contradiction, ambiguity, proposed exclusion, dependency or scope assumption must be identified in writing before contracting. The final signed Statement of Work and accepted paid-discovery outputs will govern implementation. ## PROJECT OUTCOME Build and launch a multi-tenant SaaS platform that allows each kitchen installer to: * Create and control a personal installation-time and pricing profile; * Configure personal norms, multipliers and commercial pricing rules; * Produce reproducible time and price estimates through a guided quote workflow; * Generate, download and send professional branded PDF quotations; * Maintain customer and quotation records relevant to the quotation workflow; * Review useful quotation and business information through a focused dashboard; * Compare predicted installation time with completed-job evidence; * Review deterministic calibration recommendations and manually accept, edit, reject or defer them; * Maintain full control over profile publishing, version history and rollback; * Subscribe to and manage access to the platform through Stripe billing. The system must never automatically modify or publish an installer’s active profile. The V1 must remain focused on professional quotation and controlled learning from completed jobs. It must not become a full CRM, scheduling platform or installation-management system during this engagement. ## EXISTING SOURCE MATERIAL A mature internal calculation engine, maintained workbook and existing private application repository already exist and will be used as behavioural evidence, product-direction evidence and parity references. The private repository is a behavioural and product-direction source of truth that must be reviewed during paid discovery. It is not the target production architecture and must not be copied wholesale. The selected provider must document which existing behaviours and product concepts will be: * Retained; * Reconstructed; * Improved; * Deferred; or * Deliberately excluded from the public V1. The selected provider will reconstruct the relevant deterministic calculation logic in strict TypeScript within a new, separate repository. This is not a request to transfer or rebuild the existing internal CRM, bookings, scheduling or operational application. Detailed proprietary coefficients, calculation rules, reference cases, workbook materials and relevant repository content will be disclosed progressively only after appropriate confidentiality arrangements, candidate verification and controlled-access approval. Repository access will be: * Staged; * Limited to named and approved contributors; * Read-only where practical; * Subject to least-privilege principles; * Restricted to the material needed for evaluation or paid discovery; and * Revoked when no longer required. Credentials, unnecessary personal data and unrestricted production access will not be supplied as discovery material. ## CORE DELIVERABLES ### 1. Production-ready SaaS foundation * Multi-tenant architecture; * Authentication and account management; * Strict tenant isolation and server-side authorization; * PostgreSQL Row-Level Security where appropriate; * Subscription entitlements and Stripe billing; * Audit trails; * Stable resource ownership; * Staging and production environments; * Client-controlled repositories and service accounts; * Conceptual separation between tenant, organisation, workspace, user, membership, role, billing account, subscription and entitlement; * A foundation that does not permanently assume that one tenant is always one individual installer; * A foundation that permits later multi-user organisations without requiring a tenancy or authorization rewrite. The initial user experience may be designed for a solo installer, but the underlying data and authorization model must not prevent controlled future development of KINSTALL Teams or KINSTALL Pro. ### 2. Calculation engine reconstruction * Strict TypeScript implementation; * Approximately 15 calculation stages; * Deterministic server-side calculations; * No browser-authoritative calculation logic; * Clear separation between installation-time estimation and commercial pricing; * Documented canonical input and output contracts; * Explicit numeric, rounding, default and exceptional-case semantics; * Automated stage-level and end-to-end parity tests against an approved reference corpus; * Regression coverage for every discovered discrepancy; * Traceable handling of differences between the existing engine, workbook and approved V1 behaviour. ### 3. Personal profile and versioning * Guided Personal Installation Profile setup; * Optional baseline or founder profile where appropriate; * Editable installer-owned norms; * Editable and logically grouped multipliers; * Advanced profile editor; * Separate Commercial Pricing Policy; * Draft and published profile versions; * Historical versions; * Version comparison; * Audit history; * Rollback; * No automatic profile publication or modification. The active profile must never be represented only as one permanently mutable record that destroys historical context. ### 4. Complete quote workflow * Customer management required for the quotation workflow; * Mobile-first guided quote wizard; * Conditional questions and autosave; * Stage summaries; * Predicted and chosen hours; * Justified manual overrides; * Separate calculation of installation effort and commercial price; * VAT, deposit and balance rules; * Quote statuses; * Search; * Duplication; * Immutable issued-quote snapshots; * Exact preservation of relevant inputs, engine/profile versions, overrides and pricing context; * Reproduction of issued quotation results after later profile, pricing or engine changes. ### 5. PDF, email and quote documents * Professional branded PDF quotations; * Installer and customer information; * Assumptions and exclusions; * Quote validity information; * VAT, deposit and balance calculations; * Reconciled totals; * PDF download; * Transactional email delivery; * Quote-document history; * Reliable and observable delivery handling; * Appropriate pagination and visual-regression testing for representative quotation scenarios. ### 6. Completed-job evidence and manual calibration * Predicted-versus-actual comparisons; * Completed-job actual labour hours; * Fitter count and working days where relevant; * Scope changes, delays, problems, revisits and remedial information; * Eligibility rules; * Comparable-job counts; * Deterministic recommendations; * Before-and-after simulations; * Accept, edit, reject and defer decisions; * Draft profile changes; * Manual profile publication; * Audit history; * Rollback; * Zero automatic writes to or publication of the active installer profile. One tenant’s data must not train, modify or influence another tenant’s profile in V1. ### 7. Dashboard, settings and operational controls * Professional installer dashboard; * Useful quotation activity information; * Quotation value and status information; * Conversion information where the available data supports it; * Completed-job evidence and calibration information; * Quote history and search; * Business identity settings; * Branding settings; * Personal pricing and profile controls; * Account and billing settings; * Audit visibility; * Minimum operational support and administration controls. The dashboard must be useful without introducing unnecessary CRM, scheduling or installation-management complexity. ### 8. Professional public marketing website * Mobile-first public website for UK kitchen installers; * Product positioning; * Clear explanation of the problem and product; * Features; * Pricing; * FAQs; * Founder story; * Trust and legal pages; * Privacy, Terms and Cookies information; * Demo/contact flow; * Subscription journey; * SEO foundations; * Metadata, sitemap and robots configuration; * Open Graph information; * Structured data where justified; * Analytics and consent management; * Privacy-conscious analytics implementation; * Suitable performance and accessibility standards. ### 9. Testing, security and production handover * Automated unit tests; * Integration tests; * End-to-end tests; * Calculation parity and regression tests; * Tenant-isolation and authorization tests; * Negative cross-tenant tests; * Stripe billing and webhook tests; * Profile versioning and rollback tests; * Immutable snapshot and quote-replay tests; * PDF and email-delivery tests; * CI/CD; * Monitoring and actionable alerts; * Structured operational logging; * Backups and point-in-time recovery where supported; * Demonstrated restore procedure; * Demonstrated rollback procedure; * Security and operational documentation; * Deployment documentation; * Incident and support runbooks; * Full source-code and account handover; * Recorded handover sessions; * Minimum 90-calendar-day post-production defect warranty covering defects against the accepted scope. Warranty exclusions, response expectations and support arrangements must be stated clearly in the proposal. ## NON-NEGOTIABLE PRODUCT PRINCIPLES * The calculation engine must be server-authoritative and deterministic. * Each tenant must own and control its norms, multipliers and commercial pricing rules. * Installation estimation and Commercial Pricing Policy must remain separate domain concepts. * An issued quotation must not change when the installer later changes a profile, multiplier, formula or pricing rule. * No recommendation may automatically modify or publish an installer’s profile. * Material profile changes, calibration decisions, quote-status changes, document-delivery events and billing events must be auditable. * Tenant isolation must be enforced server-side and demonstrated through automated tests. * Client-supplied identifiers or user-interface filtering alone are not sufficient tenant protection. * The V1 must remain focused on quotation rather than becoming a full operational platform. * The implementation must be maintainable and capable of being extended through controlled migrations and new domain modules rather than a foundational rewrite. ## LONG-TERM ARCHITECTURAL CONTINUITY The immediate commercial product is KINSTALL Solo: a subscription SaaS for independent kitchen installers and small installation businesses. The long-term direction may include: * KINSTALL Teams for multi-user installation businesses; and * KINSTALL Pro as future installation infrastructure for retailers, manufacturers, showrooms and related B2B clients. The provider must not build the complete Teams or Pro products during this V1 engagement unless separately authorised through a written change of scope. However, the V1 architecture must avoid assumptions that would make future development disproportionately expensive, unsafe or dependent on replacing core foundations. The V1 must not permanently assume that: * One tenant always equals one person; * One organisation always has one user or workspace; * All users have the same permissions; * A booking and installation project are permanently the same resource; * Every future job has one worker, visit or appointment; * All evidence belongs to one workflow stage; * One generic price field can represent quotation value, customer payment, installer compensation, platform margin and future settlement; * All organisations use identical branding, approval rules, pricing rules or service regions. Architectural continuity requires credible extension points and documented migration paths. It does not require speculative services, empty database tables, premature abstractions or premature microservices. ## EXPLICITLY DEFERRED OR EXCLUDED FROM V1 Unless expressly included in an agreed milestone, the following are not required in the first public V1: * AI-authoritative functionality; * OCR and photo analysis; * Automatic calibration; * Full CRM; * Bookings and scheduling; * Cross-workflow follow-ups; * Full job-management or installation-management platform; * Customer, retailer, surveyor or inspector portals; * Installer marketplace; * Automated dispatch or installer matching; * Visual Evidence; * Job Readiness; * Job Reality; * Retailer order orchestration; * Branch hierarchies; * White-label retailer accounts; * Comprehensive SLA, QA, remedial or warranty management; * Customer payment collection for the installer’s installation work; * Installer payouts, complex payment splitting or settlements; * Accounting integrations; * Native mobile applications; * International country packs; * Generic multi-trade calculation engine; * Fully implemented team-product workflows; * Microservices without demonstrated operational need; * Low-code, no-code or provider-controlled application foundations. Excluding team-product functionality does not permit omission of the underlying organisation, membership, role and authorization foundations required for future continuity. ## PREFERRED TECHNICAL DIRECTION * Next.js App Router; * React; * Strict TypeScript; * PostgreSQL; * Drizzle ORM; * PostgreSQL Row-Level Security; * Zod; * Stripe with verified and idempotent webhook handling; * Tailwind CSS; * Vitest; * Playwright; * GitHub Actions; * Vercel or a clearly justified alternative; * Modular-monolith architecture rather than premature microservices; * Managed authentication or a clearly justified equivalent; * Managed object storage where required; * Reliable-delivery or outbox-style boundary where appropriate for Stripe, email and material external events. Equivalent alternatives may be proposed, but they must be clearly justified against: * Security; * Maintainability; * Testability; * Portability; * Delivery speed; * Total cost of ownership; * Client ownership; * Operational complexity; and * Future architectural continuity. Low-code or no-code application foundations—including Bubble, FlutterFlow, Lovable or similar platforms—will not be accepted for the production application. AI-assisted development tools may be used responsibly, but the selected provider remains fully accountable for architecture, security, licensing, code quality, testing, documentation, correctness and maintainability. ## ENGAGEMENT AND DELIVERY * Target delivery period: approximately 10–12 weeks after accepted discovery, subject to validated scope and implementation plan; * Providers should propose a realistic alternative where necessary and explain the critical path, staffing assumptions, dependencies and delivery risks; * High availability and near-full-time involvement are expected from the named Technical Lead or core implementation team; * Weekly written progress reports are required; * Weekly working-product demonstrations are required; * Development must take place from the beginning in GitHub and cloud/service accounts controlled by the client; * All paid source code, designs, schemas, migrations, tests, documentation, infrastructure configuration and project-specific assets must be assigned to the client; * All contributors and subcontractors must be disclosed and approved in advance; * Named contributors may not be added, removed or replaced without prior written client approval; * Final payment will be linked to production handover, documentation, account ownership and completion of agreed acceptance criteria. Written communication will be the primary project record. Proposals, clarifications, assumptions, decisions, scope changes, milestone acceptance and commercial commitments must be recorded in writing. Calls may be used for focused clarification, technical discussion and working-product demonstrations, but they must not replace the requested written answers. Material conclusions, changes or commitments discussed during a call must be confirmed in a written recap that both parties can review and verify. Project-management platforms such as ClickUp, Jira or Linear may be used as additional interfaces, but they must not replace client-controlled repositories, documentation, infrastructure, accounts or operational records. ## PAID DISCOVERY A separately contracted paid discovery and engine-characterisation milestone of approximately 5–10 working days may be completed before commitment to the full implementation. The exact duration must be justified and agreed in writing. Discovery must have a separately agreed: * Fixed price; * Duration; * Access plan; * Deliverables; * Acceptance criteria; and * Handover requirements. The discovery outcome must include: * Repository and behavioural-source audit; * Validated V1 scope; * Explicit inclusions and exclusions; * Proposed modular-monolith architecture; * Domain-boundary map; * Domain and tenancy model; * Entity-relationship model; * Tenant, organisation, workspace, membership and role relationships; * Authorization and tenant-isolation strategy; * PostgreSQL RLS strategy where applicable; * Automated isolation-test strategy; * Calculation-engine characterisation; * Canonical reference corpus; * Stage-level and end-to-end parity-testing strategy; * Profile-versioning design; * Immutable issued-quote snapshot design; * Stripe subscription, entitlement and idempotent-webhook design; * PDF, email and reliable-delivery design; * Security, privacy and retention summary; * CI/CD and environment plan; * Monitoring plan; * Backup, restore and rollback plan; * Target Architecture and Product Evolution Map for KINSTALL Solo → Teams → Pro; * Identification of V1 decisions likely to require material future migration; * Delivery plan; * Risk register; * Assumptions and dependencies; * Fixed-price implementation milestone proposal; * Realistic production-delivery timeline; * Measurable implementation acceptance criteria; * Production handover plan. All paid discovery outputs must be implementation-usable, documented, transferable and owned by the client. Completion of discovery will not create an automatic obligation for either party to proceed with the full implementation. ## ACCEPTANCE PRINCIPLES Final acceptance criteria will be confirmed through paid discovery and the signed Statement of Work. At minimum, acceptance should cover: * 100% parity on the mutually approved canonical reference corpus; * Zero known tenant-isolation failures; * Zero unresolved P0/P1 defects at production handover; * Reproducible issued quotations after profile, pricing or engine changes; * Tested profile publication and rollback; * Tested calibration decisions with no automatic active-profile mutation; * Tested Stripe success, failure, cancellation and reactivation flows; * Idempotent handling of Stripe webhook retries; * Reconciled quotation and PDF totals; * Passing agreed unit, integration and end-to-end tests; * Demonstrated backup restore; * Demonstrated production rollback; * Operational monitoring and alerts; * Complete documentation and account handover. Recruiting design partners, obtaining a particular number of paying customers or achieving a specific commercial conversion rate are founder and business objectives. They must not be treated as contractor-controlled technical acceptance criteria unless a separate, measurable commercial service is expressly agreed. ## BUDGET The displayed USD 35,000 budget is indicative and is intended to obtain comparable proposals. Please provide your own realistic commercial offer based on the complete description and both attached documents. A lower price will not be preferred where it depends on: * Silently reducing the scope; * Omitting required testing or security; * Using unnamed or junior replacement contributors; * Delivering a disposable technical foundation; * Leaving production accounts under provider control; or * Deferring essential production-readiness work without disclosure. Your proposal must clearly separate: * Paid discovery; * Implementation milestones; * Fixed price for each milestone; * Total estimated project price; * Payment schedule; * Approved change-request rate; * Third-party costs; * VAT or other applicable taxes; * Post-launch defect warranty; * Optional support and maintenance; * Assumptions; * Exclusions; * Dependencies; and * Commercial validity period. An open-ended hourly engagement is not preferred for the complete implementation. Any hourly change-request work must require prior written approval describing its expected cost, schedule impact and acceptance impact. Do not submit a placeholder milestone for the entire displayed budget without explaining the discovery price, implementation estimate and proposed milestone structure. ## OWNERSHIP AND HANDOVER The engagement must provide: * Development in client-controlled GitHub repositories; * Client-controlled hosting and deployment accounts; * Client-controlled database accounts; * Client-controlled Stripe account and configuration; * Client-controlled email, monitoring, analytics and storage accounts; * Assignment of all paid project-specific intellectual property and deliverables; * Complete source code; * Database schemas and migrations; * Test suites and fixtures; * Design-system and UI source assets; * Architecture Decision Records; * Environment and configuration inventory; * Deployment, rollback, backup and incident runbooks; * Recorded handover; * Secure return or deletion of proprietary source material at the end of the engagement. External systems must not become the sole owner of workflow truth, and the provider must not retain operational control over the production application after handover. ## WHO SHOULD APPLY The proposed Technical Lead must: * Have at least seven years of relevant professional software-development experience; * Demonstrate production SaaS experience involving multi-tenancy, subscriptions, PostgreSQL, audit/versioning or complex deterministic business logic; * Have strong TypeScript, React/Next.js, PostgreSQL, authentication, Stripe webhook and automated-testing experience; * Be able to communicate clearly in written English; * Take architecture ownership and deliver the platform end to end; * Be available for direct founder collaboration and weekly demonstrations; * Be capable of explaining and defending technical decisions clearly in writing; * If shortlisted, be capable of participating in a focused technical discussion with the principal questions or agenda supplied in advance where practical. Individuals and teams must: * Identify in advance every person who will work directly on the project; * Disclose each contributor’s location, employment or subcontractor status, weekly availability and responsibilities; * Maintain stable named-team continuity throughout delivery; * Disclose current commitments that could materially affect availability; * Work within client-controlled repositories, infrastructure and service accounts; * Accept that no contributor may be added or replaced without prior written approval. Romania-based candidates and Romanian development teams are preferred, but location is not an absolute restriction. International candidates and teams will be considered where they demonstrate stronger relevant experience, credible delivery capacity, clear written communication, suitable working-hour overlap and a competitive commercial proposal. Large agencies, distributed teams and offshore delivery models may apply only if the exact Technical Lead and implementation engineers are identified before contracting. Undisclosed outsourcing, anonymous developer allocation and unapproved team replacement will not be accepted. ## WHAT TO INCLUDE IN YOUR PROPOSAL Please include all of the following: 1. Your name, country, city, timezone and legal/contracting status; 2. Whether you are applying as an individual, agency or small product team; 3. Every person who will work directly on the project, including: * Full name; * Role and seniority; * Country, city and timezone; * Weekly availability; * Employee or subcontractor status; * Current relevant project commitments; 4. Confirmation that the named Technical Lead and implementation engineers will remain assigned throughout delivery; 5. Your contributor-substitution policy and confirmation that no contributor will be added or replaced without prior written client approval; 6. Two or three relevant production SaaS examples; 7. Your exact personal contribution—or each proposed contributor’s exact contribution—to every example; 8. Product dates, team size, technology stack and whether you created the architecture or joined an existing codebase; 9. Your written understanding of the KINSTALL product and its principal risks; 10. Your proposed architecture and delivery approach; 11. How you would separate tenant, organisation, workspace, user, membership, role and subscription concepts; 12. How you would implement and automatically prove tenant isolation; 13. How you would implement verified, idempotent and recoverable Stripe webhook processing; 14. How you would reconstruct the existing calculation engine while preventing semantic drift and proving deterministic parity; 15. How an issued quotation would remain reproducible after profile, pricing or engine changes; 16. How you would support future KINSTALL Teams and Pro development without prematurely implementing those products; 17. Which V1 decisions in your proposal could require material future migration; 18. Proposed discovery deliverables and acceptance criteria; 19. Proposed implementation milestones and estimated duration; 20. Earliest realistic start date; 21. Fixed price for discovery, each implementation milestone and the complete project; 22. Approved change-request rate; 23. Third-party costs and VAT or other applicable taxes; 24. Post-launch defect warranty, support and maintenance terms; 25. Major assumptions, exclusions, dependencies and risks; 26. Confirmation that all source code, repositories, infrastructure accounts and paid deliverables will remain under client ownership; 27. Verifiable references for the most relevant claimed production work, where available. Please do not disclose confidential information or source code belonging to previous clients. ## SELECTION PROCESS Shortlisted candidates may be asked to complete: 1. Written clarification of experience, proposed contributors, architecture, assumptions and commercial terms; 2. Verification of relevant references, production work or claimed contributions; 3. A focused 30–45-minute technical discussion attended by the exact proposed Technical Lead and, where relevant, the principal implementation engineer; 4. Written confirmation of material conclusions, commitments and changes discussed during the call; 5. A separately contracted paid discovery milestone of approximately 5–10 working days. The technical discussion will supplement—not replace—the requested written answers. An agenda or principal questions will be supplied in advance wherever practical. Important decisions or commitments made during a discussion must be confirmed in writing before they are treated as agreed. The proprietary workbook, calculation engine, coefficients, private repositories and detailed reference materials will not be disclosed during the initial application stage. Please begin your proposal with the words: **KINSTALL PRODUCTION V1** This confirms that you have read the complete description and reviewed the requirements for both the immediate commercial V1 and its durable architectural foundations. Generic proposals, undisclosed outsourcing, anonymous team allocation, unverified claims and portfolios without a clear explanation of personal contribution will not be shortlisted.