Agave and the Rise of Vertical iPaaS platforms

how unified APIs unlock innovation

Are those UFOs or balloons? One may never know.

In the pre-software era, the problem for many founders setting out to transform industries was merely: how do I convince an industry to adapt technology at all?

In the middle of the current era, the question became: how do I convince some specific part of a company to adopt technology for their workflows?

The current rendition across the B2B landscape is simply: how on earth do I convince an industry or company to adopt yet another software tool?

Software has become priced into most industries. That’s very different than saying that existing software is good. But it’s not enough anymore for software to simply be better. More and more, it must be easy to integrate.

With the current macro portrait, every department in every industry wants to consolidate IT spend and also has scant resources for new SaaS.

For a wave of upstarts, this has meant that you must build out all the core integrations into the existing stack if you stand a chance at getting in the door.

Not only is this highly cumbersome, it’s incredibly inefficient. Engineering weeks that could be spent on product differentiation go to waste as teams comb through outdated API docs.

Luckily, a new wave of companies has been born to fix this. Enter iPaaS.

Some are generalized, integrating into all sorts of horizontal software. Merge API is the prime example here.

Others are tackling it by industry. Alloy is tackling the ecommerce space, Briza insurance, Chain.io is tackling logistics, and Agave is tackling construction.

So I had a chat with Tom Reno, the CEO at Agave, to talk about all things construction APIs and Integrations.

It’s always a blast to get to chat with extremely talented teams teams rethinking a vertical from first principles. Tom and the team have been tackling tricky data models for years. Their most recent stint was at Amazon doing something similar to make Alexa work.

But first, it’s a good time to chat about some of the nuances even within the integration space.

Unified API vs. iPaaS

There’s two types of integration services: no code automation platforms and unified APIs. When you think no code automation, think Zapier. Zapier lets you connect two apps with no dev work needed. That’s beneficial for quick and dirty integration work, but tends to be inadequate for deeper analysis or workflow support.

And it’s impossible for teams to embed a Zapier connection inside of a SaaS product trying to connect to different systems.

So no code iPaaS ends up far more focused on the end user.

On the flipside, when you think unified API, think Plaid. Plaid wants you to code and build the connections into your app, but they don’t want your dev teams to worry about provisioning access to different banks, dealing with different bank schemas, or anything irrelevant to what you are using the API for: accessing bank financial data.

That’s the model Agave chose with their Link product:

This solves both a real need for both developers and end users. End users want to integrate different data and developers need these actions to happen inside the system of record.

So with that framework in mind, we can begin to talk about the value of iPaaS and what makes unified APIs like Agave unique. I’m going to use the terms semi-interchangeably (mostly because unified API is a mouthful) but know that I’m mostly referring to the Agave/Plaid/Merge model.

Unified APIs as a Trade Language

All software is an attempt to model the world. Within a given vertical, distinct software will model the world slightly differently. Procore might refer to a Construction Project (in Agave terms) as a project while Autodesk might model this as a job. That complexity adds up - especially when a job in the ServiceTitan model means a wholly different thing.

Confused? That’s how most developers in construction feel. They have to manage both the complexity of modeling the industry and every other software vendor’s model complexity.

And if you’re a general contractor or builder in the industry using all this software, good luck parsing all this data into usable analytics. Your team will be combing through API docs to understand the differences in each software’s models.

And so we get to the first real reason that iPaaS platforms can be so powerful. They act as mechanisms that preserve the uniqueness of individual SaaS companies and yet standardize important aspects for better interoperability.

In Agave’s case, this has meant developing a unified schema for any important use case a developer might need. There is a hidden danger here. If you spend too much time philosophizing about the proper Platonic Forms of Construction Objects, you risk something best captured in this comic:

If you develop somep Platonic Ideal divorced from the construction industry and developers, around how Construction Objects should work, you risk simply building a competing standard.

But that’s not what Agave has done. Developing a Unified API in practice has looked quite similar to the development of pidgin languages.

Pidgin and iPaaS

On trade routes, a lingua franca for quick communication between different groups becomes necessary. In trade hubs where the language differences are high, pidgin languages evolve. These languages are distinct from any individual culture or tongue, and yet allow information and commerce to flow between.

Pidgin languages work by taking the essence necessary for quick and accurate communication and leaving behind a lot of the fluff. And naturally, they are ever-evolving as communication needs change or expand.

That’s basically how the best Unified APIs develop as well. It’s not so much “here’s a top-down model for how construction data models should work.” It’s far more about uncovering the trade routes between software systems and developing a working language for traveling data.

As Tom says, “Interoperability has to solve a problem.” And there is no point building along unused trade routes. As crisp as Agave’s data models are, crispness isn’t the point; the point is to be used.

And as the construction SaaS ecosystem develops, that is exactly what is happening.

iPaaS as the new Data Platform

A second thing occurs when you render disparate data useful and interoperable: You get to build data products used by industry participants.

If the first value proposition for unified APIs is around the developer experience, the data product side is far more focused on industry firms.

Across many verticals, business intelligence tools aren't great. Either they’re too insular or require far too much work for users to set up. Data is the new oil, but if you’re drilling in the wrong location or your drilling techniques stink, you’re going to inefficiently use data.¹

Earlier this week, Anna Khan at CRV noted that:

”Vertical SaaS companies at their core are one of two products: They are either 1) a workflow product that eases an existing manual process, or 2) an analytics product that takes important data from a number of tools in use and makes it more actionable.”²

She also notes that it’s really rare to do both well. I mostly agree. And what’s fun about companies like Agave is that they can provide exceptional tooling for analytics and shore up the gaps in existing products.

