A bill of quantities is the useful place to start
OpenConstructionERP documents a bill-of-quantities editor and quantity takeoff from drawings and building models. A bill of quantities connects measured work to prices, so keeping its source quantities accessible could save an estimator from repeatedly reconciling separate files. That's the adoption question I'd start with: can this application preserve the relationship between the source material and the amount you're preparing to quote?
The README describes a broader construction workspace, but a contractor doesn't need to evaluate every module to answer that question. Choose a completed job whose quantities and accepted estimate you can check. Recreate part of it, compare the result, and inspect how revisions affect the bill. That is a proposed trial. Our sandbox record contains no estimating session or accuracy measurement.
What happened when we ran it
Our run of OpenConstructionERP at commit 2d27b86 completed npm installation in 6 seconds on November 3, 2026. It recorded 2 dependencies and 14 MB on disk. Build and tests were skipped because no script or target was detected for either step. The result establishes that the recorded npm installation completed, without establishing that the application compiled, started, or processed a drawing.
The repository scan counted 15,516 files, approximately 3,944,116 source lines, and a 701.5 MB checkout. It found 25 CI workflow files and a Compose file, with no Dockerfile or tests directory detected. These observations don't prove that no checks exist elsewhere in the project. More importantly, the large checkout and small recorded npm dependency set are different measurements. Neither tells us the installed size of the Python or desktop application.
npm audit reported 0 known vulnerabilities, including 0 critical, high, moderate, and low findings. That applies to the recorded npm audit, not the Python backend, desktop download, container images, or every component named in the documentation. No audit coverage count or full-stack security assessment accompanies it. Treating that result as a blanket safety verdict would exceed what the run measured.
The measurement setup specified 3 CPUs, 8 GB RAM, and image lab-node:22. That image label does not establish the actual runtime or operating-system version. No building model, PDF drawing, or production database workload appears in the supplied record. There is no measured basis here for claims about conversion speed, quantity accuracy, or the reliability of estimates.
The documented app routes go beyond the npm check
The getting-started guide describes a Python package containing the FastAPI backend and a prebuilt React frontend. It says first run creates embedded PostgreSQL, loads demonstration data, and opens a local browser interface. The same guide offers desktop downloads and a Docker route. Our npm installation does not verify any of these application entry points, so choose one route before planning the evaluation environment.
For source development, the guide lists Python 3.12+, Node.js 22+, and PostgreSQL 16+. Its Docker instructions generate a database password and JWT secret. The default Python entry point binds to localhost, with a separate option for network access. Those details matter if a desktop trial becomes a team service: database persistence and access configuration need their own verification. We have not measured that transition.
Windows installers are unsigned; Intel Macs need another route
The README says there is no Intel macOS desktop build and directs those users to pip or Docker. The getting-started guide also says the Windows installer is not code signed yet. A company that requires approved signed installers may find the desktop route unsuitable regardless of the feature list. Confirm the available artifact against your team's actual machines before arranging an estimator's trial.
English documentation is available alongside a multilingual interface. That makes the project accessible to an international evaluation team, but language availability doesn't establish that your local rate data or contract conventions are appropriate. Use the completed job to check the inputs your estimator actually relies on, rather than accepting demonstration data as evidence for your market.
AI estimates still require professional verification
The README calls AI suggestions preliminary and requires a qualified construction-estimation professional to verify quantities, classifications, and costs before contractual or tender use. That limitation belongs near the adoption decision. Optional AI configuration needs a provider API key. Start the trial with a bill you can reconcile independently, then decide whether AI suggestions reduce useful work after corrections.
The repository API records a last push on November 4, 2026, and its issues feed shows November 1 updates, including estimating and planning feedback. Those facts establish current activity, not verified user outcomes. A published release cannot fill the missing application checks in this npm run.
ERPNext and Odoo address broader business operations
ERPNext's README documents accounting and order management. It also describes project tracking. Odoo's README lists CRM, warehouse management, and project management among its business apps. Evaluate either when general operations are your first requirement. Neither README establishes an equivalent drawing-to-quantity workflow in the scope we inspected, and we have no comparative deployment or performance measurements.
Documentation receives 4 on a scale where 1 means no usable entry instructions, 3 means a basic documented route, and 5 requires independently verified advanced workflows. Separate routes and explicit platform warnings justify that rating, while application maturity remains unassessed. The next useful result is a reconciled bill from a known project, produced through the deployment route your estimators will actually use.