Speckle in AEC — when to use, when not

1. The Decision That Started This

The conversation happens more often now. A project owner sits across from the BIM Manager and says something like: "We want a live dashboard. We want to see how many rooms are compliant with the area brief right now, not next week when the coordinator exports the schedule to Excel. We want to see it in a browser. We want to share it with the client's operations team without buying them Revit licenses."

The BIM Manager knows IFC. She's been running IFC workflows for a decade. She knows how to lock GUIDs, configure property sets, validate against Solibri, and deliver clean COBie at handover. But she also knows what IFC is not designed for: real-time web queries, live model-linked dashboards, or sub-second object traversal by a JavaScript application. IFC is a serialisation format. By design, it serialises a snapshot and hands it off. Querying it live means parsing a flat STEP-encoded text file, which is not what STEP was designed for.

The alternative she keeps hearing about is Speckle. A colleague at a competing firm used it to pipe Grasshopper geometry into a Power BI dashboard for a hospitality developer who wanted to track net-to-gross ratios across 400 rooms as the design evolved. Another firm used it to give a contractor read-only access to a federated model in a browser without any desktop software. A third used it to run automated clash detection every time a Revit model was published, with results posted to a Teams channel within minutes.

None of those workflows are impossible with IFC. All of them are significantly harder.

But IFC workflows are also not replaceable across the board. The same BIM Manager knows that her public sector client's contract requires IFC submission at each RIBA stage. The structural steelwork package goes to a fabricator whose CNC toolchain reads SteelFab XML — and the connection into Speckle for that workflow does not exist. The infrastructure drainage model is being delivered in IFC 4.3 format because Transport for NSW's digital engineering framework mandates it. And when this project is complete, the FM team needs a COBie-compliant handover package that their CAFM platform can ingest directly.

So the question is not "Speckle or IFC?" The question is "which job, which tool?"

This article is an attempt to answer that systematically, from the perspective of practitioners who have used both. It covers what Speckle actually is under the hood, where it is genuinely better than IFC-based workflows, where IFC is non-negotiable, and the failure modes that appear when either tool is pushed beyond its appropriate domain.

2. What Speckle Actually Is

2.1 Origin and Context

Speckle began as a PhD research project at The Bartlett School of Architecture, University College London, under Dimitrie Stefanescu, who holds a doctorate in Digital Design Communication from UCL. The earliest public GitHub activity on the Speckle project dates to around 2017–2018, when Stefanescu and co-founder Matteo Cominetti — both with backgrounds in computational design at firms including Arup and Buro Happold — were scratching a very specific itch: how do you get AEC geometry and metadata out of proprietary application silos without writing a bespoke exporter for each one, and how do you make that data queryable on the web without a file round-trip?

The project gained traction within the AEC computational design community — practitioners who use Grasshopper, Dynamo, and custom scripting as part of their daily workflow — before attracting venture backing. In April 2022, Speckle raised a seed round led by Foundamental and Cocoa. In December 2024, the company raised $12.5 million in Series A funding with participation from Frontline Ventures and Matrix Partners, with angel investors including co-founders of Sentry, Built Technologies, and PlanGrid.

The company is now backed by a team with deep AEC computational backgrounds, and describes itself as building "the first AEC data hub that connects with your favorite AEC tools."

2.2 The Architecture Stack

Understanding what Speckle is requires understanding what it is not. It is not a file format. It is not an API wrapper around IFC. It is a versioned object graph storage system with a network of connectors and a query layer.

The architecture has four main layers:

Kits (Schema Layer)

Speckle Kits define a "common language" — a schema — and include translation routines between an application's native object model and that schema. As the legacy architecture documentation explains, kits are "hot-swappable," meaning you can substitute a different schema definition without replacing the transport or storage infrastructure. In practice, the default kit (SpeckleObjects) defines types for geometry primitives (Point, Line, Mesh, Brep), BIM elements (Wall, Floor, Beam, Column), and parameter containers. The design principle here is "composability and extensibility, and not around completeness" — a deliberate contrast with IFC, which attempts to enumerate and formally type every building element.

The Base Object (Data Model Layer)

Every object in Speckle inherits from a Base class. The Base object has a handful of mandatory fields — id, speckle_type, applicationId — and accepts arbitrary dynamic properties. When an object is serialised, its id is computed as a hash of its content. This makes all Speckle objects immutable by reference: if an object changes, its hash changes, and it is stored as a new object. Unchanged objects reuse their existing hash.

This hash-based deduplication is architecturally significant. In a model with 5,000 walls, if 200 walls change between two commits, Speckle stores only 200 new objects. The other 4,800 are referenced by hash and not retransmitted. This is what makes the diff feature efficient: comparing two commits is comparing two sets of object hashes.

The Base object also supports detached properties — prefixing a property name with @ causes the referenced sub-object to be stored separately and referenced by hash, rather than embedded. This prevents duplication when the same mesh geometry is referenced by multiple BIM elements.

The Server (Transport and Storage Layer)

The Speckle Server is a Node.js monorepo with these main packages:

packages/server — the Node.js backend (GraphQL API, authentication, webhooks)
packages/frontend-2 — the Nuxt/Vue web frontend
packages/viewer — a Three.js extension for 3D rendering
packages/objectloader — JavaScript utility for streaming objects from the API
packages/preview-service — headless preview generation
packages/webhook-service — external event delivery
packages/fileimport-service — file parsing and import

The persistence stack uses PostgreSQL (for project metadata, commits, and object references), an S3-compatible object store (MinIO in self-hosted deployments, or cloud blob storage), and Redis/Valkey for sessions and caching.

The primary interface to this server is a GraphQL API, available at {server_url}/graphql. A REST API exists for legacy compatibility and bulk object upload/download. Every project, model (formerly called "stream"), version (formerly "commit"), and object is addressable through GraphQL.

Connectors (Application Integration Layer)

Connectors are lightweight plugins that sit inside authoring applications. The current connector roster covers:

Autodesk Revit (2022+)
McNeel Rhino (7+) and Grasshopper
Autodesk AutoCAD (2021+) and Civil 3D (2021–2025)
Blender (3.x+)
Trimble Tekla Structures (2024)
Graphisoft ArchiCAD (25, 26, 27)
Autodesk Navisworks
SketchUp
Bentley MicroStation and OpenRoads Designer (via community connectors)
ETABS (via community connector)
Power BI (via dedicated data connector)
Excel (via community connector)

The connector's job is translation: it maps the application's native object model to Speckle's schema, serialises the result, and sends it to the server via a transport. The same architecture in reverse handles receiving data.

2.3 Data Flow

The data flow for a typical operation — say, a Revit model being published and received in Grasshopper — looks like this:

