Why I'm Building a BIM Portal
A build-in-public series on creating a lightweight BIM operations portal — the architecture, the friction, and the patterns that work.
Most BIM teams do not struggle with modeling.
They struggle with everything around it — the operational work that keeps projects moving but rarely gets the same attention as the model itself.
Project setup. Role assignments. Team onboarding. Execution plans. Model health checks. Sustainability documentation. These are the small coordination tasks that repeat on every project and compound across many. Nothing is broken, but the friction between people, process, and platforms adds up quietly until it becomes the bottleneck.
I recently recorded a short update on the first phase of building this portal:
The patterns I kept seeing
Across different firms, different projects, and different teams, the same issues surfaced:
- Setup steps scattered across checklists, email threads, and chat messages
- Inconsistent onboarding — every project manager does it slightly differently
- Duplicated effort when assembling "standard" documentation that is never quite standard
- Model health checks that happen too late, or not at all
The bottleneck is not Revit. It is the repeatable operational work that surrounds it.
A personal layer to this
I have spent years working deeply with the Revit API. I understand what is possible inside the model — and I have also experienced firsthand the difficulty of building cloud-connected tools on top of Autodesk Platform Services (formerly Forge).
Even in the early days, when we prototyped APS solutions alongside Autodesk engineers at a San Francisco hackathon, it was clear: the platform is powerful, but it is not push-button.
Today, with AI-assisted development, building is more accessible than it has ever been. Rapid iteration. Code generation. Intelligent scaffolding. But it is still not one-click magic.
In the same way many non-technical stakeholders believe Revit simply "makes the model and drawings," some now assume AI can simply "generate the system." It cannot. AI-assisted development and APS integration are still complex — they are simply more manageable now.
Part of this series is documenting what that actually looks like: the friction, the architecture, the decisions, and the patterns that hold up under real project conditions.
What I'm building
I am building a BIM Portal — a lightweight operations layer that turns recurring BIM delivery tasks into reliable, repeatable workflows.
Think of it as the connective tissue between your cloud platform, your models, and the people doing the work:
- Project setup — structured onboarding with status tracking
- Teams and roles — clear assignments, not assumptions
- Execution plans — BEP structure with controlled, versioned updates
- Model indexing — health signals surfaced early, not discovered late
- Sustainability review — document workflows in a safe, non-project-specific way
- AI assistant — summaries, checks, and guided next actions
The diagram above shows the high-level architecture. The BIM Portal sits at the center as an operations layer — pulling from integrations like APS/ACC, authentication, and AI on one side, and driving structured workflows for project setup, execution plans, and model health on the other. Everything flows down to canonical state: stored, versioned, and reviewable.
This is not a product announcement. It is a build log. The portal is a good example of the kind of software many BIM teams need but struggle to build — not because the concept is complex, but because it requires discipline in architecture, state management, and integration.
One principle that drives the build
Everything should have a canonical state.
No transient AI output that disappears after the session ends. No temporary edits that drift from the source of truth. No invisible queues that exist only in someone's head.
If it matters, it should be stored, versioned, and reviewable. This is the foundation the entire system is built on.
What's next
I will break this build into short posts — each one a focused, four-to-five minute read:
- The system map — frontend, backend, storage, and authentication
- The state pattern — baseline + overrides + merged state
- External systems — handling eventual consistency with APS and ACC
- AI in BIM ops — what it is good for, and where it falls short
- Deployment — lessons, guardrails, and what I would do differently
Building in public, without exposing what should remain private. AEC needs more builders who understand both delivery and software. If you are one of them, let's build better systems.