Next.js Backend Developer — PostgreSQL, Prisma, Rules Engine and GHL Webhooks

Job Details

Description

Summary RGE ENGINE FACTORY v1 — BACKEND, DPA REFERENCE ENGINE, AUTHENTICATION AND GHL ADAPTER PROJECT OVERVIEW Referral Growth Engine (RGE) is being developed as a: Global Real Estate Intelligence + Routing + Opportunity Mapping Platform. We are hiring one accountable backend/full-stack technical integration lead to build the owned backend foundation for a controlled RGE beta. This is not a marketing website assignment. This is not a static prototype assignment. A separate frontend developer will build the owned subscriber application interface in Next.js using the API contracts, TypeScript types, authentication states and fictional fixtures produced through this backend assignment. The selected developer will personally own: - Backend architecture - PostgreSQL database design - Prisma schema and controlled migrations - Authentication - Role-based authorization - Next.js API routes - RGE Engine Factory v1 - DPA Reference Engine - GHL Adapter proof - Source freshness and confidence - Manual-review workflow - Audit logging - Automated testing - Backend-to-frontend integration - Final technical integration branch The selected developer must be able to personally review, explain and take responsibility for all delivered code, including AI-generated code. CURRENT ARCHITECTURE DIRECTION - Next.js App Router - TypeScript - Node.js - PostgreSQL - Prisma or an approved equivalent - Vercel - Private GitHub repository - Feature branches - Unmerged pull requests - GoHighLevel / GHL as a temporary public-form, CRM and communications bridge - Owned RGE backend and database as the long-term system of record - Separate frontend developer working in parallel - AI-first development with accountable human review - Fictional or separately approved static data during the proof stage - No live commercial-data API required for the initial proof PRIMARY OBJECTIVE Build RGE Engine Factory v1 and demonstrate one controlled end-to-end DPA workflow: Fictional GHL-style payload → GHL Adapter → Canonical RGE intake → Required-field and missing-field validation → DPA rules and scoring → Hard-stop processing → Source freshness and confidence → Manual-review state → Universal engine result → Audit history → API response for the owned frontend The Engine Factory must be reusable. Future RGE engines must be capable of using standardized definitions, shared services, common results and common audit controls rather than requiring a separate application to be built for every engine. TECHNICAL LEAD RESPONSIBILITY You will serve as the backend and technical integration lead. You must personally understand, implement, review and explain: - PostgreSQL database architecture - Prisma schemas and migrations - Next.js API routes - Authentication and session handling - Organization and user membership - Role-based access control - Protected API routes - Protected application routes - Webhook receipt and signature verification - Payload validation - Idempotency and duplicate-event prevention - Configurable rules-engine architecture - Manual-review state management - Source registry - Freshness and confidence processing - Audit logging - Automated tests - Vercel deployment - Secret-management boundaries - Frontend API integration - GitHub branch and pull-request controls Do not apply as a frontend-only developer. Do not apply if you require an undisclosed backend specialist, agency member or subcontractor. SCOPE 1 — CANONICAL RGE INTAKE CONTRACT Create a provider-neutral canonical intake structure containing: - Schema version - RGE intake ID - Source channel - External source-record ID - Mapping version - Submission timestamp - Consent status - Organization context - User context - Prospect or subject fields - Geography - Requested engine - Normalized input fields - Missing fields - Original-payload reference or hash - Intake status - Idempotency key - Created timestamp - Updated timestamp GHL-specific field names and GHL-specific IDs must stop inside the GHL Adapter. The core Engine Factory must not depend on GHL field names. The same canonical intake must be capable of receiving future submissions from: - GHL - A native RGE form - A partner portal - A QR intake source - An approved external API SCOPE 2 — ENGINE-DEFINITION CONTRACT Create a reusable, versioned engine-definition structure containing: - Engine ID - Engine name - Engine version - Engine status - Target audience - Supported geography - Required fields - Optional fields - Approved sources - Source priority - Source freshness requirements - Rules or scoring logic - Hard-stop rules - Missing-field behavior - Confidence behavior - Result states - Manual-review triggers - Next-best actions - Routing restrictions - Compliance language - Standard test cases The Engine Factory must load and execute an approved engine definition without requiring a new backend architecture for every future engine. SCOPE 3 — UNIVERSAL ENGINE-RESULT CONTRACT Create a common result structure containing: - Result ID - Intake ID - Organization ID - Engine ID - Engine version - Result status - Score or rule result - Confidence - Triggered flags - Missing information - Hard stops - Sources used - Source freshness - Source conflicts - Manual-review status - Reviewer action - Reviewer override - Next-best action - Routing recommendation - Created timestamp - Reviewed timestamp - Audit-history reference The frontend must receive approved result data through this common result contract. Do not place scoring, freshness, confidence or routing calculations inside frontend components. SCOPE 4 — POSTGRESQL AND PRISMA FOUNDATION Create the controlled data model for: - Organizations - Users - Roles - Organization memberships - Prospects or subjects - Intake records - External integration references - Engine definitions - Engine versions - Engine requests - Engine results - Source registry - Source-license records - Source records - Freshness states - Confidence records - Manual-review records - Reviewer actions - Routing recommendations - Audit events - Idempotency records Requirements: - Clear primary and foreign keys - Appropriate relationships - Appropriate unique constraints - Duplicate-event protection - Created and updated timestamps - Archival or soft-delete strategy where appropriate - Fictional seed data - Database tests - Migration notes - Rollback notes - No production migration without written Product Owner approval SCOPE 5 — AUTHENTICATION AND AUTHORIZATION Implement a controlled authentication and authorization baseline suitable for the RGE beta foundation. Include: - User login - Session handling - Organization membership - Role-based permissions - Protected API routes - Protected application routes - Unauthorized responses - Permission-denied responses - Audit events for sensitive actions Initial roles should include, at minimum: - Product Owner / Administrator - Organization Administrator - Reviewer - Subscriber / Partner User - Read-Only User Authorization must be enforced by the backend. Do not depend on frontend visibility rules as the security control. Do not hard-code permissions only inside frontend components. SCOPE 6 — RGE ENGINE FACTORY SHARED SERVICES Create reusable services for: - Intake normalization - Required-field validation - Missing-field detection - Engine registry - Engine-version resolution - Engine execution - Rules and scoring - Hard-stop evaluation - Source resolution - Source-license authorization status - Freshness evaluation - Confidence calculation - Source-conflict detection - Manual-review state management - Reviewer actions - Reviewer overrides - Next-best-action generation - Routing-recommendation generation - Audit-event creation - Universal-result formatting - Standard test execution The Engine Factory must not be designed as a one-off DPA-only backend. The shared services must be capable of supporting future RGE engines. SCOPE 7 — DPA REFERENCE ENGINE Use the Product Owner-approved DPA rules supplied after selection. The DPA Reference Engine must demonstrate: - Required-field validation - Missing-field behavior - Approved scoring weights - Approved thresholds - Hard-stop behavior - Source-priority behavior - Source-license status - Freshness behavior - Confidence penalties - Manual-review triggers - Funding-range caveat - Last-verified status - Reviewer override - Next-best action - Universal result - Complete audit history Use fictional or separately approved static DPA program records. Do not scrape or connect an unlicensed commercial DPA source. Do not represent a result as: - Guaranteed eligibility - Guaranteed funding - Underwriting - Loan approval - Legal advice - Financial advice - Automatic professional approval SCOPE 8 — GHL ADAPTER PROOF Build a replaceable GHL Adapter using fictional or sanitized test payloads. The Adapter must: - Receive a GHL-style webhook payload - Verify a test signature using the approved method - Validate the payload - Translate approved GHL fields into canonical RGE fields - Store external GHL identifiers separately - Preserve the mapping version - Prevent duplicate processing - Record mapping failures - Record processing failures - Return controlled status responses - Support approved status, tag or note synchronization later - Contain no DPA scoring logic - Contain no Engine Factory business logic - Contain no permanent system-of-record data - Remain replaceable by a native RGE form or another provider No live protected GHL account access is authorized during the initial proof work. A later live connection requires separate written approval. SCOPE 9 — SOURCE REGISTRY AND LICENSE CONTROLS Create a source-registry structure capable of tracking: - Source owner - Public or commercial status - License status - Permitted use - Commercial-use permission - Storage permission - Caching permission - Display permission - Derivative-analysis permission - Redistribution restrictions - Attribution requirements - Geography - Refresh cadence - Last verified - Expiration or renewal date - Legal-review status - Approved engines - Production-use authorization The system must be capable of suppressing or holding production execution when: - A required source is unapproved - A source license has expired - A source is stale beyond the approved window - The requested use exceeds permitted rights - Required consent is missing - Legal or compliance review remains unresolved The initial proof must use fictional or separately approved static source records. SCOPE 10 — BACKEND API Create documented APIs for the frontend developer, including: - Authentication state - Current user - Current organization - Organization membership - Role and permission state - Intake creation - Intake retrieval - Record retrieval - Engine execution - Engine-result retrieval - Manual-review queue - Manual-review record - Reviewer action - Source information - Source-license status - Freshness information - Confidence information - Audit history Provide: - Shared TypeScript types - Request schemas - Response schemas - Validation rules - Error-response structures - Permission requirements - Fictional mock responses - API endpoint documentation The frontend developer must be capable of building against these contracts before every backend service is complete. SCOPE 11 — FRONTEND DEVELOPER COORDINATION A separate frontend developer will work in parallel. You will serve as the technical integration lead. You must provide the frontend developer with: - Shared TypeScript contracts - Fictional mock JSON responses - API endpoint list - Authentication-state definitions - Role and permission definitions - Loading-state expectations - Error-response structures - Engine-result fixtures - Manual-review fixtures - Source and confidence fixtures - Audit-history fixtures You must review requested contract changes from the frontend developer. Do not require the frontend developer to place backend logic inside frontend components. You will be responsible for connecting the acce

Skills

Notification History

User Actions