ReJot Thinks APIs Are Broken, and Their Fix Is Surprisingly Elegant

The Macro: APIs Were a Great Idea That Stopped Evolving

The API economy is supposed to work like this: a company builds a service, exposes an API, publishes documentation, ships an SDK, and developers integrate it in an afternoon. In practice, it almost never works that way. You install the SDK. Then you need to set up webhooks to handle async events. Then you need a database table to store the state you’re syncing. Then you need background jobs to handle retries when the webhook delivery fails. Then you realize the SDK doesn’t cover the specific endpoint you need. By the time you’re done, you’ve built a small distributed system just to integrate with one provider.

This is a known problem. Stripe has spent years making their integration experience as smooth as possible, and it still takes most teams multiple days to implement properly. Twilio’s documentation is excellent. The integration is still complex. Plaid, Shopify, Salesforce. Every API provider wrestles with the same gap between “here’s our SDK” and “here’s a working integration in your stack.”

The developer tools market has tried various approaches. Zapier and Make handle integrations at the workflow level, but they’re aimed at non-developers and fall apart for anything requiring custom logic. Merge and Unified.to aggregate APIs across categories but still leave you writing backend code. Nobody has really solved the fundamental problem: an SDK gives you access to a service, but it doesn’t give you the storage, sync logic, and frontend components needed to actually use it.

The Micro: What If Integrations Included the Backend?

ReJot is building Fragno, an open-source framework that packages backend endpoints, data storage, and frontend utilities into reusable building blocks. The idea is that API providers ship complete integrations instead of just SDKs. Instead of giving developers a library that makes HTTP requests and leaving them to figure out the rest, providers would ship a Fragno package that includes the data schema, sync logic, and UI components needed to actually use the service.

The underlying technology is interesting. ReJot uses asynchronous replication through your database’s write-ahead log. In plain terms, it turns your existing Postgres or MySQL database into a communication channel between services. No message brokers. No event buses. No outbox pattern. You define “public schemas” that describe the shape of data you’re publishing, and “consumer schemas” that describe how you want to receive and transform data from other services. Everything is SQL-based and version-controlled.

Wilco Kruijer is the CEO. He previously worked on a distributed financial platform at Adyen, one of the largest payment processors in Europe. Jan Schutte is the CTO, also ex-Adyen, where he was a data platform engineer. Both of them spent years working on exactly the kind of distributed data problems that ReJot is trying to solve. They’re a two-person team based in Amsterdam, part of YC’s Winter 2025 batch.

The Adyen background is relevant because Adyen processes payments for companies like Uber, Spotify, and eBay. The scale of data synchronization at that level is non-trivial. When your cofounders have built systems that handle millions of financial transactions across distributed infrastructure, you tend to trust their instincts on data replication.

The open-source angle is smart for developer tools. You can install the CLI right now with npm. The GitHub repo is public. Developer tools that start open-source have a much easier time getting adopted because engineers can evaluate them without talking to a sales team or signing up for a demo. Terraform, Docker, and Kubernetes all followed this pattern.

The Verdict

I like the thinking here. The gap between “we have an API” and “our customers can actually use our API” is real, and nobody has addressed it at the framework level. If Fragno gains traction with API providers, the compounding effect could be significant. Every provider that ships a Fragno package makes the framework more valuable to every developer who uses it.

The challenge is the classic chicken-and-egg problem for developer platforms. Developers won’t adopt Fragno until there are packages worth installing. API providers won’t build packages until developers are asking for them. ReJot needs to find a few high-value integration partners who will build packages early, then use those packages to demonstrate the value to the broader developer community. This is the same playbook that worked for Terraform providers and VS Code extensions, but it requires patience and a lot of developer relations work.

The competition isn’t really other developer tools. It’s the status quo. Most teams have already figured out how to integrate their critical APIs, even if the process was painful. Selling “this would have been easier” is harder than selling “this is now possible.” ReJot needs to find the use cases where existing integration patterns genuinely break down. Real-time sync across multiple services with schema evolution and versioning, that’s where the value proposition gets strongest.

At 30 days, I’d want to see which API providers have expressed interest in building Fragno packages. At 60 days, whether any production applications are using the framework. At 90 days, the question is contributor momentum. For an open-source developer tool, the number of external contributors is the best leading indicator of whether the project has crossed from interesting idea to something the community actually wants. The technical foundations look solid. The adoption curve will tell the rest of the story.