Connector reads native objects
The Revit connector iterates over elements in the Revit model — walls, floors, structural framing, MEP systems — and calls kit converters to translate each into Speckle Base objects. Geometry is converted to Speckle's Brep or Mesh types. Parameters are carried as dynamic properties on each object.
Serialisation and hashing
Each object is JSON-serialised and hashed. Objects that already exist on the server (same hash) are skipped during upload. Large geometry arrays are automatically "chunked" into separately stored sub-objects.
Transport to server
The SDK uploads changed objects to the server via REST (batch upload). It then creates a new version (commit) via the GraphQL API, pointing to the root object hash and tagged with metadata: sender, source application, timestamp, and message.
Notification
The server broadcasts a real-time notification via WebSocket subscriptions to all connected clients watching this project/model. Automations configured on the model trigger.
Receive in target application
The Grasshopper connector queries the GraphQL API for the latest version, receives the root object hash, and uses the objectloader to stream child objects on demand. Objects are converted from Speckle types back to Rhino geometry and data trees.

2.4 JavaScript-First Ecosystem

One of Speckle's distinguishing characteristics is that its web layer is a first-class product, not an afterthought. The viewer (@speckle/viewer) is an npm package built on Three.js. The objectloader (@speckle/objectloader) is an npm package for streaming objects from the server. Both are published to the public npm registry and can be embedded in any web application.

This is not how IFC was designed. IFC parsers for the web exist (IFC.js, web-ifc), but they operate on flat files. Speckle's web SDK operates against a live API with object-level granularity. The practical implication: building a custom web dashboard that queries live model data, filters by parameter value, and renders a 3D view of filtered results is a tractable frontend engineering task with Speckle. With IFC, it requires either a file upload workflow or a backend IFC parsing service.

2.5 Apache 2.0 and Self-Hosting

The Apache 2.0 license matters operationally. Organisations that cannot send model data to third-party cloud infrastructure — defence contractors, government clients, projects in jurisdictions with strict data residency requirements — can run Speckle entirely on their own network. Speckle Cloud offers nine regional data centers (UK, US, Canada, Netherlands, Germany, Singapore, India, Australia, and others) for organisations that need geographic data residency without managing their own infrastructure. Self-hosting remains an option for those who need it.

The self-hosted deployment runs as a Docker Compose stack. The minimal configuration requires four environment variables to be set and takes under an hour to deploy on a Linux VM with 4 GB RAM.

# docker-compose.yml — Minimal self-hosted Speckle Server
# Based on official Speckle deployment guide:
# https://speckle.guide/server/server-manualsetup
 
version: "3.9"
 
services:
  postgres:
    image: postgres:16.9-alpine
    environment:
      POSTGRES_DB: speckle
      POSTGRES_USER: speckle
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    restart: unless-stopped
 
  redis:
    image: valkey/valkey:8-alpine
    volumes:
      - redis-data:/data
    restart: unless-stopped
 
  minio:
    image: minio/minio
    command: server /data
    environment:
      MINIO_ROOT_USER: ${MINIO_ACCESS_KEY}
      MINIO_ROOT_PASSWORD: ${MINIO_SECRET_KEY}
    volumes:
      - minio-data:/data
    restart: unless-stopped
 
  speckle-server:
    image: speckle/speckle-server:latest
    environment:
      CANONICAL_URL: ${CANONICAL_URL}         # e.g. https://speckle.yourfirm.com
      SESSION_SECRET: ${SESSION_SECRET}        # long random string
      POSTGRES_URL: postgres://speckle:${POSTGRES_PASSWORD}@postgres/speckle
      REDIS_URL: redis://redis
      S3_ENDPOINT: http://minio:9000
      S3_ACCESS_KEY: ${MINIO_ACCESS_KEY}
      S3_SECRET_KEY: ${MINIO_SECRET_KEY}
      S3_BUCKET_NAME: speckle-objects
      FILE_SIZE_LIMIT_MB: 100
    depends_on: [postgres, redis, minio]
    restart: unless-stopped
 
  speckle-frontend-2:
    image: speckle/speckle-frontend-2:latest
    environment:
      NUXT_PUBLIC_API_ORIGIN: ${CANONICAL_URL}
      NUXT_PUBLIC_BASE_URL: ${CANONICAL_URL}
    depends_on: [speckle-server]
    restart: unless-stopped
 
  speckle-ingress:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    depends_on: [speckle-frontend-2, speckle-server]
    restart: unless-stopped
 
volumes:
  postgres-data:
  redis-data:
  minio-data:

3. Speckle's Strengths In Depth

3.1 The Web Viewer: Real Access Without Licenses

Speckle's @speckle/viewer package is a Three.js extension built for AEC-scale geometry. It supports:

Automatic object batching and BVH (Bounding Volume Hierarchy) acceleration for large model performance
Instanced rendering for repeated objects (structural grids, mullions)
Progressive ambient occlusion and shadowcatching for design-quality rendering
Section planes, measurement tools, and element filtering
In-context commenting and markup
An extension system for custom functionality

The viewer can be embedded in any web application and pointed at a project URL. The only requirement is a Speckle server and a valid access token. A contractor reviewing a structural model in a browser, a developer client checking room counts on a tablet on site, an FM team cross-referencing asset data during handover preparation — all of these work without desktop software.

The August 2025 viewer redesign consolidated tools into a more accessible bottom toolbar, with dedicated panels for models, filters, section tools, and camera controls. The measure tool was specifically optimised for mobile and tablet use, supporting on-site workflows via shareable model links.

To embed the viewer in a custom application:

// TypeScript — Embedding the Speckle viewer in a custom dashboard
// Package: @speckle/viewer (from npm)
// Docs: https://docs.speckle.systems/developers/viewer/overview
 
import {
  Viewer,
  DefaultViewerParams,
  SpeckleLoader,
  UrlHelper
} from '@speckle/viewer'
 
async function initSpeckleViewer(
  containerEl: HTMLElement,
  projectUrl: string,  // e.g. https://app.speckle.systems/projects/abc123/models/def456
  authToken: string
): Promise<Viewer> {
  const params = DefaultViewerParams
  params.showStats = false
  params.verbose = false
 
  const viewer = new Viewer(containerEl, params)
  await viewer.init()
 
  // Resolve the project URL to resource identifiers
  const urls = await UrlHelper.resourcesFromURL(projectUrl)
 
  for (const url of urls) {
    const loader = new SpeckleLoader(viewer.getWorldTree(), url, authToken)
    await viewer.loadObject(loader, true)
  }
 
  return viewer
}
 
// Usage
const container = document.getElementById('viewer-container')!
const viewer = await initSpeckleViewer(
  container,
  'https://app.speckle.systems/projects/abc123/models/def456',
  process.env.SPECKLE_TOKEN!
)

3.2 The Git-Like Versioning Model

Speckle's versioning model is the closest thing AEC has had to source control for 3D models. The terminology has evolved: what was previously called "streams," "branches," and "commits" is now called "projects," "models," and "versions" in the current product UI, but the conceptual architecture is identical.

