logoalt Hacker News

brettgriffinyesterday at 8:43 PM3 repliesview on HN

> Our thesis is that the cost of producing code is heading towards zero

This (correct) thesis should illicit an interesting question about the future of SaaS markets: What happens to the SaaS markets when the cost of code approaches zero?

Coincidentally, the company that authored this post is a perfect case study.

Few people truly grasp how hard bringing a software product to market is. The feature density required to even begin selling your product often requires more human capital than early stage investors are willing to underwrite. Some founders have the background to command those terms, but most have to wedge into a market with some very small insight.

I was at a dinner with the CEO of Greenhouse in 2021 and vividly recall him explaining just how deep the feature set of a new ATS needs to be to even enter the consideration set of a buyer.

One serendipitous way companies could enter these markets is by being founded in one market, and pivoting into another. Ashby didn't start as an ATS. They were originally targeting a mid-market ERP (a hot thesis at the time). Ashby is a prime example of a company that likely could not have entered their current market because of the sheer engineering resources required to break through (and kudos to them for doing it!)

But as the cost of code approaches zero, the deterrents of entering the market also drop to zero. The next Ashby could just pursue ATS from day one. In a sense, this is the entire story of humanity and especially software (consider the cost of building an ATS in 2012 when Lever was founded vs the cost Ashby faced in 2019).

But the slope of this change is unlike anything before it.

ATS, like many other markets, has a handful of big players and a long tail of smaller offerings. No matter how many long tail providers there are, the economics of entering a market suppressed that number compared to what can and will exist tomorrow. The cost of building an ATS a decade ago was literally orders of magnitude more than it is today.

In 2016 I heard a A16Z partner describe a future where every software market would have offerings in virtually every little niche one could imagine. Years before the LLM renaissance, this sounded insane. How could the market afford to build and sustain each offering?

I don't think companies are going to start building their ATS in house, but I do believe that cost of producing code is approaching to zero, and that means hundreds or even thousands of offerings will exist in every shape, way and form we can imagine.


Replies

jpalawagayesterday at 10:47 PM

I suspect the ceo of greenhouse wasn't saying 'and there will never be another new ats again.' that's a ridiculous thing to say, as evidenced by the fact that greenhouse and lever both cropped up.

the reality actually is, you DO need depth in order to close lucrative enterprise contracts.

but startups will use anything. you use early money/traction to fund the deeper features. that's saas/startup 101.

anyhow, saas just means the second "s" matters more. maybe software gets cheaper (that's actually an unproven hypothesis), but service encompasses many dimensions. the most lucrative contracts won't be eaten by fly-by-the-night operations almost by definition. any startup that knows the words 'vendor risk' will tell you.

show 1 reply
fontaintoday at 12:34 AM

“What happens to the SaaS markets when the cost of code approaches zero?” … “Few people truly grasp how hard bringing a software product to market is.”

Are these related? The difficulty of bringing a software product to market has never been that it takes time to produce code. We’ve had the concept of MVPs for decades and pre-AI companies have raised hundreds of millions off of no code prototypes.

YC has always preached that you launch. Launch today. Launch as soon as is humanly possible. And learn. And iterate. You get something into the market as soon as possible. Spending years building the perfect software has never been the strategy pursued by technology startups, and not because of the time it takes, but because you need users to know what to build.

I think we could even go as far as to counter your argument. We know that constraints are powerful. Constraints force us to focus. Imagine you decide to build an ATS. You spend a bunch of money on Claude Code to generate hundreds of features, every little idea you can think of, you include it. You launch with the most complete ATS on the market. Ashby can’t hold a candle to the depth of your software. Do you have a better chance of success than if you had launched with a much smaller surface area, experimented, found the right area of focus, and iterated according to user behavior?

I encounter a lot of vibe coded software products that people are launching and I am not precious about code, a good product is a good product whether it was hand crafted over a decade by a thousand well paid programmers or generated in an afternoon by Claude Code from a laypersons prompt. I can name one single vibe coded product I pay for that is genuinely good software. All that the AI age has done is show that most of us absolutely suck at building products, and that even with free code, what we produce is garbage.

“How could the market afford to build and sustain each offering?”

I think you’re conflating build and sustain here. Nothing fundamental about business has changed. Sustaining a business isn’t about being able to generate code. Even in a world where code is free, how could the market sustain 10,000 Ashbys? Where are the customers coming from?

As a concrete example: how many customers does Jira have despite Linear being better software in every single way? Would generating 1,000 more Linears change Jira’s market position? Or Microsoft Teams, Teams is awful, there are so many better options. Will generating 1,000 more better options change Microsoft Teams’s position?

show 1 reply
abhikptoday at 12:12 AM

Co-Founder of Ashby here, just want to correct the record, that we were not targeting a mid-market ERP. We really wanted to build better hiring software. While our first customer was on our analytics-only product, it was built on a platform intended to be an ATS. We did build some abstractions/building blocks that are not hiring-software-specific (e.g., a workflow engine) because we recognized they allowed us to build rich features faster.

show 1 reply