Expert Full-Stack Engineer Needed to Build High-Performance Construction Takeoff Module

Expert Full-Stack Engineer Needed to Build High-Performance Construction Takeoff Module * We are building Structum AI, a construction management and estimating SaaS platform. We need an expert engineer or small team to build a high-performance construction takeoff module inside our existing platform. * This is not a basic PDF viewer. The goal is to build a takeoff experience that feels close to a desktop tool like PlanSwift, with fast sheet loading, smooth pan and zoom, instant measurements, live quantity updates, and no lag on large plan sets. * Payout schedule $6500 $1500 Milestone 1 - Proof of quality deliver with shown functionality $3000 Milestone 2 - Functional and connected to main platform $2000 Milestone 3 - Polished and ready for use * We need someone who can build a real drawing and measurement engine, not just embed a web PDF viewer. * WHAT WE NEED BUILT * The module needs to allow users to upload construction plan PDFs, split PDFs into individual drawing sheets, detect sheet numbers and sheet names, organize plan sets, perform fast measurements, assign CSI codes, manage revisions and addendums, and export takeoff quantities into the rest of our Structum platform. * Plans should be able to enter the module from existing Structum document connectors or from manual user upload inside the takeoff module. * Manual upload should support single PDFs, multiple PDFs, addendum PDFs, revised plan sets, drag and drop, upload progress, and background processing. * PDF PROCESSING REQUIREMENTS * When a PDF plan set is uploaded, the backend should process it into a takeoff-ready format. * Each PDF should be split into sheets and should extract or generate sheet number, sheet name, discipline, drawing title, page size, rotation, scale if detectable, title block data, OCR text, vector text when available, thumbnail, high-resolution rendered image, zoom tiles, sheet hash for revision comparison, and drawing geometry hash if possible. * The viewer should not depend on rendering the full PDF live every time. That will be too slow. * The preferred approach is to store the original PDF, render each sheet to an image, generate thumbnails, generate zoom tiles, store sheet metadata, store OCR and layout data, store revision fingerprints, and have the viewer load cached tiles instead of loading the full PDF every time. * PERFORMANCE IS CRITICAL * This is one of the most important parts of the project. * The module must feel fast and smooth, close to a desktop application. * Pan and zoom should feel instant. * Drawing measurements should not lag. * Measurement previews should update smoothly. * Sheet switching should be fast. * Tiles around the visible area should preload. * Large plan sets should not freeze the browser. * Autosave should happen in the background. * The canvas should not rerender the whole React page on every mouse movement. * The user should not have to wait for AI processing before viewing or working on sheets. * The preferred technical approach should use Canvas or WebGL for the drawing surface, a separate overlay layer for takeoff geometry, tile-based rendering for plan sheets, web workers for heavy geometry calculations, spatial indexing for hit testing measurements, IndexedDB or local cache for recently opened projects, server-side rendered sheet tiles stored in object storage, Redis or similar cache for sheet metadata and frequent queries, bulk save endpoints instead of saving every small mouse event, and requestAnimationFrame for pointer movement and drawing. * The module should avoid rendering thousands of measurements as DOM elements, loading the full PDF in the browser every time, updating React state on every mouse move, re-processing the same PDF every time a user opens it, or building this like a normal web PDF viewer. * TAKEOFF VIEWER UI * The UI should be clean, fast, and easy to use. * The left panel should include plan sets, sheets, revisions, addendums, sheet search, and discipline filters. * The center should include the high-performance drawing viewer, pan, zoom, select, measure, tile-based plan rendering, and measurement overlay. * The right panel should include takeoff items, CSI code, description, quantity, unit, color or layer, assembly, and sheet references. * The bottom panel should include quantity summary, export status, current scale, and current selected item. * REQUIRED TAKEOFF TOOLS * The module needs select, pan, linear measurement, area measurement, perimeter measurement, count tool, rectangle area, polygon area, calibration, scale assignment, duplicate measurement, move point, delete point, undo, redo, hide and show layers, quantity summary by CSI code, and export selected quantities. * Keyboard shortcuts should also be supported for select, pan, linear measurement, area measurement, count, cancel, delete, undo, redo, save, and zoom. * CSI CODING REQUIREMENT * Every takeoff item must be assigned to a valid 6-digit CSI code. * No takeoff quantity should be exportable unless it has a valid 6-digit CSI code. * Each takeoff item should store takeoff item ID, project ID, 6-digit CSI code, CSI title, internal trade, description, unit of measure, measurement type, waste factor, color or layer, and created by user. * The CSI picker should support search by code, search by name, search by trade, AI-suggested CSI codes based on item name and project context, user confirmation before applying AI-suggested codes, and internal aliases so users can type common trade names like drywall and find the correct CSI code. * CSI code is required at the takeoff item level. All measurements under that item inherit the CSI code. * MEASUREMENT DATA MODEL * Measurements must be stored as vector geometry, not just final quantities. * Each measurement must remain traceable back to the project, plan set, sheet, sheet version, takeoff item, CSI code, user, geometry, quantity calculation, and scale used at the time of measurement. * The system must always keep the source geometry so quantities can be audited, edited, reviewed during revisions, and re-exported later. * VERSIONING, REVISIONS, AND ADDENDUMS * The takeoff module must organize drawings by plan set, sheet, and sheet version. * Plan sets may include Original Issue, Addendum 01, Addendum 02, Permit Set, Revision 01, IFC Set, or other project-specific plan packages. * When a new plan set or addendum is uploaded, the system should detect sheet numbers, match sheets to existing canonical sheets, compare the new sheet against the previous version, mark each sheet as new, changed, unchanged, deleted, or replaced, keep old measurements tied to the old sheet version, allow the user to carry forward measurements to the new version, mark carried-forward takeoffs as needs_review when the sheet has changed, and never silently overwrite old takeoff data. * Revision comparison should support side-by-side comparison, overlay comparison, highlighted changed areas, showing which takeoff items were created on the old version, and showing which carried-forward measurements need review. * QUANTITY EXPORT AND API INTEGRATION * The takeoff module needs API endpoints so the main Structum platform can pull or receive quantities. * Quantities should be exportable into the estimating module, scope ledger, procurement module, vendor bid packages, cost code system, material and spec ledger, and reports. * Exports should only include quantities that are active, on the selected or current sheet version, assigned to a valid 6-digit CSI code, not deleted, not unresolved, and not marked needs_review unless the user approves them. * REQUIRED API AREAS * The module should include endpoints for creating a takeoff plan set from an existing Structum document, manual PDF upload, listing plan sets by project, getting plan set metadata and sheets, starting or restarting plan processing, getting plan processing status, getting sheet metadata, loading sheet tiles, loading sheet thumbnails, setting or updating sheet scale, creating takeoff items, updating takeoff items, soft deleting takeoff items, creating measurements, bulk creating and updating measurements, getting all measurements on a sheet, updating measurements, soft deleting measurements, searching CSI codes, assigning CSI codes to items, listing revisions and addendums, comparing plan sets, getting sheet versions, carrying forward measurements, getting current takeoff quantities, exporting approved quantities, getting export status, and getting export rows. * EVENTS FOR PLATFORM INTEGRATION * The module should publish events so other Structum modules can react. * Events should include plan set uploaded, plan set processed, sheet version created, revision detected, takeoff item created, takeoff item updated, measurement created, measurement updated, quantities ready, and exported to estimate. * AI-ASSISTED FEATURES * AI can help, but the module should never depend on AI to function. * AI can assist with sheet number detection, sheet title detection, discipline detection, addendum classification, revision matching, CSI code suggestions, quantity grouping, scope ledger mapping, highlighting possible missed takeoff areas, and detecting drawing callouts and symbols. * AI suggestions should be treated as suggestions. User-confirmed takeoff data is the source of truth. * Manual takeoff must always remain fast and usable even if AI processing is still running. * REQUIRED EXPERIENCE * Please only apply if you have strong experience with high-performance web canvas or WebGL applications, PDF processing and rendering at scale, construction plan viewers or takeoff tools, geometry tools, measurement systems, CAD-like interfaces, React, TypeScript, backend API development, database design, S3 or object storage workflows, background processing, job queues, tile-based image rendering, large file handling, spatial indexing, hit testing, construction estimating, CSI codes, or plan revision workflows. * Experience building only normal CRUD dashboards is not enough for this project. * DELIVERABLES * We expect a working module with PDF upload and import flow, PDF processing into sheets, fast plan viewer, smooth pan and zoom, measurement tools, scale calibration, takeoff item creation, required CSI coding, live quantity updates, geometry-based measurement storage, revision and addendum handling, carry-forward measurement workflow, exportable quantity summaries, API endpoints for integration with the main Structum platform, clean production-ready code, and performance-tested UI that works on large plan sets. * * Build the core viewer approach, PDF processing strategy, tile rendering approach, and basic sheet viewer. * APPLICATION QUESTIONS * Have you built a high-performance PDF, CAD, map, canvas, or drawing viewer before? Please describe it. * How would you approach making pan, zoom, and measurements feel desktop-fast in a browser? * What frontend rendering approach would you use: Canvas, WebGL, SVG, DOM, or a hybrid? Why? * How would you process large construction PDF plan sets into sheets, thumbnails, and zoom tiles? * How would you store measurement geometry so it can be edited and audited later? * Have you worked with construction takeoff, estimating, CSI codes, or plan revisions before? * What risks do you see in this module, and how would you reduce them? * Please share relevant examples of similar work. * We are looking for an expert who can think through the product, performance, architecture, and construction workflow, not just someone who can add a PDF viewer to a page. * This can be a long-term role if the first module is successful.