A project is the top-level container — analogous to a git repository. A model is a named branch within that project — you might have models for architecture/levels, structure/framing, mep/hvac, and coordination/federated. Each model maintains an independent version history.

A version is an immutable snapshot — a commit. It records the root object hash, the sender's identity, the source application, a timestamp, and a human-readable message. Versions cannot be modified after creation. If you need to roll back, you receive an older version; the newer one is not deleted.

This model has several practical implications that file-based workflows cannot match:

Parallel design options are first-class: create a new model for option-a/facade and option-b/facade, develop each independently, compare them in the viewer.
Change attribution is automatic: every version knows who sent it and from which application.
Cross-discipline dependency is explicit: the structural coordinator can point their Grasshopper analysis at the architecture/levels model and always receive the latest version automatically.
Rollback is safe: since all versions are immutable and retained, reverting to a prior state does not destroy history.

3.3 Model Diff and Change Detection

Because every Speckle object has a content hash, comparing two versions is mathematically precise. The Compare Versions feature in the viewer surfaces this as a visual tool: elements that were added, removed, or modified between any two versions are colour-coded in the 3D view. No file comparison required, no manual changelog.

Under the hood, the diff is computed by comparing the set of object hashes between version A and version B. Objects in A but not B are deletions; objects in B but not A are additions; objects whose applicationId matches between versions but whose content hash differs are modifications. Because the hash is computed from the object's entire content — geometry and parameters — a parameter change on an otherwise unchanged wall will register as a modification. This is the behaviour you want for BIM quality assurance: a changed fire rating or a moved partition is caught, not silently accepted.

The diff is not just visual. Because the objects are queryable via GraphQL, you can write scripts that query the diff programmatically — pull all modified walls between version N and N-1, check their fire rating parameter against the specification, post failures to a QA tracker. This is the foundation of an Automate-based BIM QA pipeline.

This is a qualitatively different capability from what IFC workflows offer. IFC does not have a built-in diff mechanism. BCF (BIM Collaboration Format) provides issue tracking against a federated model, but BCF issues are manually created by reviewers. They do not automatically detect element-level changes. Tools like Solibri and Navisworks can compare IFC snapshots, but they require the analyst to initiate the comparison manually against two static files, and the comparison is only as current as the last manual export from the authoring tool.

Speckle's diff is always available, always current against the live model state, and requires no additional tooling beyond the Speckle server and connectors that are already in use.

3.4 Custom Dashboards and Business Intelligence

The Power BI integration and the GraphQL API together make Speckle the most practical path to live model-linked dashboards in AEC. The Power BI connector automatically extracts object properties into a tabular format that Power BI can work with natively — no custom ETL required. The Speckle Power BI visual renders the 3D model inside a Power BI report, with selection state linked to other report visuals.

Use cases that are in production at firms including Arup, Gensler, and China State Construction:

Net-to-gross ratio tracking per floor level, updated each time a new Revit version is published
Material volume aggregation for embodied carbon dashboards
Room compliance status (brief area vs. designed area) per zone
Structural element count and tonnage by frame type
Program distribution by use category and level

The underlying pattern: Speckle objects carry their native application parameters as properties. Those properties are queryable via GraphQL. They flow into Power BI or any other analytics tool. The model is the source of truth, and the dashboard reflects the current version without manual export.

# GraphQL query — Fetch all Revit walls with their fire rating parameter
# Server: https://app.speckle.systems/graphql
# Authentication: Bearer token in Authorization header
 
query GetWallFireRatings($projectId: String!, $objectId: String!) {
  project(id: $projectId) {
    object(id: $objectId) {
      children(
        select: [
          "id",
          "speckle_type",
          "parameters.FIRE_RATING.value",
          "parameters.CONSTRAINT_LEVEL.value",
          "area",
          "volume"
        ]
        query: [
          {
            field: "speckle_type"
            operator: "="
            value: "Objects.BuiltElements.Wall:Objects.BuiltElements.Revit.RevitWall"
          }
        ]
        limit: 1000
      ) {
        objects {
          data
        }
        totalCount
        cursor
      }
    }
  }
}

3.5 Computational Design Round-Trips

The Grasshopper and Dynamo connectors are Speckle's original killer feature, and they remain its strongest differentiator for computational design workflows.

The pattern: a Grasshopper script generates geometry based on parametric inputs. The script publishes to a Speckle model via the GH Send component. A Dynamo script in Revit subscribes to that model, receives the geometry, and drives Revit element placement. When the Grasshopper parameters change, a new version is published, Dynamo receives it, and Revit updates.

This round-trip is documented in peer-reviewed research — a 2022 study published in the Journal of Civil Engineering and Management demonstrated a Grasshopper-to-Speckle-to-Dynamo-to-Revit workflow for structural truss optimisation, where the optimal geometry generated in Rhino/Grasshopper was transferred into a Revit model via Speckle and a Dynamo translation script.

The Python SDK makes this scriptable outside of visual programming environments:

# Python — Sending geometry from a parametric analysis to Speckle
# Typical use case: Grasshopper/Dynamo automation, or standalone computation
# Package: specklepy (pip install specklepy)
# Docs: https://speckle.guide/dev/py-examples.html
 
from specklepy.api.client import SpeckleClient
from specklepy.api.credentials import get_default_account
from specklepy.objects.geometry import Point, Mesh
from specklepy.objects.base import Base
from specklepy.transports.server import ServerTransport
from specklepy.api import operations
from dataclasses import dataclass, field
from typing import List
 
# --- Authentication ---
client = SpeckleClient(host="app.speckle.systems")
account = get_default_account()
client.authenticate_with_account(account)
 
# --- Define a custom Speckle object for structural members ---
class StructuralMember(Base, speckle_type="Custom.Structural.Member"):
    """Custom Speckle object carrying geometry + analysis results."""
    member_id: str = None
    section_type: str = None
    utilisation_ratio: float = None
    displayValue: List[Mesh] = field(default_factory=list)  # Geometry for viewer
 
# --- Build objects from analysis results ---
def create_member_objects(analysis_results: list) -> Base:
    """Convert analysis output to Speckle object graph."""
    root = Base(speckle_type="Custom.Structural.AnalysisSet")
    members = []
 
    for result in analysis_results:
        member = StructuralMember(
            member_id=result["id"],
            section_type=result["section"],
            utilisation_ratio=result["utilisation"],
            displayValue=[result["mesh"]]  # Speckle viewer will render this
        )
        members.append(member)
 
    root["@members"] = members  # '@' prefix = detached storage (deduplication)
    root["totalCount"] = len(members)
    root["maxUtilisation"] = max(r["utilisation"] for r in analysis_results)
    return root
 
# --- Send to Speckle ---
PROJECT_ID = "your-project-id"
MODEL_ID = "structure/analysis"
 
transport = ServerTransport(client=client, stream_id=PROJECT_ID)
root_object = create_member_objects(my_analysis_results)
 
