If you started a company two years ago, many assumptions are no longer true

Build vs. buy is an eternal question in enterprises. I remember many in-house data teams trying to build tools for "digital transformation" and cloud migration about 10 years ago. The challenge was, building those tools was more expensive than those enterprises could budget for (IT as cost center), so a startup like Snowflake would easily outcompete in-house solutions with their custom, cloud-based tech stack that was necessarily complex because it needed to serve the needs of thousands of customers.

If he's right, the build vs. buy equation has shifted more towards build, at least as far as enterprise software is concerned. IT is still a cost center, but in theory an internal team can now handle more requests for custom tools without looking to outside vendors. Essentially the cost of building in-house might be collapsing and therefore enterprise software startups will be serving fewer customers (who would all pay you more because if solving the problem was cheap they'd do it).

If you had to build a stack for dozens of customers paying huge amounts of money, how would that stack differ from the stack you'd build to serve thousands of customers? Certainly it wouldn't need to be as scalable! And that's probably what he's getting at. I think what you'd do instead, to capture those higher price point customers, is solve their problems more specifically, in a higher value manner.

Many companies already do this, investing far more in field engineers than they do in their tech stack, since customization is essential.

So hand-waving about how easy it is to have an MVP in days w/o actually experience in doing that seems ironic.

Now, maybe he's saying this based on companies he's funded who've had great success with what he's saying. But it's curious that the only concrete example of a company mentioned is one that's six years old and not operating like that. And in fact, many of the ways he thinks that company went wrong seem completely unrelated to AI?

> Chris is now starting to raise his first large fundraising round. In looking at his investor deck I realized that while he’s been heads down, the world has changed around him – by a lot. The software moat he built with his 5-year investment in autonomy development is looking less unique every day. Autonomous drones and ground vehicles in Ukraine have spawned 10s, if not 100s, of companies with larger, better funded development teams working on the same problem.

> While Chris has been fighting for adoption for this niche market (one that is ripe for disruption, but the incumbents still control), the market for autonomy in an adjacent market – defense – has boomed. In the last five years VC Investment in defense startups has gone from zero to $20 billion/year. His product would be perfect for contested logistics and medical evacuation. But he had literally no clue these opportunities in the defense market had occurred.

> While there’s still a business to be had (Chris’s team has done amazing system integration with an existing airborne platform that makes his solution different from most), – it’s not the business he started.

"Being heads down without paying enough attention to the market for 6 (!!) years" doesn't seem like an AI-caused issue.

Meanwhile, the core suggestion doesn't seem to fix that, it seems almost completely perpendicular.

> You can now test multiple versions of the same business at once (or simultaneously be testing different businesses). While you can be simultaneously testing five pricing models, ten messages or twenty UX flows, the “user interface” may no longer be a screen at all. Testing might be to find prompt(s) to AI Agent(s) deliver needed outcomes.

Ok, but this person didn't even seem to be doing enough paying to the market of one version already?

And while this claim about parallel development being a huge unlock is the most interesting thing, it also sounds a bit glib. Getting your foot in the door is the hardest thing early on, now you're trying to run six versions of your company at once? Each time you get a foot in the door sales-wise, are you trying to make them use all 6 versions, or are you only gonna get feedback on 1? Would you want to pay money to be a beta tester of 6 different products simultaneously, with reason to believe that 5 of them will probably evaporate over night soon?

But this I just thought was vacuous. I agree with what you wrote, but more to the point, I didn't find any real advice about how a startup should actually change that passed my sniff test. I left the tech startup world about 2 years ago myself, and I'm glad I did, because I just think there are way fewer differentiable opportunities now. That is, even if I accept what Blank says is true, what are all these 2+ year old startups supposed to do - just create some model wrapper/RAG chatbot product like the million other startups out there?

Even in defense, like the article says, there are now a bajillion drone companies, and it looks like a race to the bottom. The most successful plan at this point just looks like the grifter plan, e.g. getting the current president to tweet out your stock ticker.

I'm honestly curious what folks think are good startup business plans these days. Even startups that looked they were "knock it out of the park" successes like Cursor and Lovable just seem like they have no moat to me - I see very few startups (particularly in the "We're AI for X!" that got a ton of funding in the past two years) with defensible positions.

It takes far less manual prompting to make it have consistent output, work well with other languages, etc. But if you watch the "thinking" logs it looks an awful lot like the "prompt engineering" you'd do by hand back then. And the output for tricky cases still sometimes goes sideways in obviously-naive-ways. The most telling thing in my experience is all the grepping, looping, refining - it's not "I loaded all twenty of these files into context and have such a perfect understanding of every line's place in the big picture that I can suggest a perfect-the-first-time maximally-elegant modification." It's targeted and tactical. Getting really good at its tactics for that stuff, though!

I can get more done now than a year ago because taking me out of the annoying part of that loop is very helpful.

But there's still a very curious gap that the tool that can quickly and easily recognize certain type of bugs if you ask them directly will also happily spit out those sorts of bugs while writing the code. "Making up fake functions" doesn't make it to the user much anymore, but "not going to be robust in production but technically satisfies the prompt" still does, despite it "knowing better" when you ask it about the code five seconds later.