LLMs Make Development Cheaper, but Not Always the Process Itself

One of the things we at Detix Services see more and more often in companies - internal tools have become very easy to build.

Before, if a team wanted to build its own reporting system, its own system for running builds and tests, a test case management tool, or some internal portal, it was already a separate project.
You had to estimate the task, assign people, budget, and time. And the cost of development alone forced a simple question: do we really need to build this?

With LLMs, this barrier has become much lower.

Now it often feels like: “There is nothing complicated there. We can build our own in a couple of days.” And the most interesting part - teams often really do it.
The first version can look great. A nice dashboard with statistics. Exactly the filters the team needs. Nothing extra. Everything works just the way you wanted. At this moment, your own solution can easily look even better than a ready-made product.

But there is one problem.

LLMs have made it much cheaper to create software. But the cost of its later life has not dropped nearly as much.

After the tool is created, it needs support. Bugs appear in it. It needs updates. It needs servers and other infrastructure. Security questions come up. You need to manage access rights, update libraries, help users, and train new people.
And all of this is engineers' time. Not tokens. People.
And even one small internal tool already creates one more system the company has to be responsible for.
For example, a team decides to build its own reporting system for automated tests.
At first, everything looks simple. Take the test results, put them in a database, build a page with statistics. With an LLM, the first version really can be built very fast.

But building fast does not mean building well.

Problems can appear even before the tool starts to scale. How is the data stored? Who has access to it? Are there security issues? What happens if the database or the server goes down? Who watches for errors? Who updates the dependencies? How stable is the solution at all? Does it add new instability to the tests themselves?

Because if an internal tool starts breaking test runs, giving unstable results, or creating false failures, it is no longer just a technical inconvenience. It directly affects delivery speed, test quality, and, just as important, the team's trust in automation.
If people stop trusting test results, they start checking them by hand, ignoring failures, or re-running tests several times. At that moment, the tool that was supposed to speed up the process actually starts to slow it down.

And then a second team comes.

They need a different format of results. A third team wants to see six months of history. A fourth one needs different access levels. Management wants overall statistics across all projects. The security team wants single sign-on through the corporate account.
And then it turns out that one team runs 5 thousand tests, and another one runs 500 thousand. And here the scaling problems begin.

A solution that worked perfectly for one team may not work at all for twenty. Problems appear with speed, database load, backups, queues, monitoring, and recovery after failures.
And a year later, the “small internal tool” has actually turned into a separate product. Only without a separate team that takes care of this product.
The same can happen with your own systems for running tests, managing test cases, deployment, monitoring, or other internal services.

There is one more, less obvious risk. Your own tool can make the process itself less effective.
At first it feels like: “We built everything exactly for ourselves. Now it will be faster.”

But after some time, the process starts to adjust to the limits of the tool itself. People change the way they work not because it is better, but because that is simply how the system works.
And even more important - the tool itself could have been built for the wrong process from the very beginning.

This is especially visible in test automation. You can very quickly automate a complex process of running tests, collecting results, re-running them, doing manual analysis, and building reports. And you get a beautiful system that does all of this automatically.

But if the process itself was badly designed, we did not solve the problem. We just automated a bad process very well.

And then the tool locks this approach in even more, because changing the process now means changing the code, the data, the reports, and the team's habits.
What looked “cool and convenient” at the start may turn out, a year later, to be a worse solution than if this tool had never existed at all.
This does not mean that companies should not build their own tools. Sometimes building your own solution really is the right choice, better than buying a ready-made one.

But now, when creating software has become much easier, it is worth looking even more carefully not only at the cost of development, but also at the cost of the whole process around it.
Because the question is no longer: “Can we build this?” With LLMs, the answer will very often be: yes.
The much more important question is: “Will this tool make the whole process simpler and cheaper a year from now?”