object_hash = operations.send(base=root_object, transports=[transport])
 
version_id = client.commit.create(
    stream_id=PROJECT_ID,
    object_id=object_hash,
    branch_name=MODEL_ID,
    message=f"Analysis run — max utilisation {root_object['maxUtilisation']:.2f}",
    source_application="Python/Analysis"
)
 
print(f"Published version: {version_id}")
print(f"Viewer: https://app.speckle.systems/projects/{PROJECT_ID}/models/{MODEL_ID}")

3.6 Speckle Automate

Speckle Automate is the CI/CD layer for model workflows. It operates on a simple trigger model: when a new version is published to a specified model, one or more Automate functions execute. Functions are Docker containers running Python or .NET code; they receive model metadata and a Speckle token, interact with the published model via the API, and return structured results (pass/fail status, annotated objects, messages) that appear in the Speckle UI alongside the triggering version.

Current capabilities include:

Quality assurance checks: verify that elements have required parameters, that parameter values fall within expected ranges, that BIM execution plan naming conventions are followed
Code compliance: run geometry and attribute checks against project-specific rules (minimum room areas, maximum structural spans, fire compartment integrity)
Clash detection: integrate with external clash detection services
Report generation: produce PDF or CSV outputs from model data
Notification routing: post to Slack, Teams, or email based on check results

The deployment model is function-as-a-service: you write the function code, push it to a GitHub repository, and Speckle Automate builds and runs it in a managed container. You do not manage the runtime infrastructure.

# Python — Speckle Automate function skeleton
# Template: https://github.com/specklesystems/speckle_automate_python_example
# Functions receive automation context; results are posted back to the Speckle UI
 
import sys
import json
from specklepy.api.client import SpeckleClient
from specklepy.api import operations
from specklepy.transports.server import ServerTransport
 
def run_automation(automation_context: dict, function_params: dict, token: str):
    """
    Main entry point for a Speckle Automate function.
 
    automation_context keys:
        projectId, modelId, versionId, speckleServerUrl,
        automationId, automationRunId, functionId
 
    function_params: user-configured JSON inputs defined in the
                     function's parameter schema
 
    token: Speckle personal access token for API calls
    """
    server_url = automation_context["speckleServerUrl"]
    project_id = automation_context["projectId"]
    version_id = automation_context["versionId"]
 
    # Connect to the Speckle server
    client = SpeckleClient(host=server_url)
    client.authenticate_with_token(token)
 
    # Get the version's root object hash
    version = client.commit.get(project_id, version_id)
    root_hash = version.referencedObject
 
    # Stream all objects from the version
    transport = ServerTransport(client=client, stream_id=project_id)
    root = operations.receive(obj_id=root_hash, remote_transport=transport)
 
    # --- Run your checks ---
    failures = []
    min_area = function_params.get("minimumRoomAreaM2", 9.0)
 
    for element in flatten(root):  # flatten() traverses the object graph
        if getattr(element, "speckle_type", "").endswith("Room"):
            area = getattr(element, "area", None)
            if area is not None and area < min_area:
                failures.append({
                    "objectId": element.id,
                    "message": f"Room '{element.get('name', 'unnamed')}' area "
                               f"{area:.1f} m² is below minimum {min_area} m²",
                    "level": "error"
                })
 
    # Return results — the Speckle Automate platform surfaces these in the UI
    result = {
        "status": "failed" if failures else "passed",
        "statusMessage": f"{len(failures)} rooms below minimum area" if failures
                         else "All rooms meet minimum area requirements",
        "results": failures
    }
 
    print(json.dumps(result))  # Automate reads stdout
    return result
 
if __name__ == "__main__":
    # Docker entrypoint: python main.py run <context_json> <params_json> <token>
    context = json.loads(sys.argv[2])
    params = json.loads(sys.argv[3])
    auth_token = sys.argv[4]
    run_automation(context, params, auth_token)

4. Where IFC Still Wins

This section is longer than the previous one. Not because IFC is a better technology in the abstract, but because the jobs where IFC is the right answer are more numerous, more deeply embedded in contractual and regulatory infrastructure, and more consequential when got wrong.

4.1 The Fundamental Distinction

IFC and Speckle solve different problems.

IFC is a formal interchange standard — a stable, versioned schema published under ISO 16739, with defined object types, property sets, and geometry representations. Its purpose is to enable data exchange between organisations that do not share a common toolchain, operating over timescales that may span decades. It is the lingua franca of openBIM: when a Norwegian public client specifies openBIM in a tender, when a Singaporean statutory authority requires a digital model for planning submission, when a UK local authority expects COBie at asset handover, they are specifying IFC.

Speckle is a collaborative data platform — a real-time, versioned object store with a connector ecosystem. Its purpose is to enable live data sharing within and between teams that have chosen to use it, over the active life of a project. It is the right tool when you control the toolchain and need velocity; it is the wrong tool when you cannot control what the receiver uses or when long-term schema stability is a requirement.

Speckle

Versioned object graph; schema defined by Speckle Kits; extensible with custom types; no formal standard body

IFC

ISO 16739-1:2024; formally typed schema; property sets defined by buildingSMART; schema stability across tool versions

4.2 Regulatory Submissions and Government Contracts

The buildingSMART 2025 IFC Mandate Report documents national IFC mandates across multiple jurisdictions. As of early 2025:

UK: BIM Level 2 compliance is mandatory for centrally procured government projects under the UK BIM Framework. ISO 19650-compliant workflows with IFC and COBie deliverables are expected on major public infrastructure.
Spain: Mandatory IFC use in public contracts, phased from 2024 to 2030.
Australia: Transport for NSW mandates IFC within its Digital Engineering Framework for all new road and rail infrastructure.
Scandinavia: Norway and Finland have had public sector openBIM requirements for several years, with IFC as the specified format.
Singapore: BCA (Building and Construction Authority) has required IFC-based submissions for electronic planning applications since 2016.

None of these mandates reference Speckle. None of them can be satisfied by Speckle alone. When a contract requires an IFC deliverable at RIBA Stage 3, you need to produce an IFC file, regardless of what internal tooling your team uses for real-time collaboration. The receiving authority's platform (Solibri, Revizto, a government digital gateway, a planning portal) expects IFC. They will not install a Speckle connector.

This is not a criticism of Speckle. It is a description of a deployment reality that will not change in the near term.

4.3 Handover Deliverables and COBie

COBie (Construction Operations Building Information Exchange) is a structured data schema for building handover. It specifies how equipment lists, product data sheets, warranties, spare parts information, and preventive maintenance schedules are captured and delivered to the building owner at practical completion. COBie can be delivered as a spreadsheet (for smaller projects), or in IFC STEP format or ifcXML for larger projects where machine-readable data is required by the FM platform.

