> That’s why selling SaaS or AI to this kind of company isn’t for me - I’d rather focus my energy on building a company from my own principles, and hire people who share them from the beginning.

> When I told my manager I was leaving, he said I should start my own company and give him a call when I do. So that's what I'm doing.

I love hearing stories like this, because it shows a way to be a builder without the "venture or nothing" narrative that has pervaded the tech space since the dotcom days.

It is very difficult to make a venture-backed services firm (providing services, not software) that can be immediately profitable, grow sustainably, and outperform competitors with in-house technology that's built for real on-the-ground stakeholders... at a speed that will satisfy venture investors.

But it is more possible than ever ([0]), to do this (in-house tech and all) on a bootstrapped basis - since AI reduces the engineering staff required to build, adapt, and maintain an agile best-in-class solution at single-tenant/single-customer scale. The outcome is at the least a lifestyle business, but with upside that can take the form of anything from franchising to licensing to full-fledged SaaS in the future.

I wish OOP the best of luck, and hope he's found a passion. He could go far with this approach if he ends up following through.

([0] This is not to say there are no barriers to entry. There's privilege in the word "founder," and this is no exception. And the K-shaped economy has left many brilliant would-be founders behind. But at least some barriers are lower than they once were, and that's worth appreciating.)

It's fascinating - how does one defend against an attacker or red-team who controls the CPU voltage rails with enough precision to bypass any instruction one writes? It's an entirely new class of vulnerability, as far as I can tell.

This talk https://www.youtube.com/watch?v=BBXKhrHi2eY indicates that others have had success doing this on Intel microcode as well - only in the past few months. Going to be some really exciting exploits coming out here!

Thanks for this history, I wasn't aware. It's an interesting point that if this is happening anyways by Apple's fiat, it's in the legacy CAs' interest to even further accelerate the mandatory timeline, so they can pivot to consulting services for their existing customers.

I do still feel that "that blog/publication that had immense cultural impact years ago, that was acquired/put on life support with annual certificate updates, will now be taken offline rather than migrated to a system that can support ACME automations, because the consultants charge more than the ad revenue" will be an unfortunate class of casualty. But that's progress, I suppose.

The certificate lifetime decrease, to 45 days, was discussed in: https://news.ycombinator.com/item?id=46117126

This isn't LE's decision: a 47 day max was voted on by the CA/Browser Forum.

https://www.digicert.com/blog/tls-certificate-lifetimes-will...

https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-sch...

https://groups.google.com/a/groups.cabforum.org/g/servercert... - public votes of all members, which were unanimously Yes or Abstain.

IMO this is a policy change that can Break the Internet, as many archived/legacy sites on old-school certificates may not be able to afford the upfront tech or ongoing labor to transition from annual to effectively-monthly renewals, and will simply be shut down.

And, per other comments, this will make LE the only viable option to modernize, and thus much more of a central point of failure than before.

But Let's Encrypt is not responsible for this move, and did not vote on the ballot.