IT Consulting: From Business Needs to Better Technology Decisions

This article is based on the thoughts of Gábor T., senior business consultant.

How Does Software Consulting Turn Business Needs into a Working System?

Most technology decisions do not start where people tend to assume. By the time an organisation reaches the point of wanting to build or improve something, the business strategy and the digital direction are usually already in place. The hard question comes after that: which applications, in which architecture, and with which technology make sense to build. That decision shapes the technological reality of the next 5–10 years, and a poor choice can generate significant extra costs for years to come.

Classical IT consulting rarely gives a meaningful answer to that question. A strategy presentation, a market analysis, and a process diagram do not, on their own, explain how a plan becomes working software. That requires a consultant who understands code, architecture, and how a business problem maps onto technology. This is the distinction between software consulting and classical management consulting.

The Symptom Is Rarely the Same as the Problem

Clients rarely arrive with a perfectly formulated problem. Most of the time they describe symptoms, and the real cause only emerges during the discovery phase. A simple example illustrates the difference: if someone says “our system is slow,” that is still a symptom. If they say “dispatchers cannot see drivers’ real-time positions, so they coordinate by phone, which takes an average of four minutes per call,” that is closer to the cause and immediately opens up a space for technical solutions.

Clients naturally tend to present the symptom as the problem and to steer the conversation toward the solution they have already formed in their own minds. One of the most important parts of the business analyst’s work is to notice this steering and approach the problem from the outside in a structured way. The truth is that the fate of most projects is decided here, not during development.

Business Process Optimisation: Software, Workflow, and Operational Efficiency

A manufacturing company with 80 employees came to us with a complaint about slow quote preparation. Every quote was built in Excel, circulated by email for approval, and the average turnaround was four to six working days. At first glance this looked like a typical digitalisation task: a manual process that needed to be automated.

During the requirements discovery, however, it became clear that the problem was not people being slow. There was no structured quoting process at all, the pricing logic lived in colleagues’ heads, and the approval levels were undefined. Building a faster interface to replace Excel would have eased the symptom while leaving the cause intact. A year later the same company would have come back with the same complaint, only this time with a more expensive piece of software behind it. The solution turned out to be a specification for a CPQ (Configure-Price-Quote) system that captures pricing logic in a rules engine and automates the approval workflow.

This kind of work is what business process optimisation should actually mean: it begins with a genuine understanding of the process, not with purchasing software. On a local government project, the same logic revealed that 70 percent of complaints arrived by phone because of a lack of status tracking. The real bottleneck, however, was in the internal approval process, where cases sat in a waiting status for an average of eight days. The digital transformation started there as an internal process change, and the customer-facing interface was added only in a second phase.

Three Questions That Come Up in Almost Every Software Project: Architecture, Build or Buy, and Integration

Three topics surface in almost every project during the discovery work, and each is worth examining separately.

1. The first is the architectural choice. Monolith or microservices, cloud-native or on-premise, which stack fits the team and the problem. These decisions define the next 5–10 years of the project, and in my experience, jumping to microservices is overkill in most cases in the Hungarian mid-market context. A fast-growing fintech startup, for example, wanted to rewrite everything in a microservices architecture, while 80 percent of the performance problems came from a single poorly optimised database layer. The recommendation was a modular monolith with database optimisation, which solved the problem at a tenth of the cost.

2. The second is the Build or Buy question. Should we build custom software or buy a ready-made solution? The answer is almost never black and white. A complex system usually has components where a market solution is the right choice and components where custom development is the only viable path. A Build or Buy analysis breaks the system down into components and evaluates each one separately, recommending market solutions for standard parts and custom development for the parts that carry competitive advantage.

3. The third is integration and legacy systems. At a logistics company with 200 employees, dispatchers spent two to three hours every day copying data by hand between the CRM, the dispatch management system, and the invoicing tool. The solution was an API gateway-based integration layer that connects the open systems directly and pulls data from the 15-year-old closed CRM via scheduled exports until the CRM replacement takes place.

The Real Cost of Architectural Decisions

An IT consultant’s work delivers genuine value when, alongside understanding the problem, it also addresses the technological dimension of the solution. Software architecture is the structural foundation of a system and determines its performance, scalability, maintainability, and development speed for the years ahead. Fixing a bad architectural decision after the fact is one of the most expensive operations in software development.

This is precisely the practical side of IT system design: applying proven patterns (solid, clean architecture, hexagonal architecture, domain-driven design) to the specific problem at hand, not because they look good on a slide.

When choosing technology, we look at the problem, the team, and long-term sustainability rather than at the current hype. We examine the maturity of the technology, the team’s competencies, the licensing model, integration options, and vendor lock-in risk. These questions form the backbone of a long-term IT strategy.

At the infrastructure level, the focus falls on the choice between cloud, on-premise, and hybrid models, CI/CD pipeline design, monitoring, and cost optimisation. IT security consulting considerations are built organically into all of these areas, because securing a system after the fact is generally considerably more expensive than designing it to be secure from the start.

Compliance requirements (GDPR, industry regulations, audit requirements) create technological constraints. Systems must demonstrably operate in the way the regulation requires. This is where technology consulting, IT consulting and audit considerations, and business analysis are most closely connected.

Software Consulting and IT Advisory in Practice

Every project has a dedicated consultant who has a technical background but also understands the business context. This person is the bridge between the client and the development team: they communicate with empathy, document with precision, and work to ensure that both sides mean the same thing by the same term.

The value of system design and the system designer’s work depends heavily on whether the steps that led to each decision can be reviewed later, which is why every meeting, decision, and change is documented. I know this initially feels like an administrative burden, but three or four months after a project launches, nobody remembers why we chose that particular technology.

Consulting is not one-way communication. We actively involve the client in the discovery process and in decision-making, with regular approval checkpoints that ensure the work does not drift away from the original business objectives.

In most organisations, problems and needs change continuously. Growth, expansion into a new market, or a regulatory change all generate consulting needs. In those moments, the value of a trust-based partnership becomes clear: the client naturally turns back to the same team. The shared work has built a common vocabulary and a shared understanding of the problem that does not need to be rebuilt from scratch each time.