COBie is explicitly aligned with IFC: it is a subset of the IFC model, based on the Facilities Handover Model View Definition. The data that COBie captures — type definitions, asset instances, job procedures, spare parts, warranties — maps directly to IFC entities. CAFM (Computer-Aided Facilities Management) platforms — Archibus, Planon, IBM Maximo, Bentley AssetWise — typically have IFC/COBie importers. They do not have Speckle importers.

The COBie handover is not just a format question. It is a process question. COBie data is accumulated progressively throughout the project: specifications populated at design, manufacturer data populated at procurement, installation records added during construction, commissioning results added at practical completion. Each of these stages requires discipline-specific tools that produce correctly mapped IFC property sets. The BIM Manager's job is to verify that property set coverage is maintained throughout the project lifecycle, not just at handover.

This process is entirely compatible with a parallel Speckle workflow — the Revit model that feeds COBie through the IFC exporter is the same model that can be publishing to Speckle for real-time collaboration. But the COBie chain depends on IFC configuration decisions (stable GUIDs, Pset_ManufacturerTypeInformation, Pset_MaintenanceJobType mapping) that must be made at project initiation and maintained through every model authoring cycle. These decisions are invisible to Speckle. If the IFC exporter is not correctly configured, the Speckle workflow will not tell you.

If your project involves a meaningful FM handover — any asset-intensive building where the owner plans to use a CAFM system — the handover deliverable will be IFC-based. The Speckle workflow you ran during design and construction does not substitute for this. What you can do is use Speckle to organise and enrich asset data during the project, then export a structured IFC at handover. But this requires that your authoring tools are configured to produce correct IFC from the start, with stable GUIDs and populated property sets — which is an IFC problem, not a Speckle problem.

4.4 Federation Across Organisations Without Shared Tooling

The multi-consultant federation scenario is where IFC's vendor-neutrality matters most. A large infrastructure project might involve:

An architect on ArchiCAD
A structural engineer on Tekla
An MEP consultant on MagiCAD / Revit MEP
A civils sub-consultant on Civil 3D
A geotechnical specialist on PLAXIS with custom outputs
A cost consultant on no 3D platform at all

Getting all of these parties onto Speckle requires each of them to install and configure a Speckle connector, connect to your server (or Speckle Cloud), and understand the versioning model. For the architect, structural engineer, MEP consultant, and civils team — all of whom are using software with native Speckle connectors — this is achievable. For the geotechnical specialist and cost consultant, it may not be.

Even where connectors exist, the human side of connector adoption is non-trivial. A BIM Manager does not unilaterally decide that the civil sub-consultant will use Speckle. The civil sub-consultant has their own BIM procedures, their own server infrastructure or lack thereof, their own data security constraints, and potentially their own client commitments on data handling. Negotiating a shared Speckle workspace across organisations adds a procurement and contractual dimension that IFC file exchange — being file-based and requiring no shared platform — sidesteps entirely.

IFC's federation model requires no shared platform. Each discipline produces an IFC file from their native application. The BIM coordinator receives all files, loads them into a federation viewer (Navisworks, Solibri, Revizto), and runs coordination. The geotechnical specialist exports from PLAXIS using a PLAXIS-to-IFC bridge. The cost consultant receives an IFC and runs quantity extraction against it.

The federation tool itself — Navisworks, Solibri, Revizto — acts as the common layer. Each participant keeps their own tooling and workflow. The IFC file is the contract. This model has been working in large-scale construction for decades, and its familiarity is itself a value proposition: project teams know how to use it, contract lawyers know how to reference it, and dispute resolution processes know how to handle it.

This is not ideal — manual file exchange is slower than automated version publishing — but it works across the entire supply chain without requiring anyone to adopt a new platform. The coordination tool is the common layer, not the authoring workflow.

4.5 Infrastructure Projects and IFC 4.3

IFC 4.3 (ISO 16739-1:2024) extended IFC's scope from buildings to linear infrastructure. The IFC 4.3 programme covers:

Road infrastructure (IFC Road)
Railway infrastructure (IFC Rail)
Bridge structures (IFC Bridge)
Ports and inland waterways

buildingSMART finalised IFC 4.3 as an ISO standard in 2022/2023. This matters because many national transport authorities — UK Highways, Network Rail, Transport for NSW, Infrabel (Belgium) — are now writing IFC 4.3 into their digital delivery specifications for infrastructure projects. The alignment, track geometry, culverts, earthworks, and drainage elements in an IFC 4.3 model are formally typed entities with defined property sets and spatial containment structures.

Speckle has no equivalent schema for linear infrastructure at this level of formal specification. You can push Civil 3D geometry into Speckle (the Civil 3D connector supports corridors, alignments, and surfaces), but the resulting objects carry Civil 3D's internal property structure, not IFC 4.3's formally typed infrastructure objects. An authority expecting an IfcAlignment with IfcLinearElement geometry representations will not find them in a Speckle stream.

For infrastructure projects governed by IFC 4.3 mandates, IFC is the only answer. Speckle can coexist as an internal coordination and analysis tool, but it cannot produce the mandated deliverable.

4.6 Archive-Grade Interchange and Long-Term Schema Stability

IFC is an ISO standard published in human-readable text (STEP Part 21 / ASCII encoding). An IFC 2x3 file produced in 2010 can be parsed and interpreted today by any IFC-compliant tool. The schema is publicly documented, the encoding is self-describing, and the file requires no proprietary runtime to read. This is not an accident — it was a design goal. IFC was intended to be an archival format for building data.

Speckle's object model is extensible and dynamic by design. A Speckle object's properties are defined by the kit and connector that created them, which can change between connector versions. The object hash ensures immutability of stored content — if you have a hash, the object will always return the same data. But if the kit schema changes, the interpretation of what that data means may change. There is no formal governance process that guarantees Speckle objects produced by the Revit connector v2 will be interpretable by an arbitrary tool in 2035 in the same way that an IFC 2x3 file produced in 2010 is interpretable today.

For long-duration projects — toll infrastructure with 25-year concession periods, hospital assets with 60-year operational lifespans, government buildings subject to ongoing statutory records requirements — archive-grade interchange matters. IFC is the appropriate choice for records that must survive software tool cycles.

4.7 Per-Use-Case Decision Tree

Is the deliverable contractually specified as IFC?
If yes: you must produce IFC. Use your authoring tool's IFC exporter. You can also run Speckle in parallel for internal collaboration. If no: proceed to the next question.
Will the data be received by an organisation that cannot or will not install Speckle connectors?
If yes, and the receiving organisation uses IFC-based tools: use IFC for that exchange. Speckle can handle internal workflows. If no: proceed.
Is the deliverable a COBie or FM handover package?
If yes: the handover must be IFC-aligned (COBie is a subset of IFC). Use IFC for the handover deliverable. If no: proceed.
Is this an infrastructure project with a formal IFC 4.3 mandate?
If yes: IFC 4.3 for the mandated deliverables. If no: proceed.
Is the archive period more than 10 years and schema stability a stated requirement?
If yes: IFC for the archival record. If no: proceed.
Assess Speckle fit
If you have reached this step: the exchange is internal or the receiving party is willing to use Speckle. Evaluate: do you need real-time web access, model diff, custom dashboards, or computational design round-trips? If any of these: Speckle is the better tool for this exchange.

