What they were
The five tools helped a team think through a first plan for BIM work: how large a team might need to be, a budget scenario, the effort in producing drawing documentation, a pilot and rollout for a four dimensional planning approach, and a readiness check for a shared data environment. Each answered one question and nothing more.
They were free and needed no account. What a visitor typed stayed in their own browser and was never sent to a server.
How the know-how became a tool
- 1Start with one decision. Each tool was built around a single decision a project team has to make early, not around a list of features.
- 2Ask only what people can answer. The questions were ones a team could answer on day one, with a way to say “not sure” instead of guessing.
- 3Show the assumptions. The reasoning behind a result stayed visible, so a reader could disagree with it and change it.
- 4Say what it cannot do. Every result carried its limits next to it. The tools were for early guidance, not for relying on in place of professional judgement.
Why I stopped
I retired the tools to focus this site on the work I now do: helping firms and vendors take construction AI from pilot to product. I have no usage figures or results to claim for the tools, and I do not make any here.
What it shows
The same discipline applies to AI tools in construction. A tool is not a product until it has a named owner, real users, one metric the business already tracks, a defined level of autonomy and a rollout plan that survives the second project. Getting a tool to be understandable and honest about its limits is the first part. Getting it adopted is the rest.
Turn your know-how into a tool See how I help with the rest →