Architecture

When your business depends on someone else's API

If an outside provider can change its terms and stop your operation, you don't have a provider. You have a partner who never signed anything.

EK · VISIÓN 01 ANÁLISIS ACTIVO PARAGOLPES · 91% PUERTA · 74% ALETA · OK Coste reparación estimado 1.480 €

The risk nobody watches until it happens

There are entire businesses built on a third party's data. Valuations, reference prices, catalogs, appraisals. It works well and it's the right call at the start, because building that from scratch makes no sense while you're still validating a model.

The problem shows up later, once the business is already billing: that provider can raise the price, change the terms of use, or simply decide the deal no longer interests them. And there's no conversation to be had, because there's no alternative in place.

THREE PIECES

How it gets solved

The independence layer. No part of the system talks directly to the provider. Everything goes through an in-house middle layer. Today that layer asks the external provider; tomorrow it can ask an engine of its own, and the rest of the system never notices. That makes any provider interchangeable.

Persistence. Every query that's already being paid for gets saved. If a thousand queries a month are being paid for today, today those start becoming a thousand pieces of proprietary data a month. It's not extra work: it's a way of building. The same bill as always, with an asset accumulating behind it.

The ingestion engine. In parallel, a process keeps building a proprietary database from available public sources. With every month that passes, a larger share of the frequent questions can be answered without leaving the house.

It gets built from day zero

This is the point most worth understanding: doing it from the start costs practically nothing extra, because it's an architecture decision, not an added feature. Doing it two years later means rewriting half the system.

That's why we build it into the initial design even when the client doesn't see the risk yet. It's the kind of decision that only gets appreciated once it's too late to make it.

From cost to product

There's a second move, and it's the nice one. Once that proprietary database has enough volume and quality, it can be served to third parties through its own API, with its own keys and its own usage metering.

At that point the data stops being a line of expense and becomes a source of revenue. The same asset built to protect the business ends up billing for itself.

AN ORDINARY DAY

An email that's no longer a crisis

An email arrives from the provider announcing a rate change starting next month. In a company without this architecture, that email is a crisis and a negotiation from a position of weakness.

Here, it's just an email. Someone weighs up whether it's still worth it, compares it against what's already answered with proprietary data, and decides calmly. Which is exactly what all of this is for.

WHAT WE KEEP AND WHAT WE ADD

This isn't about breaking up with anyone.

Still the provider's

Their service, their data quality and the contractual relationship, which stays in place for as long as it's worth it.

What we add

The freedom to switch without anything stopping, a proprietary asset that grows every month, and the option to turn it into revenue.

Sam Laniakea

Does your business depend on an outside provider?

In a discovery call we review what you depend on today and where to start building your own independence layer.

Sam Laniakea

Using a different system? Tell us and we'll tell you on a call if it's possible.

Inspired?

Build your next big idea with EKUANTUM.