4.8 The IFC Translation Problem: Honest Accounting

It is worth acknowledging the genuine problems with IFC in practice, because the decision is not "perfect IFC vs. imperfect Speckle" but rather a comparison of two tools with real limitations.

IFC round-trips between Revit and ArchiCAD are notoriously problematic. Elements that are parametrically defined in Revit (curtain walls, complex families) often import into ArchiCAD as generic mesh bodies that cannot be edited as BIM elements. Solid Element Operations flatten to boundary representations. NURBS objects get tessellated at low resolution. Walls and structural elements lose their type identity and become "Generic Models."

The IFC standard notes explicitly that the format "is intended for information and geometry exchange, but not for round trips." This is a significant limitation that practitioners who use IFC daily understand, but that marketing materials for openBIM rarely acknowledge.

The translation fidelity problem has a technical root. IFC defines a schema with formally typed entities — an IfcWall has a specific data structure, a specific set of allowed property sets, and a specific geometric representation. Revit walls and ArchiCAD walls map to IfcWall through different converter implementations. When Revit exports an IfcWall, it uses its own exporter logic to produce the geometry representation. When ArchiCAD imports that IfcWall, it uses its own importer logic to reconstruct a native ArchiCAD wall. The round-trip depends on the compatibility of two independently implemented converters, not on the IFC schema itself. The schema may be stable; the implementations are not.

This is why the same IFC file can import perfectly into Solibri (which renders IFC natively and makes no attempt to convert to a host-application object model) but fail to produce editable ArchiCAD elements. Solibri reads the IFC schema directly. ArchiCAD's IFC importer tries to reconstruct a native ArchiCAD wall from the IFC encoding, which is a much harder problem.

IFC property set mapping is also non-trivial. The number of IFC property sets is large, their mapping to application-native parameters requires configuration, and the configuration is not automatically preserved across software updates. An IFC export that was correctly configured in Revit 2022 may need recalibration after an upgrade to Revit 2025 if the exporter internals changed.

The buildingSMART IDS (Information Delivery Specification) standard attempts to address this by making property set requirements machine-checkable — you specify which entities must carry which property sets with which data types, and IDS validators can check compliance. But IDS validation is an addition to the IFC workflow, not a simplification of it. It adds another artifact to maintain and another tool to integrate.

None of this invalidates IFC for the use cases where it is mandatory. But it does mean that teams should be clear-eyed about the maintenance burden of IFC workflows, and should not assume that IFC handles all inter-application exchange more cleanly than Speckle handles it within its supported connector ecosystem. Speckle's translation losses are real too — the Revit connector does not perfectly preserve every Revit object type, and some elements convert to geometry without BIM semantics. But Speckle's losses are often visible within the same toolchain, whereas IFC's losses are often only discovered when the receiving party opens the file in their application and finds broken elements.

5. Anti-Patterns

5.1 Speckle as IFC Replacement

The most common mistake made by teams adopting Speckle is treating it as a drop-in replacement for IFC. The reasoning sounds plausible: "Speckle handles all our inter-application data exchange, so we don't need to maintain IFC export workflows anymore."

This fails for the reasons documented in section 4. Speckle does not produce IFC. No Speckle connector produces an IFC file as output. If your project has IFC deliverable requirements — whether contractual, regulatory, or client-driven — those requirements do not disappear because your team is also using Speckle.

The correct mental model: Speckle is a real-time collaboration and data platform that operates alongside authoring tools. IFC is a deliverable format produced from those authoring tools. They are not in competition. Your Revit model can push to Speckle every hour and also export a stage-gate IFC on the contractual milestone dates. Maintaining both is not duplicated effort; they serve different audiences.

5.2 Forcing Third-Party Adoption

Speckle only works as an exchange mechanism when both sides have a Speckle connector or API access. Attempting to make Speckle the primary exchange mechanism with consultants or contractors who have not adopted it creates friction that typically results in one of two failure modes:

The external party uses a file-based workaround (they export IFC, you import it into Speckle via the fileimport service), which negates most of the real-time benefits.
The external party is effectively locked out of the collaboration platform and receives only static exports, creating a two-tier information access problem that the Speckle platform was not designed to produce.

The appropriate scope for Speckle as a primary exchange mechanism is within an organisation or within a project team where all parties have agreed to the tooling. For exchanges with the broader supply chain, IFC remains the practical choice.

5.3 Ignoring Data Residency for Cloud-Hosted Servers

Speckle Cloud is GDPR-compliant and offers regional data centers. But for projects involving sensitive data — defence contracts, government infrastructure, commercially sensitive master plans — the question of where data resides is not solved by GDPR compliance alone.

The specific risks:

Sub-processor chains: Speckle Cloud, like all SaaS platforms, uses cloud infrastructure (AWS, GCP, or Azure depending on region). Your data residency policy needs to be reconciled with the sub-processor chain of the cloud host, not just with Speckle's own servers.
Access control granularity: Speckle's sharing model is at the project level. Fine-grained element-level access control (visible to structural consultant, not visible to quantity surveyor) is not natively supported.
Audit logs: Speckle Cloud provides some audit capability, but it may not satisfy the audit log requirements of a government contract that specifies ISO 27001-aligned logging.
Data classification mismatches: Some organisations classify 3D building models as RESTRICTED or higher, particularly for secure facilities, prisons, courts, or critical national infrastructure. Sending these models to a SaaS platform — even a GDPR-compliant, European-hosted one — may violate the classification policy.

Self-hosting resolves the sub-processor and data residency concerns. It introduces infrastructure maintenance burden. The trade-off should be evaluated against the specific project requirements, not assumed to be negligible. The self-hosted path is well-documented and realistic for organisations with a DevOps function; it is a genuine operational burden for firms without dedicated infrastructure capability.

5.4 Treating Speckle as the Source of Truth

Speckle is a data hub — it stores and versions what connectors send to it. It is not an authoring tool. The source of truth is and must remain the authoring application: Revit, Tekla, Rhino, or whatever tool the discipline engineer uses. A common failure mode is treating the Speckle version as the canonical record and allowing the authoring model to drift or be lost. When this happens, the Speckle data cannot be re-imported into a new authoring model without conversion loss, because Speckle's schema and the authoring tool's native schema are not lossless inverses of each other.

This failure mode appears in teams that get excited about the Speckle viewer and start treating it as the primary review environment, while the authoring Revit model falls behind. The viewer shows an older version; the architect makes changes in Revit; nobody has published those changes to Speckle; the client reviews the stale viewer version and comments on geometry that has already been changed. Information lag in a tool designed to eliminate information lag is a particularly embarrassing failure.

