Users should be able to have full control over their experience interacting with third parties if they want it. This isn't unique to post-LLM stacks like this, but it seems like this shifts the balance of power.
The next step after injecting custom UI controls is to build completely alternative frontends. The next step after that should be to build generic local frontends that abstract over multiple comparable thirdparty providers.
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.
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.
I'm solving this from the other side of the equation: we work directly with the SaaS vendors to make vibe coding embedded into their platform. Working with some Series B companies right now, 2000 business users are now able to build any feature they want, within the guardrails of the SaaS vendor. (More info in profile if anyone wants to chat)
Exciting times!
However, the thought of the non-technical users I work with doing that is scary, they have no idea if the code the LLM writes is correct, is it going to have a bug that causes a massive issue down the line?
I've seen fat finger errors cause financial loss, but at least in those cases the user always had a chance to realise their error and fix it, with something like this how would you even know?
Now every customer can get the power of Claude Code and vibe coding in a safe and controlled environment.
Moloch demands babies be scarified to generate maximum profits!
For one, this is a very US concentric way of thinking. Secondly, if a human person thought like this we'd consider them to be an anti-social psychopath, which directly conflicts with the more recent SCOTUS ruling that companies are humans too.
So, yes, we have legally mandated companies be evil. It's been working out well for us in the US as prices skyrocket and any competition is bought up or abused with patents/IP.
No denying that. SaaS started with a user problem at the center of it and as they scaled, forgot about an individual user. This only presents the user frustration and a possible solution to it.
If you're building for individual users you're not going to succeed. We all prioritize for broad success from the beginning.
I'm very into the idea of inversion of control and giving users this flexibility but I agree with GP that the SaaS company critique is misplaced. I hope you find enough success with 100X that you end up coming to the same conclusion.
I'll also add that one of your video examples is essentially a Twitter spam generator; is that the kind of feature you think SaaS companies should be prioritizing?
Shameless plug: my company does it, live with Series B companies.
A TOS/CSA should in no way ever attempt to prohibit automation, and if it does, it (generally) deserves to be disrespected.
There is a legitimate concern however about customer resource use escalating beyond what was expected when the price was set. Luckily this can be written as a simple black and white determination without any complicated gray areas, and is therefore easily enforced both in the code and in the contract.
This is not a moat.
