I’ve been seeing a few API-enabled startups in architecture and construction this year. Few of them API-first.
We first partnered with Speckle in 2020, leading their pre-seed raise. Dimitrie and Matteo have created an amazing API-first company distributing 3D data on the most granular object level.
But apart from 3D data, there is massive amounts of flat data in AEC that needs harmonization and easy distribution, such as invoice data, purchase orders, tickets and lots of project level information.
So where do we expect the API-first players in flat data to emerge? What do I look for?
Get the slide deck
There is 550 billion invoices issued globally per year. 10% of global GDP is construction. So, fair assumption that at least 55 billion invoices are issued in construction every year. That makes at least 165 billion flat documents (invoices, tickets, purchase orders etc.) in AEC. This number is most likely under-estimating the flat documents in construction, given lots of milestones and sub-contracts.
And yet, there is only a comparatively small handful of startups dealing with API-first in flat AEC data as time of writing. Selected examples are Agave, Comstruct, Gryps, or Toric.
So we used our learnings from 2020-2022, and combined them with our analysis of more than 100 well-known API (first) companies from other sectors.
(Here is our API startups market map and database – we made them open-source, so feel free to re-use)
And bam, here are our 10 commandments for API-first in AEC
#1 Repetitive data objects, used one billion times a year
Unified APIs need to process similar data points in same objects a billion times a year.
#2 Done repetitively and manually across systems
The data points are used repeatedly in manual workflows with iterative steps, switching systems + channels.
#3 Ability to focus on 1 scaleable property (ideally 2)
Either:
- one standardizeable data object (eg. ecommerce payment, account statement, 3D model)
- one standardized “host” software with market share >10% (eg. Procore, Revit, AutoCAD; NB: SAP doesn’t count due to customized instances)
- one super-repeatable customer type who already has tens of softwares and is building integrations with own dev team (eg. Mulesoft, Makini)
#4 Data points can be standardized BEFORE you reach scale
You need 1’000 samples to identify repeatable standardization and harmonization.
If you need 1’000’000 samples you picked the wrong object.
#5 Already digitally available
Data objects exist consistently in software. Implies: pre-requisite is high (legacy) software adoption by suppliers.
#6 Fragmented data providers offer non-harmonized data points
Integrations are expensive when point-to-point, fragmented, undocumented, and data is not harmonized.
#7 50%+ of market has no public APIs
There is not a dominating software provider that already has open APIs (eg. Twitter, Meta).
#8 hundreds of parties develop applications using the data points
Either:
- Inhouse engineering teams (eg. compliance, verification, security, eshop multi-payments before Stripe)
- Third-party software vendors or startups (eg. FinTechs with Plaid, HR/payroll startups)
#9 High existing software adoption from SMBs/startups (accelerant, not prerequisite)
Accelerant because:
Low resources to build all integrations inhouse. Hence, high value per customer per software integration offered while initial sales cycles are low and initial frequency is high.
#10 Software procurement done by software engineers (accelerant, not prerequisite)
Accelerant because:
Very difficult to achieve high sales velocity when procurement needs to pass on the discussion to engineers.
Sources
Number of invoices issued globally