[ebiester]

So, it's just changing the problem up a level.

First, is a 500 because you are using the API in a way that is unexpected a customer found defect? If Claude can't find the answer, what is the expectation of support?

If an internal team makes a change that breaks your workflow (because it was an unexpected use case), is that a CFD?

Do teams slow down in new features because the API must be the stress test of a public api?

I'm fine with unsupported frontends but an external API will be very difficult to keep static.

[raw_anon_1111]

The last company I worked for before going into consulting full time was a startup where I was the then new CTOs first technical hire. The company before then outsourced the actual technical work to a third party consulting company until they found product market fit.

His primary mandate was API and micro service first.

Our customers were large health care systems.

We had a customer facing website that was built on top of the same APIs that we sold our customers.

Our customers paid for the features they wanted and those features were available on our website, they were used for their website and mobile apps and the ETL process was either via a file they sent us and we ran through the same APIs or they could use our APIs directly for both online and batch processes.

This is no different from the API mandate Bezos made at Amazon back in 2000.

You don’t have to keep an API static - that’s what versioning is for.

[apsurd]

I think the talking point is maintaining a well versioned and solid API as product is way harder than shipping a few screens that can change whenever you need them to. (behind those screens being a bunch of duct tape to a clusterF of internal APIs). no guarantees.

what you're saying is that you were at a company that did that hard thing of shipping APIs as product.