Jeffrey Paul: Build / Buy / Bot

Jeffrey Paul

Build / Buy / Bot
24 December 2025
( 602 words, approximately 3 minutes reading time. )

In the old days when you ran your startup, you had to focus on your core objectives very closely in the early days. You had a limited number of innovation tokens, and beyond that you had to focus on your core product exclusively. No sysadminning (Heroku/Lambda), no hard drives (S3), no databases (RDS), no CDN (Cloudflare), no geth (Infura).

As a result, there are many SaaS startups that offer relatively straightforward services: things like APIs, API caching/aggregation/translation layers, industry-specific CRUD apps, image or video transcoding and resizing, analytics, webhook gateways, etc. They’re not hard to build, they’re just time-consuming, and adjacent to your startup’s core mission. You can pay them some small usage-based fee now, and if you get larger, you can build a replacement or renegotiate or change vendors.

A lot of SaaS startups’ secret sauce was simply having faster devs than their customers and perhaps on-call sysadmins, not some specific insight or unique knowledge about the problem space they are solving.

That’s all out the window now with SOTA AI models. Disparage “vibe coding” all you like, it’s here and it works and it’s going to change the world.

The build/buy equation just got an anvil dropped on one side of the seesaw, and your stupid SaaS startup idea is pulling a Wile E. Coyote midair at 30,000 feet. If all of the edge you had was that you could build it faster than your customers, you’re toast.

Competent engineers can now crank out a prototype supporting api/service (unrelated to their startup’s raison d’être) in a day or two, something that used to take a few people a month. Will it be as good and featureful and polished? No. Will it be as reliable? No, but serverless exists and bugfixes and test coverage will take minutes now instead of hours. It’s a startup, and it’ll probably be good enough, and close enough in perf to your free/startup tier that they’ll do that instead of paying you $49/month.

Furthermore, they’ll probably open source it, because it is unrelated to their profit model; remember, we’re talking about tangential supporting services here. If they don’t, someone else scratching that itch will. People will add features to it to make it more broadly useful on an as-needed basis. Bullshit “open core” startups will thankfully be toast.

The barrier to entry for starting a useful SaaS before was that you could actually ship working software faster than most. That’s gone now.

I expect:

  • many small orgs/startups choosing “build” much more often than “buy”
  • large orgs assigning small teams to build internal replacements for medium-to-large SaaS products that they are paying a vendor big recurring dollars for, because of the force multipliers that are LLMs
  • boring/basic CRUD b2b SaaSes to die even faster than they already are
  • a slight shift back toward b2c due to the decreased cost of platform-specific mobile client development
  • tons of SaaSes being replaced by f/oss projects
  • “open core” projects to have their data retention/SSO/2FA enterprise carrot nonfree plugins/libraries to be either replaced by vibe coded f/oss replacements that slot in easily to the “community edition”, or simply forked, as the cost of reviewing PRs and merging in upstream changes drops dramatically
  • increased frequency of new working and useful f/oss projects, because scratching an itch becomes so much easier and faster
    • I even have a few of my own. I imagine many others are tagging 1.0.0 of little side projects that have been pending for years.

About The Author

Jeffrey Paul is a hacker and security researcher living in Berlin and the founder of EEQJ, a consulting and research organization.

 sneak@sneak.berlin

 @sneak@sneak.berlin

 @sneakdotberlin

 @eeqj

 linkedin.com/in/jeffreypauleeqj