by Rhea Purohit in AI & I

TL;DR: Today we’re releasing a new episode of our podcast AI & I. Dan Shipper sits down with Henrik Werdelin, the founding partner at the startup studio Prehype, and cofounder of Audos, a platform where you can build your own AI startup. Watch on X or YouTube, or listen on Spotify or Apple Podcasts. Here’s a link to the episode transcript.

Was this newsletter forwarded to you? Sign up to get it in your inbox.

Henrik Werdelin wants to launch 1 million businesses that make $1 million each.

As the founding partner of Prehype—the startup studio behind companies like Barkbox and Ro Health—he’s spent the last decade helping founders turn ideas into successful, venture-backed companies. Now, he’s taking everything he’s learned and building it into Audos, a platform that helps everyday entrepreneurs use AI agents to brainstorm ideas, finance and market their products, and find niche audiences. He also recently co-authored a book, Me, My Customer, and AI, about the new shades of entrepreneurship that AI is creating.

After years of building companies and helping others do the same, Werdelin has developed a sharp eye for what really makes a startup work. In this episode of AI & I, Dan Shipper and Werdelin talk about what separates successful AI businesses from the rest. (We had Werdelin’s cofounder at Audos, Nicholas Thorne, on the podcast back in March of 2024.)

Click here to read the full post

Want the full text of all articles in RSS? Become a subscriber, or learn more.

I love SQL Server, and I’m excited for the release of 2025. I think the query processing keeps getting better, which means your apps are gonna go faster, with less code changes.

The AI stuff is a little fluffy, and I don’t think time will be kind to it, but I totally understand why Microsoft felt like they had to chase that buzzword. All the cool kids are doing it, just like they did blockchain and IOT, and Microsoft is always looking for any way they can to keep SQL Server relevant to developers.

However, I keep seeing stuff in other databases that really is innovative, and would genuinely make developers’ lives easier, and I find myself wishing that Microsoft would focus on these kinds of real-world usability improvements. Here are just a few that have come across my desk recently.

Optional From-First Syntax

Imagine being able to write your queries like this:

FROM dbo.Users u
INNER JOIN dbo.Comments c ON u.Id = c.UserId
SELECT u.Location, u.Reputation, c.Score, c.Text
WHERE u.DisplayName = N'Brent Ozar'
ORDER BY c.Score DESC;

If you wrote the from and joins first, then IntelliSense would actually be useful, because the select/where/order would all understand where you’re pulling data from. I am so sick and tired of starting my queries by typing:

FROM dbo.Users u
INNER JOIN dbo.Comments c ON u.Id = c.UserId

And then up-arrowing back up to the top to type SELECT, because now I get autocomplete. I have to do this so freakin’ often that the up and down arrows on my keyboard are visibly more worn out than most:

The only other keys that are even more worn out are the ones on the left side, and I’ll leave the reason why as an exercise for the reader:

DuckDB lets you type FROM first, but best of all, it’s optional – not required – so your queries work either the old school way, or the new from-first way. It’s a great way to gradually implement a better querying experience.

Native Rest or GraphQL API

Microsoft’s Azure Data API Builder sits in between your apps and your database. The DBA sets up the DAB, defining which tables people are allowed to query and update, and how joins are formed. It’s like a reporting universe, but for your applications.

Then, developers simply hit the API with REST or GraphQL requests like:

GET http://sqlserver:5000/api/Actor

And get easy-to-consume JSON result sets. It supports filtering, sorting, joins, etc, and even better, it has pagination by default, encouraging good, scalable development practices.

Because both the API inputs and outputs are standards, this would be usable across not just SQL Server, but other Microsoft (and other!) database products, especially if Microsoft implemented it in stuff like Azure SQL DB and CosmosDB. Instead of having to build Tabular Data Stream (TDS) support into every app development platform, any dev platform that supported the REST or GraphQL APIs and JSON output would instantly have access to Microsoft’s best relational databases. Easier app development = better chance that Microsoft databases will get picked to play.

Yes, Microsoft built this innovation, and yes, they made it open source. But because it’s buried in with the rest of their open source projects, it’ll never get the marketing attention it needs, and big companies often refuse to install any add-ons. If it was part of the boxed product itself, I think it’d get rapid adoption for new development projects. Will it find its way into the boxed product? Probably not, because it won’t increase licensing sales.

Better Query Plans with Plan Stitching

Back in 2018, Microsoft published a research paper about plan stitching: breaking query plans up into parts, compiling the parts separately, and then stitching together the various parts at runtime. It’s kinda like OPTION (RECOMPILE), but inside the query itself, while it’s running.

This would be so helpful for those 20-table-joins I see so often in reporting queries, not to mention people who like to join half a dozen nested views together. SQL Server just doesn’t stand a chance of building an accurate overall plan in situations like that. Instead, I’d love for it to start pulling data back from the first couple of tables, and then make different decisions based on how many rows come back from each table.

The research looked promising, albeit challenging (and expensive) to actually implement and test. I understand why it didn’t make the cut, but that doesn’t stop me from wishing for it. However, the next innovation is less nice-to-have, and more come-on-why-the-hell-don’t-we-have-this-yet….

Automatic Backups, Encryption, and Patching

When you provision an AWS RDS SQL Server instance (and you get similar options in Azure SQL DB, I just happened to be provisioning an RDS instance so I was reminded of this), you get a simple set of checkboxes and dropdowns:

Company-wide settings policies like Cost Threshold, MAXDOP, trace flags, etc – just a matter of picking them from a dropdown. Automatic backups? Already checked for you, with continuous point-in-time backups managed by the robots. Encryption? Of course. Automatic patching? Sure, if you want (not on by default) and you can even pick the maintenance windows when you want them to happen.

It’s 2025. Why are we screwing around with vector data types when SQL Server still installs itself in such a vulnerable state, with no backups, no corruption checking, and no ability to patch itself, and not offer any options during setup to mitigate these glaring problems? I hate whatever product manager is letting that happen. There’s a word for them, what is it, trying to think of it…

Valve has created a PC-based game console that lives under your TV. The Steam Machine takes everything that's great about the Steam Deck and adds the raw power to compete with the latest PlayStation and Xbox consoles. It also puts a huge amount of pressure on Microsoft to perfect its Windows and Xbox combination, as the Steam Machine brings Windows games to the living room in a way that Microsoft is dreaming up for its next-gen devices.

The Steam Machine looks like an Xbox Series X that has been cut in half into a miniature box. The 6-inch cube runs Windows PC games through Valve's Linux-based SteamOS, and it should have enough power throug …

Read the full story at The Verge.