# I Spent 15 Years Selling Custom Software. AI Is Making Me Rethink the Market I Knew.

Over 15 years of running a software agency, I lost plenty of proposals to nobody at all. The prospective client heard the price, did the math, and went back to a spreadsheet. I filed those as lost deals and moved on.

An essay I read in March made me reopen that file.

Julien Bek's Sequoia piece, ["Services: The New Software"](https://sequoiacap.com/article/services-the-new-software/), got quoted everywhere for one line: "For every dollar spent on software, six are spent on services."

Another part stayed with me longer.

Bek mapped ten service industries where AI companies could sell completed work instead of tools: the filed tax return rather than tax-preparation software. Insurance brokerage, accounting and audit, healthcare revenue cycle, claims adjusting, tax, transactional legal work, IT managed services, supply chain, recruitment, and management consulting all made the list.

Custom software development didn't.

I didn't read that as a mistake. The list is illustrative, and managed IT services are on it already. But I now run a company that generates working applications from specifications, and I kept wondering whether the industry where I spent those 15 years belonged somewhere on that map.

Those years give me old assumptions to test, not a forecast. We're building inside this change, and I don't feel ahead of it. I'm learning from each client project.

One of those projects made the question concrete.

## What Pulse is actually selling

Pulse is a startup building private community software. Its founder came to us with an outcome to deliver, not a request for a better coding tool.

Members needed profiles, matching, and a way to find relevant people. Each organization's data had to stay inside its own private application. Members and administrators also wanted to use the system directly from ChatGPT or Claude.

We built the product through Metatable. In September, Pulse shows the product publicly for the first time, at an event run by an international business organization. It's also talking with three other professional and event communities about pilots, each at a different stage.

For each prospect, we discuss what the community needs. My CTO and I turn those conversations into product decisions, then guide the build and keep working until the result is ready. Pulse gets a turnkey product. It doesn't have to operate Metatable or make the engineering decisions itself.

The relationship is easy to misread. A community gets a functioning private network from Pulse. Pulse gets a finished software product from us. Both arrangements deliver an outcome, and in both, the technology stays behind the delivery.

One startup and a small pipeline aren't enough evidence to call a category. They were enough to make me see two parts of Bek's thesis differently.

## Software has an unusual feedback loop

Bek separates professional work into intelligence and judgment. Intelligence follows rules. Judgment depends on context, experience, and taste. Work with a higher intelligence ratio should move to AI sooner.

I wonder if there's another useful axis: how quickly the work can reveal its own errors.

A tax position can look reasonable and fail in an audit years later. A weak contract clause stays hidden until a dispute; a claims decision can clear internal review and still end up in court. Feedback arrives slowly, and a qualified human stays responsible for the output the whole time.

Software often fails more loudly.

You can run it before delivering it. Does sign-in work? Does matching return the right people? Can each person see only what they're allowed to see? Each check produces an immediate answer, and when something fails, the system can use that result to correct the work and try again.

Passing those checks doesn't make the product good. A working application can still solve the wrong problem or confuse the people using it. I learned long ago that delivering what a client requested isn't always the same as delivering what the client needed.

Still, the feedback loop seems important. It lets AI verify a meaningful part of the work before a customer sees it. I suspect this is one reason software development adopted AI so early, and one reason custom development may be suited to selling finished work rather than tools.

The judgment has to live somewhere. Pulse understands its market and brings us what each prospect needs. My CTO and I decide how those needs should become a product: who the members are, what they can do, how matching should work, which unusual situations matter. We write those decisions into a specification, guide Metatable through the build, and judge what comes out.

Our development experience still matters here. We have intuition for the questions nobody asked and the decisions that will cause trouble a year from now. Metatable handles much of the building. The judgment stays ours.

## What a telecom still wanted to delegate

Another conversation complicated that model for me.

A national telecom operator approached us about an internal tool for salespeople in its retail network. Staff needed quick, reliable answers from the company's approved knowledge base while a customer was standing in front of them.

Metatable doesn't require customers to write code, so their team wouldn't need programming skills to use the platform. But they didn't want to operate the platform themselves. They wanted us to understand the problem, decide how the system should work, and deliver the outcome.

The coding barrier had disappeared. The desire to delegate had not.

Maybe that's the distinction I'd been missing. A customer can understand the problem clearly and still prefer that an experienced team owns the product and delivery decisions. Making a tool easier doesn't automatically turn a services buyer into a software user.

I find that hopeful for developers. Writing code is becoming a smaller part of the value. More of it sits closer to the client: finding the real constraint, and staying with the problem until the result works for them.

Delegation doesn't push the customer out of the decisions, though. The specification is plain language, so a buyer can read exactly what the system will do and push back before anything gets built. What they hand over is the engineering, not the understanding of their own business.

How much judgment can move into the system before a customer stops trusting it? I don't know. Different kinds of software will probably settle at different points.

## The demand I may have counted incorrectly

Bek recommends starting with outsourced work. The logic is strong: the buyer already pays for the outcome, the budget exists, and an AI-native provider can replace an existing vendor without asking the company to reorganize itself.

My mind keeps going back to the proposals from the top of this piece. They didn't lose to another agency. The client did the math and kept the spreadsheet. For years I counted them as lost leads. Some of them may have been evidence of demand the market couldn't serve.

No purchase showed up in the software market, no contract in the services market. The problem just stayed inside the business.

Bek calls a similar pattern "abandoned work" in procurement: companies skip negotiations with smaller suppliers because human attention would cost more than the likely savings. Custom software has its own abandoned work. It's the long queue of useful internal tools and narrowly focused products that never justified a conventional development project.

Private community software may be one example. Every network has its own members, permissions, matching logic, and data. Generic platforms cover the common features, but the valuable part is often specific to the group, which is exactly what made traditional custom development expensive.

AI changes that threshold. Much of the repeated work can be generated and checked, while human judgment is recorded in a plain-language specification. A useful product for one professional community no longer needs millions of potential users to justify being built.

AI assistants lower the threshold further. A member who only needs the system occasionally may never learn another dashboard, but they can ask ChatGPT or Claude to find a relevant person, request an introduction, or update a profile. The private application still holds the member data and rules. The assistant is just another way in.

We've been calling this [software you talk to](/blog/software-you-talk-to-headless-mcp). I'm still working out how far the idea goes.

## The questions I'm learning to ask

I can't tell from one startup's early pipeline whether private communities are a durable category. I also can't put a credible number on the custom software demand that never transacted. Market estimates vary too widely, and my own sales history is anecdote, not data.

But I now ask different questions when I look at an AI services opportunity.

How quickly can the finished work prove that it functions?

Who needed the outcome all along, but never entered the market because the old service cost too much?

And once the coding barrier is gone, which judgments does the customer still want to delegate?

Sequoia's map gave me no conclusion about custom software. What it gave me was a reason to go back through 15 years of calls, proposals, and rejected budgets.

Some of the clients I thought we'd lost may have been waiting for a different thing to buy.

If you're sitting on one of those problems, the internal tool or the niche product that never justified a development project, I'd like to hear about it. [Book a call with me](https://cal.com/metatable/ai-dev-tool-demo) or write to yd@metatable.ai.