This realization that most software BI tools are inadequate has shaped entire companies as of late. Everyone is attempting to figure out why.

If you look at what Snowflake has been up to, a lot of their work has been concentrated in developing shared contexts for industries to solve these inefficiencies, albeit with far less BI and far more data standardization. This all happens pretty far from the original source - the system of record where the data originated.

But when you standardize that data far closer to the source - when data is still flowing through the pipes to its final destination, things change. Since standardization happens en route, the end destination can be more opinionated in how to build out useful analytics. That’s exactly what Agave is doing.

And even better, since Agave is in constant communication with its customers - both developers and users within the industry, they get a great glimpse into what data insights are necessary, hard to access, and worth paying for.

a sample dashboard

In the process of developing an integration platform, the Agave team has de facto developed a construction ontology - a working knowledge graph of how different workflows, insights, and more work together.

That knowledge graph is incredibly useful as the industry continues to become more data driven, but constrained by a highly fragmented software stack.

My hunch is this product set will ultimately be where Agave unlocks a ton of value. When you think about Rippling, they spent about 2 years building out integrations before getting to turn those integrations into a useful product. The beauty (and why API platforms are heavily underestimated initially) is that Agave get paid to do intense integration work and also get to build out additional products on top where they will accrue far more value. A far better construction analytics product is coming.

iPaaS as Switzerland

There’s one last dimension of iPaaS platforms that is important but with somewhat unknown ramifications: iPaaS vendors are well positioned to navigate an ecosystem of adversaries.

More succintly (and to state the obvious): Autodesk and Procore are in competition with each other. And in fact, they would prefer that other software partners choose sides.

But as a construction startup, that’s usually not in your best interest. For instance, StructShare wants to fix construction materials procurement and wants to work with both Autodesk and Procore users to integrate relevant data. Having to pick a side to get an integration is bad for business and bad for innovation.

Enter Agave - construction developer Switzerland. As a neutral party, Agave gets to liaise with both sides. After all, there’s a lot to gain for Autodesk and Procore too. Having a buffer zone that still makes integrations far easier is a huge benefit to them as well.

And it turns out that even besides the actual integrations, Agave’s business development function is immensely valuable for their customers. Tom thinks it’s underrated how long it can take to get API access to crucial platforms, up to 11 months for some. And for startups without that much time or run rate, Agave is critical to their success.

Marketplace Infrastructure

Neutrality might ultimately help encourage innovation in the industry. As vSaaS ecosystems develop, the largest platforms build out marketplaces to help fellow software vendors get the word out about their product.

These marketplaces right now don’t have a lot of downsides. Procore isn’t charging their marketplace users fees for being featured. But you can imagine a day where Procore does. Apple sure does. And with a fee, will come additional costs passed on to customers.

In that world, it’s incredibly useful to have a network of pre-configured and independent integrations ready to go.

Agave today allows platforms to white label their integration on top of existing marketplaces, it’s not a stretch to imagine Agave one day rolling these into an independent marketplace themselves. At the very least, this sort of infrastructure might deter platforms with marketplaces from usurious fees on startups long term.

Industry Innovation Hubs

There’s one last reason vertical unified APIs are really exciting: they unlock innovation. Unified APIs in particular spur on new innovation.

Plaid did far more for fintech than solve bank authentification. I’d argue that they actually shifted the Overton Window amongst a whole generation of fintech founders on what’s possible. Plaid was not simply an integrator, they were an ideation partner for how to work with newly accessible data.

And my hunch is that when construction data flows far easier, we end up with a new wave of construction tech companies tackling previously intractable problems.

I don’t know quite what that looks like yet and neither does Agave, but it is a super exciting proposition. The best part about creating industry infrastructure is that people tend to use it in increasingly creative ways.³ And Agave is happy to be an ideation partner along the way.

Unified APIs decrease the surface area that founders have to trek in order to build net new things. With approachable and transparent data models like what Agave has built, I think we will witness a new construction tech era unfold.

Insider Knowledge - Notes on Building a Unified API

I thought it might be best to end with some insights from Tom about some of the things that go into building a great API platform.

On Unforeseen Network Effects:

What we didn’t realize going in was how network effects would work. Large industries have tight networks and word spreads quickly among partners + ISVs + GCs + VCs. Often our software partners will introduce us to their end users and vice versa. Everyone wants more interoperability when it benefits the business and will willingly facilitate introductions.

On When a Vertical is Ripe for Unified API:

Look for verticals where:

1. Buyers aren’t going to do a rip and replace and instead require new software to integrate into existing systems.

2. The core systems of record are in competition with each other.

3. Widely adopted systems don’t have great APIs.

4. There’s no industry standards.

5. Interoperability is becoming demanded.

6. Generalized iPaaS platforms like Zapier can’t build the nuanced integrations required.

7. And lastly, the demand for domain’s data/functionality is growing in order to build all sorts of new workflows.

And One Last Note on Interoperability:

Pursuing interoperability directly as an end in itself is a well-intentioned path to nowhere. You must target solving a specific business problem (revenue, cost).

Correspondingly, the volume of API calls performed doesn’t equal value. Some API transactions are far more valuable than others, even if they are low frequency.

Figuring out where the valuable API calls lie is usually the key to identifying where interoperability adds value.

1. Let’s see how many metaphors we can mix today, shall we?

2. https://medium.com/crv-insights/vertical-saas-decoded-five-takeaways-investors-and-entrepreneurs-often-overlook-63b3afb50def

3. Likewise, the current crop of logistics innovation is a direct result of increased interoperability and decreased integration costs.