Project Overview I am looking for a full-stack developer to fix and finalize the “Demo Mode” of an existing MVP codebase. The project is a construction management platform called BillMilli. It allows owners to validate 3D design updates, track construction readiness, and manage site capture requirements. Current Status:I have the full source code (developed over 2 months), but I am unable to get the full stack running locally to demonstrate it. The code includes a FastAPI backend, a React frontend, and an Expo mobile app. The Goal:Your primary job is to take the existing repository, debug the configuration/connection issues, and deliver a fully functional local demo. The project will be considered complete only when the system works as described below. Scope of Work & Capabilities (The “Working Demo”) I need the following features (which are already in the codebase) to function seamlessly in a local Docker/Dev environment: 1. Backend (FastAPI & Python) • Auth System: User login/signup must issue valid JWT tokens. • Project Lifecycle: Ability to create new projects and generate default construction stages/checklists. • File Ingestion Pipeline: The system must accept uploaded 3D models (IFC/GLB/DWG), store them in MinIO (S3-compatible storage), and process them for metadata. 2. Frontend Dashboard (React + Vite + TypeScript) • Dashboard Visualization: The React dashboard must connect to the API and display project KPIs, stage health, and progress. • Interactive 3D Workspace: The integrated Three.js viewer must correctly load and render the uploaded 3D models so users can explore building shells interactively. 3. Mobile Capture App (React Native / Expo) • Field Companion: The mobile app must connect to the local backend. • Capture Flow: Ability to start a “capture session,” view checklists, and upload site photos. (AR alignment features are present in the code and should be verifiable). 4. Infrastructure (Docker/MinIO) • The entire stack (Postgres, MinIO, API, Frontend) must spin up using docker compose up or a similar single-command setup without crashing or networking errors. Tech Stack • Backend: Python, FastAPI, SQLAlchemy, Alembic. • Storage: MinIO (S3 compatible), PostgreSQL (Database). • Frontend: React 18, TypeScript, Vite, React Query, Three.js (for 3D). • Mobile: React Native, Expo. • DevOps: Docker Compose. Payment Terms (Strict) • Milestone 1 (100%): Payment is released ONLY upon the delivery of a working demo. • You must provide a screen recording of the system running on your machine and a guide/fix for me to run it on mine. • If the demo does not work or the 3D models fail to load, the project is not complete. To Apply Please confirm you have experience with FastAPI, Three.js, and Docker Compose. If you can fix broken environment configurations and debug full-stack connections quickly, this is the job for you. I have attached the full project. This is how you will be charged: This checklist breaks down the system into its 5 core “Product Pillars.” Use this to verify if the developer has actually delivered a working system or just a UI shell. 1. Project & Stage Lifecycle (The “Backbone”) The Logic:When a project is created (POST /projects), the backend doesn’t just add a row to the DB. The StageManager service (backend/app/services/stage_manager.py) must automatically generate a template of construction stages (e.g., “Foundation,” “First Fix”) and default checklists. Requirement for Success: 1. Auto-Generation: Creating a project must result in ~5-10 “ConstructionStage” records appearing in the database automatically. 2. State Transitions: You cannot start “Stage 2” if “Stage 1” is not APPROVED. The backend enforces this logic. ✅ Verification Checklist: • Create Project: Create a new project “Villa 101” on the dashboard. • Auto-Stages: Click into the project → “Stages” tab. Are “Foundation”, “Structure”, etc., already listed? • Stage Gating: Try to click “Start Stage” on the 3rd stage immediately. It should fail or be disabled until previous stages are done. 2. Mobile Field Capture (The “Eyes”) The Logic:The mobile app (mobile/src/screens/CameraScreen.tsx) uses the camera to take site photos. Crucially, it bundles metadata (GPS, Compass Heading, and AR Pose) into the upload payload. The backend (complete_routes.py) stores the image in MinIO and the metadata in Postgres. Requirement for Success: 1. Network Tunneling: The phone must reach the Docker container (requires Ngrok/Expo Tunnel). 2. Metadata Persistence: When viewing the photo on the Web Dashboard, you must be able to see “Captured at: [GPS Coordinates]” or similar metadata. 3. Offline Queue: (Bonus) If the phone is offline, does it queue the upload? (The code hints at Redux state management for this). ✅ Verification Checklist: • Connection: Open the app on a physical phone (not simulator) and log in. • Capture: Take a photo in a “Capture Session.” • Sync: Refresh the Web Dashboard. Does the photo appear under the correct Project & Stage? • Data Check: Click the photo details on the web. Is the file size > 0 and is there a timestamp? 3. Thermal Analysis Engine (The “Brain”) The Logic:This is a sophisticated background worker (backend/app/services/thermal_analysis.py). It takes the 3D model geometry (walls/windows), combines it with climate data (e.g., “Al Falah” weather data), and calculates cooling loads (AC tonnage). Requirement for Success: 1. Geometry Parsing: The analysis will fail if the 3D model doesn’t have “Rooms” or “Zones” defined. 2. Climate Data: The system must fetch or have cached weather data for the selected location. 3. Output Storage: The result is a JSON blob stored in project.metadata['thermal_analysis']. ✅ Verification Checklist: • Run Analysis: On the web dashboard, go to “Thermal Analysis” → Select “Al Falah” → Click “Run”. • No Crash: This computation is heavy. Ensure the backend doesn’t timeout (500 error). • Results: Do you see numbers change? (e.g., “Total Cooling Load: 45.2 kW”). If it says “0 kW”, the geometry parsing failed. • Heatmap: Toggle “Show Heatmap.” Does the 3D viewer colorize the rooms (Red = Hot, Blue = Cool)? 4. Deviation Detection (The “Quality Control”) The Logic:Located in backend/app/services/deviation_detector.py. This compares the Actual Position (from the anchored photo) vs. the Expected Position (from the uploaded BIM/CAD model). Requirement for Success: 1. Anchoring: You must manually or automatically “pin” a photo to a 3D element (e.g., “This photo is of Wall A”). 2. Tolerance Rules: The system checks a dictionary of rules (e.g., wall_position: 2.0cm). 3. Event Creation: If the distance > tolerance, a DeviationEvent row must be created in the DB. ✅ Verification Checklist: • Simulate Deviation: In the backend/database, manually tweak a wall’s position in the 3D model data. • Anchor Photo: Upload a photo and “Anchor” it to that wall (simulating the wall was built in the wrong spot). • Trigger: Check the “Deviation Management” page (frontend/src/pages/DeviationManagement.tsx). Did a new “Detected” item appear? • Workflow: Click “Reject” on the deviation. Does the status change to Red? 5. Payment Gates & DLP (The “Wallet”) The Logic:The enhanced_routes.py contains logic to block payments. It checks: can_release_payment. This returns False if there are open “Critical” deviations or if the stage is not 100% complete. Requirement for Success: 1. Blocking Logic: A payment request should be strictly blocked by the backend if criteria aren’t met. 2. DLP (Defects): Creating a “Defect Ticket” (DLPTicket) should be linked to a specific Room or Element ID. ✅ Verification Checklist: • Gate Test: Try to “Approve Payment” for a stage that is still “In Progress.” It should return a specific error message (e.g., “Blocking reasons: Stage not complete”). • Defect Logging: Create a DLP Ticket: “Cracked Tile in Kitchen.” • Traceability: Go to the “Kitchen” room in the dashboard. Do you see the ticket listed there? Summary for the Developer “I will be testing the delivery against these 5 flows. Please ensure the Happy Path for each of these features works without crashing before handing over the code.”