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.
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.
what you're saying is that you were at a company that did that hard thing of shipping APIs as product.
If attention-span was shot with social-media, it has no chance in the age of AI. All these deep tech-tools potentially have tons of value, but if it doesn't make sense in 5 seconds, very hard to compete.
This could not be more wrong. Features do, because telling a user they can do X comes with a standing promise that it works, the results are correct, the ui is accessible, the feature cleanly interacts with all other features in the system (both now and in the future), corner cases are worked out, etc. And that burden is where prod+eng spend time.
So true. People are going to be sooo mad when they find out we all have these Build Features For Free buttons and just don't press them.
edit: reading further into this, the idea is perhaps that users vibe-code their own distinct UX with everything valuable to them. That's not a bad take, but even in that world, I wouldn't think UX and product disciplines become exposed for having no value at all.
> the idea is perhaps that users vibe-code their own distinct UX with everything valuable to them
I do find this interesting. I work on a complex business operations and reporting platform and every facility has their own lil quirks. More control in their hands would let them smooth out their workflows while still relying on the foundational work our platform does.
Yes, today's HN session has me nerd-sniped about what the future of product development looks like. I've been thinking how mock-to-prototype is just too slow when engineers can ship so much so fast. Eng needs design direction especially when it's too easy to "solve design" with tailwind components and "You're a designer from a top saas company" prompts.
But what if the new UX is less visual-first and more IA, primitives and well structured object models... now that has me thinking.