The workflow should be: author → Speckle (for collaboration and analytics) → author (for changes and downstream deliverables). Not: author → Speckle → Speckle as permanent record.

5.5 Under-specifying the BEP

A Speckle-enabled project needs its own information requirements defined explicitly, just as an IFC-based project needs a BIM Execution Plan. What models are maintained? At what cadence does each model publish to Speckle? Which models are the reference for which disciplines? When a Speckle version is issued at a project milestone, what quality checks must pass before it is marked as the milestone issue?

Without these definitions, teams drift into informal practices: the architect publishes when they remember to, the structural engineer publishes a different model branch from the one the architect is referencing, and the version history becomes a log of arbitrary saves rather than a meaningful record of design progression.

The BEP for a Speckle-enabled project should specify project naming conventions (project IDs, model names, branch naming standards), publication triggers and frequency, milestone issue definitions (which version hash constitutes the milestone deliverable), Automate function configurations and pass/fail criteria, and access control decisions (who can view, who can publish, who can comment).

This is not more work than a conventional BIM Execution Plan. It is the same work, applied to a different platform. Teams that skip it discover the same coordination failures that IFC-only teams discover when they skip their BEP.

6. Case Studies

The following scenarios are composites drawn from publicly documented use cases at firms including Arup, Gensler, and China State Construction, cross-referenced with capabilities documented in AEC Magazine, DataDrivenAEC, and the Speckle blog. They are not attributed to specific projects.

6.1 Owner Dashboard for a Mixed-Use Development

Context: A 45,000 m² mixed-use development with approximately 400 residential units and 8,000 m² of commercial space. The developer's investment committee expects a weekly briefing on design progress, including net-to-gross ratios by zone, room count by typology, and compliance of unit sizes against the approved planning brief.

Previous workflow: The BIM Manager exported a Revit schedule to Excel each week. The numbers were formatted manually. The Excel file was emailed. Any discrepancy between the Excel and the model required a new export.

Speckle implementation:

Revit connector configured to push the architectural model to a dedicated Speckle project on each "Save to Central" event (via webhook trigger).
Power BI connected to the Speckle project via the Power BI connector. Measures written in DAX to compute net-to-gross per floor, unit area distribution, and compliant vs. non-compliant unit counts.
The Speckle 3D visual embedded in the Power BI report allows the client to click a non-compliant room in the report and see it highlighted in the model.
Automate function configured to run on each new version and post a summary card to Microsoft Teams: version author, timestamp, unit count changes since the previous version, and a direct link to the diff view in the Speckle web app.

Outcomes: The weekly briefing became a live dashboard refresh. The developer's operations director could check design status at any time. Non-compliances were caught within hours of being introduced rather than discovered at the weekly review. The BIM Manager's weekly schedule export was eliminated.

What IFC contributed: The Stage 3 planning submission required an IFC 4 Reference View. This was produced from the same Revit model via the built-in IFC exporter, completely independent of the Speckle workflow.

6.2 Structural Optimisation Pipeline

Context: A medium-rise timber structure, approximately 12 storeys. The structural engineer is running iterative optimisation of the mass timber frame using a custom analysis script. The architect is working in Rhino. The structural BIM model is being built in Revit (for IFC deliverable) but the optimisation geometry needs to drive it.

Speckle implementation:

Structural engineer develops optimisation script in Python. The script generates candidate frame configurations, evaluates structural performance metrics (deflection, utilisation), and publishes results to a Speckle model (structure/optimisation) using the specklepy SDK. Each candidate is a separate version with the utilisation data attached as properties on each member object.
Architect opens the Speckle web viewer, filters members by utilisation ratio, and identifies which frame zones are over-utilised in each candidate.
After selecting an optimised configuration, the structural engineer uses a Dynamo script to receive that version from Speckle and drive the Revit structural model placement.
The Revit model then exports IFC for the coordination model and eventual handover.

# Python — Speckle round-trip for structural optimisation
# Receive an architecture version, run analysis, publish results
 
from specklepy.api.client import SpeckleClient
from specklepy.transports.server import ServerTransport
from specklepy.api import operations
from specklepy.api.credentials import get_default_account
 
def analyse_and_publish(
    project_id: str,
    arch_model_id: str,
    results_model_id: str
) -> str:
    """
    Receive latest architecture version, run analysis,
    publish results as a new version.
    """
    client = SpeckleClient(host="app.speckle.systems")
    account = get_default_account()
    client.authenticate_with_account(account)
 
    # --- Receive latest architecture version ---
    commits = client.commit.list(project_id, branch_name=arch_model_id, limit=1)
    latest_version = commits[0]
    arch_root_hash = latest_version.referencedObject
 
    transport = ServerTransport(client=client, stream_id=project_id)
    arch_model = operations.receive(
        obj_id=arch_root_hash,
        remote_transport=transport
    )
 
    # --- Run analysis (simplified) ---
    results = run_structural_analysis(arch_model)  # your analysis logic
 
    # --- Publish results ---
    results_transport = ServerTransport(client=client, stream_id=project_id)
    results_hash = operations.send(base=results, transports=[results_transport])
 
    version_id = client.commit.create(
        stream_id=project_id,
        object_id=results_hash,
        branch_name=results_model_id,
        message=f"Analysis against arch version {latest_version.id[:8]}",
        source_application="Python/StructuralAnalysis"
    )
 
    return version_id

Outcomes: The optimisation loop that previously took three days (export geometry, transfer file, remodel in analysis tool, export results, re-import to Revit) was reduced to a continuous pipeline. The architect could see structural utilisation overlaid on their design geometry in real time.

6.3 Model Diff Workflow for a Renovation Project

Context: A phased renovation of a 1960s commercial building. The existing conditions model is being progressively updated as survey work is completed. The design team needs to track exactly what changed between survey rounds and ensure that design elements do not conflict with newly surveyed conditions.

Speckle implementation:

Survey deliverables (point clouds and manually modelled existing conditions) are pushed to a Speckle model (existing/survey) after each site visit.
The Speckle web viewer's Compare Versions tool is used to identify new elements added since the previous survey version — new structural elements found behind cladding, services runs, drainage locations.
An Automate function runs on each new survey version and compares it against the current design model (design/architecture). Objects from the design model that intersect with new survey geometry are flagged and linked in a report posted to Teams.
The project architect reviews flagged items directly in the Speckle diff viewer, which renders both survey and design geometry simultaneously with the changed survey elements highlighted.

