The Most Expensive Part of an IT Project Is the Questions Nobody Asked [INTERVIEW]

It has never been easier to build something yourself. A prototype can be ready in a day, without writing a single line of code, and more and more business owners are rightly taking advantage of that. But in IT projects, the most expensive thing is often not what was built badly – it's what nobody asked about at the start. Why can quotes for the same project vary by several hundred percent? Why can't security be "added" at the end? And what costs only show up once a system goes live? Michał Pierzchlewicz, co-founder and CTO of TeaCode, walks us through it.

‍

Why do companies commission custom software when the market is full of off-the-shelf solutions?

Michał: There are many reasons, but the most interesting cases for me are those where the existing tool starts holding the company back. It may work perfectly well from a technical standpoint, yet still prevent the business from taking its next step.

We work with a sports federation in the United States that has hundreds of thousands of members. They were using a large, off-the-shelf platform. They wanted to change how they serve their members and how they access and use their data, but the vendor had no plans to develop new features for a single client. They had a choice: accept the status quo, or build their own system and have control over how it works.

For a large Polish catering company, the reason was operational security. Their entire sales process ran on a third-party system. That made sense early on, but as the company grew, relying on an outside provider for such a critical process became too big a risk.

Reputation matters too. A US training company asked us to rebuild its mobile app because poor app store ratings were hurting the whole brand.

When does it make sense to buy a ready-made solution, and when should you build your own?

In my view, that line has shifted a lot. Building your own solution is still an investment that has to pay off, but today it can be done faster and cheaper. I believe it makes the most sense to invest in your own solutions wherever your business meets the customer. That’s where you shape the experience that can actually set you apart. There's no point reinventing the wheel with standard tools like accounting systems.

But customer touchpoints aren't just the website and the app. We have an e-commerce client in Germany that does custom printing. Its customers designed their prints in an app, but the process still required a graphic designer: they'd open the file, fix it and send it back – over and over again. That was an operational cost, but above all it was a bottleneck: there was no way to shorten turnaround times or expand the offering without growing the team. We built a new configurator and internal tools that cut manual work to a minimum. As a result, the designers gained time to create new designs, and the company was able to expand its range.

Is it artificial intelligence that has made building software cheaper?

AI is the cherry on top. What really matters are two changes we've seen in the market and in technology over the past few years.

The first is team costs. During the COVID, salary increases of around fifty percent were standard and could eat up a project's entire margin. Today the market has stabilized.

The second is the maturity of the technology. For years there were framework wars, and something new appeared every few months. Over the past two or three years, that has calmed down.

It's only on that foundation that AI starts delivering real results – on two conditions: that it's used by people who know what they're doing, and that we're working with technologies the models were trained on. As soon as you move to a niche technology, the hallucinations start, the model suggests solutions from several versions ago, and the generated code simply doesn't work.

So can you build something yourself today, without a technical background?

I don't see a problem with someone building a simple solution on their own and using it. A friend of mine who runs a chain of bakeries needed a tool to track staff check-ins. I advised him to try building it himself. It worked – the system is up and running. Even without an IT background, you can build something that delivers real value.

The question isn't whether you can built something yourself, but how complex the system is and how much risk comes with it. The more features and data, the more complicated the web of access permissions, the more extensive the infrastructure – the easier it is to fall into a loop where you add one thing and break another.

Then there's security. We often get requests along the lines of: "I've built a system, it just needs the security fixed." But above a certain level of complexity, patching the holes isn't enough. It often turns out there simply are no foundations, and the system has to be rebuilt from scratch.

As a prototype, though, a solution like that is very valuable. The client can show us what they want to achieve instead of trying to describe everything. We work this way ourselves on larger projects. When people can see something and click through it, it's easier for them to say what they need and what should work differently. Things they hadn't thought of before come up too. Only then do we build the actual system – on the right architecture.

Say you need outside expertise. How should you prepare for conversations with vendors to get comparable offers?

There’s a trend, often encouraged by AI itself, toward writing an extensive request for proposal with detailed requirements, sometimes even data structures. That creates a lot of noise. We receive a ready-made solution concept, but almost nothing about the problem it's supposed to solve. And that's the most important part.

I understand where this comes from: to get comparable offers, you have to send everyone the same, equally defined scope of work. The problem is that a list of requirements says little about what’s specific to the business or about how the company works. We end up pricing a predefined concept without knowing whether it reflects the company's real needs.

That's why we start by asking about the problem the client wants to solve. Then it becomes clear which parts of the specification are actually needed and what's missing from it. Skip this step, and it often ends in a significant budget overrun.

We had a client, a small Polish company, that wanted to rebuild its portal. They came with a business problem and got three very different quotes: a very low one, ours somewhere in the middle, and a very high one. Each company approached the same problem differently. The cheapest one underestimated its scale; the most expensive one came from a large organization working within a corporate structure. The client did the right thing by coming with a problem. The catch was that offers built on such different assumptions can’t be compared side by side.

And how do you know you've found the right partner?

I'd look for a company that specializes in the area in question. Then you bring them a problem, and the other side knows what to ask and what's needed to actually solve it – instead of learning your industry on your dime.

I'd also pay attention to who I'm talking to from the very beginning. We moved away from the model where salespeople led the initial conversations. For us, what matters is that someone asks the right questions straight away and pushes back on what’s unrealistic or hard to deliver, based on what we’re seeing in our current projects. It's a dynamic industry, so you have to stay hands-on and keep learning.

What most often goes wrong when building custom software?

The biggest risk is usually what you don't know – what you didn't foresee and didn't plan for.

We once spoke with a company that had commissioned a 3D product configurator from another vendor. The budget had ran out, and although the tool worked, the back-office system used to prepare models, materials and options wasn't suited to the employees who were supposed to use it. Fixing that part could have meant a second project with a similar budget. So the question came up: whose fault was it – the people who prepared the specification, or the people who delivered the project?

I try to prevent situations like this. I start by understanding how the company works and what its processes are. I involve everyone the project affects as early as possible.

At a minimum, the client needs one person who acts as the point of contact and has access to knowledge inside the company. They don't need to know IT, but they do need to know who to talk to and about what. Without that, the risk grows.

Say the system is already live. What next?

That's not the end. There's a recurring cost of maintaining the infrastructure. With a small, self-contained system, after the first few months of stabilization and minor fixes, ongoing maintenance may come down to updating libraries and responding to security alerts. Larger projects, or those under continuous development, often require someone to maintain them part-time, sometimes even a small team.

As AI gets better at writing code, how will the developer's role change?

Expert knowledge will still be highly valuable. AI is good at generating repetitive code, but it works on patterns and probability. It can suggest a solution that works statistically, but it won't necessarily be the best one in your case.

Expertise means, among other things, anticipating the consequences of decisions: what will happen if we implement something a certain way, how it will affect the user experience, and whether it will actually solve the business problem. The focus is shifting from writing code to understanding context and making the right decisions. AI doesn't yet replace people in uncovering needs the client hasn't put into words, or in judging the consequences of decisions in a specific business context.

That doesn’t mean we should be afraid of these tools. We should use them and keep up with how they evolve – but check their output rather than trust it blindly. AI on its own is often still not enough to solve a business problem. That's why human involvement remains so important.

Thank you for the conversation.

‍

Sponsored by TeaCode. Originally published in Polish on money.pl, September 28, 2026.