I keep hearing some version of the same thing from companies right now: “We can build that ourselves.” Increasingly, they’re right. Give one or two really good engineers a month, access to the right data and APIs, and the AI tools available today, and they can build something that looks pretty damn good. That changes the buy-versus-build conversation quite a bit. Five years ago, building a serious piece of internal software usually required a larger team, more time and enough investment that somebody had to think pretty hard before giving the work a green light. Today, the cost and effort required to get to a working first version have dropped dramatically, and that will continue.
I’m all for that. I actually think companies should build more software themselves when what they’re building is closely tied to what makes their business special. If you have proprietary data, logic or knowledge that helps you price better, predict customer behavior, manage risk, make better recommendations or do something competitors can’t easily replicate, I’d absolutely consider owning that capability.
I have a much harder time with companies rebuilding software that already exists in abundance simply because version one looks cheap. That’s where I think a lot of the buy-versus-build math has gone off the rails, because we’re getting much better at calculating what it takes to create software while still doing a pretty bad job calculating what it takes to own that software once the excitement of building it is over.
And AI is about to make that problem much bigger.
When everyone can build, deciding what deserves to be built matters a lot more I read a Harvard Business Review article recently called AI Makes Building Easy. Choosing What to Build Is Harder, by J.P. Eggers, Sarah Ryan and Asha Dinesh. Their argument is worth paying attention to because AI is making sophisticated product creation accessible to far more people, while also speeding up work across software development, testing, documentation and other parts of building products. (Harvard Business Review)
I think there’s an important implication for large companies that goes beyond what happens to engineering teams. When creating software was expensive and slow, there was a natural brake on how much internal software an organization could create. Someone needed a budget, engineers had to be allocated, priorities had to be debated and, usually, a lot of people had to agree that whatever was being proposed was important enough to spend the money. AI starts taking that brake off.
A product manager can prototype an internal tool. An operations team can build something around a model and some internal data. A CX team can create its own analysis application. A contact center team can stand up a bot. An individual employee with some technical ability and access to the right tools can solve a problem that would have required a formal technology project a few years ago.
On one level, I love this because companies have spent decades making people wait months for relatively simple technology changes. Giving people the ability to solve more of their own problems is healthy.
But there’s another side to it that I think we’re going to discover pretty quickly. If every department can create software, every department can also create software that somebody eventually has to maintain.
The cost of saying yes to version one is collapsing. That should make companies more disciplined about what they build, not less disciplined, because you can create a tremendous amount of technical baggage before anyone realizes how much has accumulated.
The $50,000 build can become a $500,000 annual commitment pretty quickly Let’s do some rough math. I’m using illustrative numbers because compensation varies by company, geography and level, but I care more about the order of magnitude than whether somebody thinks a particular engineer costs $235,000 or $265,000 fully loaded.
Assume you have two really good engineers who each cost the company around $250,000 a year once you include salary, bonus, benefits, payroll costs and everything else that comes with employing them. Give them a month to build something and you’ve got roughly $42,000 of engineering cost.
Add some product-management time, front-end support, a data architect who helps get the data working properly, plus cloud and model costs while everyone develops and tests it, and landing somewhere around $50,000 to $60,000 for a strong first version isn’t hard.
Think about how attractive that looks next to a software vendor asking for $300,000, $500,000 or $1 million a year. I completely understand why a CFO, CIO or business leader looks at those numbers and starts wondering why the company wouldn’t build.
Now move forward six months.
The product is live and people rely on it. Maybe it analyzes customer feedback, gives contact center employees answers, creates surveys, automates some workflow, finds patterns in conversations or helps employees make decisions. Someone still has to own the code, and that person isn’t doing it for free simply because they already work for you.
Suppose one senior engineer spends half their time on the product over the course of the year. Using our $250,000 loaded-cost assumption, that’s $125,000. The second engineer gets pulled in about 25 percent of the time for releases, bug fixes, integrations and problems the first engineer can’t handle alone, adding another $62,500.
The product manager spends a quarter of their year dealing with requests, prioritization, changes, user problems and testing. At a loaded cost of around $220,000, that’s another $55,000. A front-end developer at a similar cost spending 20 percent of their time on it adds about $44,000.
Now bring in the data architect or senior data engineer because schemas change, pipelines break, definitions move and access rules get updated. At 20 percent of a $250,000 loaded cost, there’s another $50,000.
Then you have security, DevOps, QA, identity, monitoring and the shared technical work that nobody thinks much about when somebody is showing the prototype. Give that another $50,000 of annual capacity across different people and the ongoing people cost is roughly $386,500.
Nobody in that example is working full time on the product.
Now add the technology underneath it. Cloud infrastructure, databases, model usage, tokens, storage, logging, monitoring, evaluation tools, APIs, backups and whatever else is required to keep the application alive. A relatively modest $10,000 per month adds another $120,000 annually.
You’re now at roughly $506,500 a year to operate something that might have cost $50,000 or $60,000 to build.
That is the number I want in the buy-versus-build presentation.
Now multiply that across the company This is where the HBR argument made me think differently about the problem. If AI allows far more people to build, then we shouldn’t only be thinking about the cost of one internally built application. We should be thinking about the economics of an entire portfolio of applications that suddenly becomes much easier to create. (Harvard Business Review)
One $500,000 annual operating commitment isn’t necessarily a big problem for a large organization. Ten of them start to get interesting. Twenty definitely get interesting.
I’m not suggesting the math scales perfectly, because it doesn’t. Companies will share infrastructure, security teams, data platforms and engineering resources, so ten applications aren’t automatically ten times the cost of one. But the work doesn’t disappear either.
Every tool creates some combination of code, data connections, access rules, users, documentation, testing requirements, model dependencies and business logic that somebody has to understand. Every new internal tool creates another place where a company change can cause something to go wrong.
You can imagine how this happens without anyone ever approving a $5 million internal-software program.
Marketing builds two things.
CX builds three.
Operations builds four.
The contact center has a couple.
Finance creates one.
HR develops its own employee assistant.
Product teams create another five because they can now move without waiting on central technology.
Nobody did anything irresponsible. In fact, most of those teams probably made a perfectly reasonable local decision.
Then a CIO looks across the company two years later and discovers 30 internally built AI applications, 17 different ways people are storing knowledge, multiple model providers, duplicated tools solving similar problems, a pile of integrations and dozens of people spending some percentage of their week keeping all of it alive.
That’s where the economics change.
The individual build decision looked cheap. The collective operating model isn’t.
Tokens probably aren’t the cost I’d worry about most There’s a funny thing happening with AI where people obsess over model and token costs because they’re visible. Someone looks at the usage dashboard, sees $5,000 going out the door every month and starts asking whether prompts can be shortened or a cheaper model can handle some of the work.
Fine. Manage it.
I’d spend at least as much time looking at the humans wrapped around the software. If your model costs $5,000 a month, that’s $60,000 a year. One senior engineer spending 25 percent of their time maintaining the product can cost you about the same amount before you’ve counted anyone else.
I hear about Product and CX leaders spending hours every day reviewing AI-generated analysis because they don’t completely trust what they’re seeing. They’re finding hallucinations, fixing classifications and checking whether something is safe to put in front of senior management.
Do that across three or four senior people and the labor cost of checking the AI can easily become more material than the cost of running the AI. Yet the technology spend gets scrutinized while the directors spending seven hours a week checking its homework remain buried inside payroll.
That time isn’t free.
There’s also a point where you have to question the economics of building a system that requires highly paid people to continually inspect the work it was supposed to eliminate.
Survey software is a good example because nobody thinks it’s complicated I know companies that have built survey capabilities inside their own digital platforms, and I understand the logic. How hard can it be to put five questions in front of somebody after they complete an interaction?
The actual survey probably isn’t difficult to build. The problems show up after the company decides that this thing is now software it intends to keep.
Someone wants to change the questions. Another team wants new targeting logic. A business unit wants the survey somewhere else. Legal wants language changed. The CX team wants to run a test. Somebody decides survey responses should connect to transaction data or support history.
The internal development team can do every one of those things. The same people are also working on login problems, product releases, security issues and whatever senior management decided was urgent this quarter.
The survey change waits three weeks.
Nobody did anything wrong. The company built software that sits outside the core product, and then the core product quite reasonably got priority.
I don’t think that delay gets priced into many build-versus-buy models either.
AI creates a much messier version of the same problem Now take the survey example and make the application intelligent.
Say your team builds an internal AI tool that analyzes customer conversations. It ingests calls, survey comments, chats and operational data, and a leader can ask it questions about what customers are struggling with.
I love that idea. Companies should have far easier access to this kind of customer intelligence.
But think about everything sitting underneath it.
A customer hierarchy changes after a reorganization. Marketing renames a product. Operations changes how cases are classified. A data team updates what a field means. Someone changes ownership of a source. Legal changes which information can be used. An acquisition brings in a different data structure.
Then the technology changes. Your model gets updated. Prompts evolve. Knowledge gets replaced. An API changes. The team alters how information is retrieved or stored.
Pretty soon you have an octopus with 50 tentacles coming at you every week. One tentacle is data, one is security, another is policy, another is organizational hierarchy, another is permissions, and somebody somewhere just changed an integration nobody remembered the tool relied on.
The part that worries me most is that the software doesn’t always break when this happens.
Sometimes it keeps working.
The dashboard loads. The analysis appears. The AI responds in three seconds and sounds completely confident.
Nobody realizes the definition underneath it changed six weeks ago.
I’d almost rather have some systems crash. At least a crash gets someone’s attention.
The refund-policy problem is a perfect example I’ve heard versions of this from contact center leaders. The business changes a refund policy and people inside the company know about it, but the people responsible for the homegrown bot aren’t necessarily part of that process.
Maybe the documentation gets updated. Maybe it doesn’t. Maybe the new policy sits in a source the bot hasn’t ingested yet.
For the next few days, your AI confidently tells customers something that stopped being true.
The bot technically worked. The customer still got the wrong answer from your company, and that is the only part the customer cares about. Now you have additional calls, escalations, complaints, potentially credits or refunds you didn’t intend to provide, and an internal debate over whose responsibility it was to make sure the bot knew the policy changed.
Once your software starts speaking or acting on behalf of the company, maintaining it requires understanding what is changing across the company.
That’s a very different commitment than writing code.
The opportunity cost bothers me even more than the direct cost Everything I’ve described so far is still mostly an accounting discussion. We can estimate engineering capacity, product capacity, infrastructure, token consumption and other expenses, then come up with an annual number.
The harder question is what those people would have done instead.
I wouldn’t simply slap another “opportunity cost” number on top of the $500,000 because there’s a good chance we’d double-count some of the same resources. I’d force the business to compare the value of maintaining the internal software against the value of whatever isn’t getting done because those people are maintaining it.
If one of your strongest engineers spends half the year supporting an internal survey platform, that engineer has half as much time available for customer-facing products.
If a product manager spends 25 percent of their year owning an internal AI application, that’s roughly three months of capacity that isn’t going somewhere else.
If a senior data architect is spending a day every week keeping an internal customer-insight tool fed correctly, then something else on the data roadmap is getting less of that person.
Good technical people don’t have a lot of unused time sitting around waiting for internal tools to maintain.
So when somebody says, “We already have the people,” I’d challenge that pretty aggressively.
Yes, you already employ them.
What are you willing to stop asking them to do?
That answer belongs in the decision.
Vendors aren’t getting a free pass from me I can already imagine a few software vendors using this argument in their next sales deck, so let me ruin that part for them.
A lot of enterprise software is horribly overpriced.
The packaging can be ridiculous. Companies buy 40 capabilities because they need six. Professional-services bills pile up. Integrations that looked simple during the sales process somehow become six-month projects.
Then renewal time arrives and everyone acts like an 8 percent price increase is a law of physics.
I’ve also seen companies customize vendor platforms so heavily that leaving them becomes almost impossible. The data sits there, employees are trained on it, workflows have been rebuilt around it and a web of integrations makes moving to something else a significant undertaking.
That’s a form of technical debt too.
Some of the AI software being sold right now should get even more scrutiny. If a good internal team can reproduce most of the value in a month using a general-purpose model and a few APIs, somebody needs to explain why the vendor deserves several hundred thousand dollars a year.
Buying software badly can be just as dumb as building it badly.
The point is to compare the real economics of both choices.
Where I draw the line For me, the closer the capability gets to what makes your company valuable, the stronger the case for owning it.
If a retailer has proprietary intelligence around customer behavior that materially improves merchandising, recommendations or pricing, I’d seriously consider building around it.
If a financial company has better risk intelligence because of its unique data and expertise, I’d be reluctant to outsource all of that logic.
If a marketplace lives or dies based on how well it matches buyers and sellers, I’d expect matching technology to be a serious internal capability.
Those systems deserve people, money and attention because improving the software improves the business.
I become much more skeptical when the company is rebuilding commodity functionality.
Surveys, basic workflow, scheduling, ticketing, standard reporting and common administrative capabilities don’t suddenly become strategic because your own engineers wrote the code. That doesn’t mean you should buy an overpriced platform. It means the bar for building should be higher than “we can do it for less than the vendor wants.”
Tell me why owning the capability makes the business better three years from now.
If it doesn’t, I’d probably rather have your best people working somewhere else.
Put year three on the spreadsheet, and add the other 20 tools while you’re there If I were reviewing one of these decisions today, I’d spend surprisingly little time debating whether the team can build the software.
I’d assume they can.
I’d want to see who owns it three years from now, how much engineering capacity it requires, how much product and data work it consumes, what we’re spending on models, cloud, security and monitoring, and what happens when the systems and policies around it inevitably change.
Then I’d want another view.
Show me every other internally built product we already own.
Show me what each one costs.
Show me where they overlap.
Show me how many different teams are maintaining their own little versions of similar capabilities.
Show me what happens if AI makes it possible for us to create twice as many next year.
That’s the part of the HBR argument I think deserves much more attention inside established companies. As execution becomes easier, prioritization becomes more valuable. The ability to build more things doesn’t automatically mean the business benefits from owning more things. (Harvard Business Review)
I think AI will push companies to build far more software themselves over the next decade, and much of that will be good. Smaller teams will create incredibly specific applications around company data and knowledge that would never have been economical before.
We’re also going to create a massive amount of internal software nobody really wants to own.
There will be bots sitting on old policies, analysis tools using definitions that changed months earlier, internal applications built by employees who moved on, and AI outputs being manually checked by people whose salaries never appeared in the original ROI calculation. The real buy-versus-build question has changed because building itself is no longer the constraint it once was.
If the software helps make your company meaningfully better at the thing customers hire you to do, build it and fund it properly. Put great people around it, accept the long-term cost, and treat it as a product rather than a project.
If it doesn’t, I’d want somebody to show me the year-three math, the opportunity cost and the rest of the internal software portfolio before the first engineer starts writing code.
AI is making it remarkably easy to create software. That makes deciding what deserves years of your company’s money, attention and best people a much bigger part of the job.