What IFC could not have done as efficiently: IFC model comparison requires exporting two static snapshots and running them through a comparison tool (Solibri's model checker, for example). The comparison is a manual step. Speckle's automated trigger on version publish, with automated diff notification and direct viewer link, collapsed a process that previously took half a day into a fifteen-minute automated alert cycle.

6.4 MEP Coordination Without Navisworks Licenses

Context: A commercial fit-out project with three MEP sub-consultants — mechanical, electrical, and public health. None of the sub-consultants have Navisworks licenses. The project manager wants the client to be able to review the combined MEP model weekly without installing any software.

Previous friction point: The lead consultant collected IFC files weekly, federated them in Navisworks, ran basic clash detection, produced a Navisworks NWD, and distributed it. Recipients without Navisworks could only open the NWD with the free Navisworks Freedom viewer, which has limited functionality. The process took two to three hours per week and produced a static snapshot.

Speckle implementation:

Each MEP sub-consultant was onboarded to a shared Speckle project workspace. Setup time per consultant: approximately thirty minutes including connector installation and authentication.
Each discipline publishes their model to a dedicated model within the project: mep/mechanical, mep/electrical, mep/public-health.
The Speckle web viewer aggregates all three models in a federated view. The client, the project manager, and the lead consultant can open this view in a browser at any time without software.
The weekly coordination session moved from a static NWD review to a live viewer session: participants filter by system type, use the section tool to cut through risers, and add inline comments that are visible to all project members.
Automate functions run clash detection logic on each new version publish, posting a summary of bounding-box intersections by severity to the project Teams channel.

Outcome: The weekly NWD preparation process was eliminated. Sub-consultants published their models directly. The client had continuous access to the live federated model. Clash comments were created and resolved in the Speckle viewer rather than via email with screenshot attachments.

IFC's role: The final coordinated model was exported as IFC at the end of the design development stage for the main contractor's Navisworks-based construction coordination. Speckle was used during design; IFC handled the contractor handoff.

7. Limits and Caveats

7.1 Adoption Curve

Speckle's connector model means that the platform's value is proportional to how many people in your supply chain are using it. In a team of six where everyone has installed the connector and understood the versioning model, Speckle is transformatively useful. In a project team of forty where fifteen people are external consultants using software without connectors (or without the willingness to install one), Speckle's value narrows to the internal team.

This is not a technical limitation of Speckle. It is a network effects problem that any platform faces before achieving ubiquity. IFC does not have this problem because IFC is the de facto standard and virtually every AEC software vendor provides an IFC exporter. Speckle's connector ecosystem is growing — the speckle-sharp repository covers Revit, Rhino, Grasshopper, Dynamo, AutoCAD, Civil 3D, and ETABS, and community connectors extend coverage further — but it is not universal.

The adoption question becomes more acute the further you go from the design team into the construction supply chain. General contractors, specialist subcontractors, and fabricators are less likely to be running Rhino or Revit. They may be using bespoke fabrication software with no Speckle connector and no API. Steel fabricators using Advance Steel, precast manufacturers using PLANBAR, curtain wall fabricators using proprietary systems — none of these have Speckle connectors in the current (2026) ecosystem. The IFC or DSTV export from those tools is the practical exchange mechanism.

BIM Managers evaluating Speckle for a project should conduct a connector coverage audit at project initiation: list every application used by every team member, verify connector availability and supported version, and identify gaps. For gaps, determine whether IFC or file-based exchange is the fallback. This audit takes an hour and prevents integration surprises mid-project.

7.2 Vendor Maturity Considerations

Speckle is a venture-backed startup that was formally incorporated around 2020. It has raised $12.5 million in Series A funding and has paying enterprise customers including Arup and Gensler. Its open-source core mitigates the lock-in risk that comes with any vendor-dependent platform: if Speckle Systems ceased to exist tomorrow, the Apache 2.0 server code would continue to be available, and existing self-hosted deployments would continue to function.

However, the product surface is still evolving rapidly. The terminology changed (streams → projects, branches → models, commits → versions) between major releases. The Automate product was in public beta through 2024–2025, with the full product launch introducing pricing tiers that were not yet finalised at the time of writing. API surface changes may affect integrations built on the v2 API. Teams building production integrations against the Speckle API should treat it as a capable but evolving platform, not a stable standard.

7.3 Element Support Gaps

Not every element type in every authoring tool is supported at the same fidelity in the Speckle connector. The Revit connector handles walls, floors, roofs, columns, beams, doors, windows, rooms, curtain walls, and MEP elements, but there are element types and parameter configurations that fall through to generic geometry. The supported elements matrix documents coverage per connector, but it requires checking against your specific model content.

For workflows where parameter fidelity is critical — MEP specifications, structural connection parameters, fire rating attributes — test the round-trip with representative elements from your actual model before committing to a Speckle-based workflow.

7.4 The Speckle-IFC Bridge

Speckle can import IFC files via the fileimport service. The importer parses the IFC and converts elements to Speckle objects, making them visible in the viewer and queryable via the API. However, this is a one-way translation: IFC → Speckle. The resulting Speckle objects carry the IFC property sets as dynamic properties, but they are not losslessly roundtrippable back to IFC. The conversion loses IFC type identity nuances, relationship structures, and geometry representation fidelity for complex elements.

This is actually a useful capability for teams that receive IFC models from consultants who have not adopted Speckle: you can import the IFC into a Speckle project, overlay it with your Revit or Rhino models, and coordinate in the Speckle viewer. The IFC-model consultant does not need to install anything. The limitation is that the IFC-derived Speckle objects are read-only reference geometry — they are not equivalent to models that came through a native Speckle connector, and Automate functions that expect native Speckle object types will not work correctly against them.

Use IFC import into Speckle for reference model overlay and visual coordination. Do not use it as a mechanism to transform IFC deliverables into Speckle objects for further authoring or downstream analysis that depends on element type fidelity.

7.5 Pricing and Business Model Evolution

Speckle operates on a tiered SaaS model. As of mid-2026, workspace plans run from a free tier (limited project count and version history) through per-user monthly pricing for professional and business tiers. Speckle Automate is priced on compute usage. Enterprise pricing is negotiated.

The pricing model has changed significantly since the platform's early days as a pure open-source project — a shift the company has described as moving away from what they called a "suicidal business model." The open-source core remains Apache 2.0, and self-hosted deployments are not paywalled. But the managed cloud service and Automate are commercial products with active pricing evolution.

Teams building production integrations on Speckle Cloud should model total cost of ownership including per-user licensing, Automate compute, and the cost of engineering time to build and maintain integrations. Self-hosted deployments avoid licensing costs but carry infrastructure and maintenance costs that should be estimated honestly — particularly for organisations without in-house DevOps capability.

8. Sources and Further Reading

The following primary sources were used in researching this article. URLs were verified accessible at time of writing.

Speckle official sources:

IFC and buildingSMART sources:

Third-party analysis:

Speckle: when to use it, when not

Server-Sent Events vs WebSockets in 2026: when SSE wins, backpressure, reconnect semantics

Webhook signature verification done right: HMAC, timing-safe compare, and replay defense

Postgres connection pooling at scale + serverless cold starts: pgbouncer, Supavisor, RDS Proxy