dpc10

For whatever reason I've preferred, at least so far, Fable to 5.6. I've spent the time since Fable's return being very cautious about when and how I use it, whereas with 5.6 (especially given OpenAI's generous limit resets) I'm pretty liberal about using it for lots of things that in the long run I could do with a less capable model.

Psychologically, I think that approach has made me value the delicate, ephemeral creature that is Fable more than I otherwise might. I don't know if that was Anthropic's plan, but if it was it worked on me at least.

But there's a limit to how many times they can play this card. Eventually either Fable has to blow me away so much that it justifies the API spend (it hasn't yet), or I have to decide that I can't rely on it, and I develop an approach that leans on it less heavily.

I don't know when we hit the tipping point from scarcity increasing perceived value to uncertainty reducing real value, but it can't be that far away.

In general more eyes on a real product are good for the companies making it. There's still the same need as always to triage the input--the easier it is to demo a product, the farther the average demo user is from your ideal user or product vision.

But it's hard to hide things in a real product demo, and that's something companies should embrace! Learn early and often, rather than find out only at the end of a protracted sales process that the buyer and seller weren't on the same page.

I love Postgres, and I agree with the general sentiment. But I read the (growing) genre of "use Postgres for everything" articles and they imply a difficulty in running other software that I just don't see.

I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange gives me a k/v store that I can thrash without worrying about performance (I know it's fast), downstream impact (am I slowing down critical-path SQL queries), etc. Especially in the age of LLMs, which I've found to be great at devops-type tasks, I feel slightly less compelled to simplify my stack.

Here's what I'd do if I were YC, especially having seen in this thread and on Twitter a bunch of seemingly promising startups that were rejected from Startup School:

Add a second chance--not just for those who received an incorrect email today, but for everyone who was rejected but fully audits the program. Toward the end of the ten weeks, allow startups auditing the course to submit a progress report or a second application, with some of those candidates--perhaps those that have shown the most growth over the course of the program?--accepted to participate in a later 10-week advisory program like the one Startup School offers on the advisory track. (I'm sure a chance at $10k would be appreciated as well.)

That would make Startup School a more appealing proposition for those who were not accepted, relieve some of the sting for those who are upset today, and to some extent correct for the fact that the selection process is inherently imperfect. From YC's perspective, it would increase participation in Startup School without requiring huge numbers of new advisors; you'd have 10 weeks to find a couple of new advisors for a small batch of accepted second-chancers, or perhaps some of the first-run advisors would be willing to commit to a second round. Plus this would give YC another opportunity to get in early with some of the most promising startups they rejected today.

(I think giving hope to people who were misinformed today would help alleviate some of the PR problems YC is surely going to face, but I'd add this as a permanent feature of Startup School anyway.)

We extracted Carom Analytics from the CRM we're working on, and we're releasing it for free since we've seen a lot of interest in actionable Stripe metrics--customer LTV, churn rates, etc. I'm happy to answer any questions and would welcome any feedback.