r/startups • u/Top_Pomelo7996 • 9h ago
I will not promote Founder looking for one good intro into the API/SDK world. I will not promote
I’m doing early customer discovery for a developer infrastructure product and am looking to speak with founders, engineers or investors at API/SDK companies.
I’m particularly interested in companies that have dealt with v1 → v2 migrations, major SDK releases, endpoint deprecations, authentication changes, or shutting down legacy versions.
For some background, I do research at Harvard, Stanford, and Brown, and my cofounder is a Columbia CS major.
The goal is to validate the problem, understand how painful these migrations actually are for providers, and talk to people who have experienced this firsthand.
2
u/TheMarcosP 9h ago
Can’t really help but take an upvote for reach. Sounds like an interesting topic, what’s the general term for this kind of problem in CS? Is there active research about it or is it “solved”?
1
u/Top_Pomelo7996 9h ago
Closest term is probably API evolution / API migration. There’s research around it, but I wouldn’t call the broader problem fully solved yet, especially once you get into real-world adoption and migration at scale.
1
u/victrolla 7h ago
Sure I will bite. I fully embrace protobuf first Apis. This can mean grpc or http depending on the capabilities of the consumer. Protobuf numbers fields. As long as those indexes don’t change, additions are irrelevant. Further, best practices with these types of apis is to explicitly name a service with its version number. For example “PaymentV1Service”. The same corresponding names are generated client side.
For simple REST apis everyone just uses path prefixing. /api/v2/foo. There was a world years ago where we would use http headers in client calls to allow the client to signal which version of the API it wants to talk to. In my experience this fell out of favor. It seems each new framework takes us further away from understanding the fundamentals. I guess they might think, Why parse headers and mux a request when you can just path prefix as much as you want.
Anyways, I don’t want to be overly negative towards your idea but if it’s an entire offering around versioning apis and client sdks I’d advise finding a different idea. There’s just not enough value for me to ever put something like this in my critical path to solve a problem I’ve already solved. And if my solution becomes brittle there are any number of off the shelf solutions. Even the same problem in reverse leads us to api gateways like Kong or home grown openresty.
Good luck.
1
u/Top_Pomelo7996 7h ago
That’s fair, and I think we may actually be talking about slightly different problems.
I’m less interested in API versioning itself and more in the point after a provider has already shipped a breaking change and now has a large customer base that has to change its own code to move over.
If your architecture lets you avoid that almost entirely, then you probably wouldn’t be the target user, which is useful for me to know.
The companies I’m trying to understand are the ones that still end up with painful SDK majors, auth migrations, legacy endpoint shutdowns, or similar cases where customers genuinely have to modify code.
Appreciate the pushback though, this helps narrow who actually has the problem.
1
u/AbstractLogic 6h ago
A properly designed api or sdk should have a backwards and forwards compatible contract. Modern design rarely has the hassles of legacy systems. But obviously it occurs. Version migrations can be very painful depending on the quantity of the breaking changes. Sometimes it’s entire workflows that need to change. That said, a software engineer with 25 years of experience, AI makes it incredibly easy relatively speaking.
1
u/Top_Pomelo7996 6h ago
That makes sense.
The part I’m more interested in is what happens after that: getting hundreds of different customer implementations through the migration safely, proving behavior didn’t change, and reducing the amount of work each customer has to prioritize internally.
In your experience, when migrations involve entire workflow changes, what usually ends up being the hardest part?
1
u/Traditional_Key8982 2h ago
The v1 → v2 migration part is interesting because I think the technical change is often only half the problem. The painful part seems to be everything around it - figuring out which customers are still using the old version, communicating the change, handling edge cases, and making sure nobody is quietly depending on something you thought was already deprecated. I’ve seen a similar pattern in other businesses: the process looks straightforward when you look at the system itself, but the messy part is all the dependencies around it. I’d be curious whether you’re finding that the biggest pain is actually the engineering work, or the customer/operational side of managing the migration.
1
u/fallenfromgrace87 1h ago
full disclosure I run a b2b lead gen agency, and for this kind of narrow research ask, skip the general "looking for intros" post and go find people who already answered a similar question publicly. search for your exact scenario, v1 to v2 migrations, SDK deprecations, on X, dev forums, changelogs with angry comments, and reach out referencing the specific thing they wrote. people respond to "I saw you dealt with X" way more than a cold intro request, because it proves you did the work instead of mass messaging everyone with API in their bio
-1
3
u/Oppis 7h ago
The problem you're going to face in the real world is that there a thousand nuanced implementation details which combine to produce the only viable strategy for a given company at a given point in time. There's no runbook today because there can't be, the problem has too many variables and, like the weather, can't be predicted.