Picture a company like yours. Eighteen months ago the leadership team looked at three proposals for a platform that would show sales, margin, backlog, service issues, and cash in one place. Each came with a license, an implementation partner, and a multi-year commitment, and each price had a comma in a place nobody liked. The team could not agree on scope, so it waited. Nobody got credit for waiting. It felt like indecision.
Now picture the same team this quarter. One developer, working with an AI assistant and an operations leader who knows where the numbers live, has put a single view of the business in front of the Monday meeting. It pulls from the accounting system, the CRM, the service desk, and a couple of spreadsheets that were never supposed to be systems. It took weeks, not a year. It is not perfect, and a few people argue about the definitions. But the company sees its own data in one place for the first time.
If you held off on licensing big enterprise software while AI changed the economics of building, you may be sitting on a better option than the one you passed up.
If you held off on licensing big enterprise software while AI changed the economics of building, you may be sitting on a better option than the one you passed up. This article is about what that option is, what it takes, what can go wrong, and how to find out whether it is real for your company before you spend much.
The Reward for Waiting
Three things moved while you were deciding. Building a custom solution got cheaper, because AI now writes much of the connecting code, the data transformations, the tests, and the first draft of the screens that used to eat a team’s calendar. The cost of staying flexible got more valuable, because a multi-year commitment signed on a 2024 architecture is a commitment to a way of working that is already changing. We wrote about the tradeoffs buried inside long commitments in Want to Direct the AI Dividend? You Must See the Tradeoffs Clearly. And the alternative to a big platform stopped being a spreadsheet and a prayer.
We want to be careful about how strongly we say this. Our judgment is that for a mid-market company with a defined set of systems, a custom single view of the business now costs a small fraction of what comparable enterprise software would have cost just two years ago. That is our argument, based on how the work is now done, and it is not a published finding. We have not found a public benchmark that measures it, and we will say plainly what evidence does exist further down. The right way to treat our claim is as a hypothesis worth a bounded test.
What a Single Pane of Glass Is, in Plain Terms
The phrase is old, and it often means a dashboard. A useful one is more than that. It is one place where the numbers from your operating systems arrive on a schedule, are cleaned, are tied to definitions your leadership team has agreed to in writing, and can be traced back to their source when someone asks where a figure came from.
Under the screen sit a few layers. Connectors pull data out of the systems that hold it. A store keeps a clean copy so the operating systems are not slowed down by reporting. A set of definitions says what counts as a customer, a booking, a margin point, or a late order. Views turn that into pages and alerts for the people who use them. Access rules decide who sees what. None of this is new, and every enterprise platform you were quoted contains all of it. What changed is how much of the building can now be done by an AI assistant under a person’s direction.
What AI Does and What People Still Do
Here is the division of labor that works. AI is very good at the repetitive middle of the work: writing a connector to a system with a documented interface, converting messy fields into consistent ones, drafting tests, generating documentation, and producing the first version of a chart or a report page. It is fast, it does not get bored, and it will happily rewrite something four times.
A person owns it on Tuesday morning when a number looks wrong.
People do the parts that decide whether the thing is trustworthy. A person decides what the company should measure in the first place. A person writes down the definitions and settles the argument about them. A person chooses the architecture, reviews what the assistant produced, and decides what the system is allowed to touch. A person owns it on Tuesday morning when a number looks wrong.
That is why the honest requirement is at least one human programmer, and sometimes several. One experienced developer can carry a handful of systems with well-behaved interfaces. A company with many systems, regulated data, or near-real-time needs will want a small team, plus someone who understands security. The assistant changes how much each person can do. It does not remove the need for the person.
Builders appear to know this. In a late-2025 survey of 817 builders run by Retool, a software vendor, only 8 percent said they use AI-written code without changes, while 44 percent said they test it thoroughly and 32 percent review it briefly. That is a vendor survey with an unstated company-size mix, so we read it as a signal about habits and not as a measure of quality.
What the Evidence Says About the Cost Shift
We looked for hard numbers on how much cheaper custom builds have become compared with licensed platforms, and we did not find a trustworthy public one. What exists points in a direction, and every piece has limits.
The Retool survey, published in February 2026, found that 35 percent of respondents said they had already replaced at least one purchased tool with a custom build, and 78 percent expected to build more in 2026. It listed business intelligence tools among the categories at risk of replacement, at 29 percent, without stating the base for that figure. Retool sells a platform for building internal tools, and its report words some bases inconsistently, switching between teams, builders, and organizations. Treat it as evidence that buyers are trying this, which is a weaker claim than evidence that it is cheaper.
On productivity, the research is honestly mixed. METR, a research nonprofit, ran a randomized trial in early 2025 with 16 experienced open-source developers and 246 real tasks, and found that the developers took 19 percent longer with AI tools than without them, while believing they had been faster. In February 2026 METR said its newer data could no longer measure the effect reliably, partly because many developers declined to work without AI, and said it believes developers are likely more sped up now than in early 2025 without being able to say by how much. The short version is that nobody has a clean number. A company that expects a fixed percentage is making a bet, not reading a fact.
That is the case for a pilot with your own numbers. A comparison that a CEO can trust has two columns. On the licensing side: the license, the implementation partner, the internal administrator, the change requests that cost extra, and the price of leaving. On the building side: developer time, AI usage fees, hosting, a security review, and the maintenance that every system needs. Get your own quotes for the first column. Ask a developer for an estimate of the second. The gap, if there is one, will be yours and not ours.
What Can Go Wrong
Speed creates its own risks, and the research on AI-written code deserves a straight reading.
A preprint from researchers at several universities, last revised in October 2026, analyzed more than 300,000 commits written by five AI coding assistants across 6,299 GitHub repositories. It found that between 7.5 and 14.8 percent of each assistant’s commits introduced at least one issue flagged by static analysis, most of them code smells, and that 22.7 percent of the issues it tracked were still present in the latest version of the repository. That is a preprint, and a static analyzer flags problems that are not always bugs. It still says that AI-written code can leave a maintenance bill behind if nobody pays attention.
The Software Improvement Group, in its State of Software 2026 research as reported in June 2026, said that AI-generated code showed roughly twice as many security-risk violations as human-written code across its benchmark of 30,000 enterprise systems. We read the news coverage and not the report, and the coverage does not explain how AI-written code was identified, so we would not lean on the exact ratio. The more useful finding is the one SIG states in words: AI magnifies the standards and controls you already have. A company with weak review will get weak software faster.
There is also a quieter risk, which is the one you may already have. In the Retool survey, 60 percent of builders said they had built something outside IT oversight in the past year, and about half of those who did built custom dashboards. If you do nothing, your single pane of glass is being built anyway, by several people, in several places, with no shared definitions. A sponsored, owned project is safer than the one that is already happening.
Guardrails That Make the Shortcut Safe
None of this is exotic, and a mid-market company can do all of it. Name one accountable owner on the business side, a person with authority over the definitions. Write the definitions down before building the screens, because the arguments are cheaper at that stage. Start read-only, so the new system looks at your operating systems and cannot change them. Give the system its own identity and the least access that lets it work, the same principle we covered in Taming the Agentic AI Genie. Require tests and a human review of every change before it goes live. Keep the code and the documentation in a repository your company owns. And decide, at the start, how you would walk away.
If you cannot explain your system to a new developer, you are renting it.
That last point comes from an unexpected place. In September 2026, Gartner predicted that by 2028, 70 percent of enterprises will abandon agentic AI built through vendor forward-deployed engineering, because of rising costs and an inability to evolve it independently. The release states no survey behind the prediction, and it concerns vendors who embed engineers to build for you, which is not the same as what we describe. But its advice applies to anyone who brings in outside builders: set the intellectual property rights, the knowledge transfer, and the exit plan in the contract before the work starts, and execute the exit plan instead of extending the engagement because your people are not ready. The point of building is to end up owning something. If you cannot explain your system to a new developer, you are renting it.
When You Should Still Buy
Custom does not mean everything. Your accounting system, payroll, and other systems of record are a poor place to experiment. They carry regulation, audit trails, and years of edge cases that someone else has already paid to learn. The sensible shape is to buy or keep the systems of record and build the single view on top of them. A dashboard that reads your ERP is a fraction of the risk of a replacement ERP.
Buy also when a commodity product does exactly what you need and your people will use it as is, when you cannot staff or contract a developer you trust, or when your data is so regulated that the review burden swamps the savings. Our test is simple. If the thing you want is mostly a view of your own data, in your own definitions, then you are a good candidate to build. If the thing you want is a transaction engine that other parties rely on, you are probably not.
What This Will Not Do
A custom view will not fix a company that does not agree on its own numbers; it will show the disagreement faster. It will not remove the need for a person who understands the data. It will not stay good without maintenance, and the maintenance is a real cost that belongs in your comparison. Our cost claim is a judgment and not a benchmark, and the evidence we cited has limits: a vendor survey, a preprint, news coverage of a benchmark, a research trial whose authors say its newest data is unreliable, and a Gartner prediction with no stated basis. If your systems are few and your data is clean, you may not need any of this.
How to Start in 90 Days
Pick one decision your leadership team makes every week with incomplete data, and build the view for that decision alone. Choose three to five systems at most. Assign one developer you trust and one business owner. In the first 30 days, agree on the definitions and connect the sources in read-only mode. By day 60, put the first version in front of the weekly meeting; our article on including tech in the weekly meeting describes a short list of metrics that work well on that page. By day 90, compare the real cost and the real usefulness against the licensing quotes, and decide whether to extend, buy, or stop.
Our 2026 Mid-market Analytics Maturity Survey is a useful way to gauge how ready your data is. If you want an outside read before you commit, an independent assessment will tell you where your data lives, how ready it is, and whether this is a good place to start. Innovation Vista keeps a bench of more than 450 former CIOs, CTOs, and CISOs, so a developer-led build can have an experienced reviewer who has seen these projects go well and badly. Waiting may have been the right call. Whether it pays off is up to what you do next.
