First, Set the Hype Aside
For the past few years the same sentence has been echoing in nearly every boardroom: "We need to get into AI." The trouble is that this is not a goal — it is a feeling. Like "we should digitalize" or "we should move to the cloud," it is a slogan that means nothing until you fill it in. AI is not a destination; it is a tool for doing a specific job cheaper, faster or better. The moment you put the tool in place of the goal, you start inventing a problem just to fit the solution you already bought.
The danger of hype is not only wasted budget. The real danger is that expectation runs ahead of reality. There is a chasm between a technology working flawlessly in a pitch deck and that same technology working with your actual data, your actual customers, your actual regulations. Projects that begin with the belief that "AI solves everything" curdle into disappointment at the first real-world friction — and often cast a shadow over the whole subject.
The aim of this article is not to talk you out of AI. Quite the opposite: used well, it is a powerful tool that genuinely works and produces measurable value. The aim is to pull you away from the shine in the showroom and invite you to look from where an engineer — or a founder who takes the business seriously — stands. The questions asked from there are always the same: Which problem? How much money? How much risk? And how will we measure the result?
Start With a Problem, Not a Technology
A good AI project almost never starts with the question "where can we use AI?" It starts with "what tires us out the most, what costs us the most, what are we always late doing?" Put the technology aside and list your company's most boring, most repetitive, most human-hour-devouring tasks. That is exactly where AI shines today: high-volume, patterned work built on recognizing linguistic or visual patterns — work that, taken one item at a time, is not mentally taxing.
It pays to be concrete. "Improve the customer experience" is not a problem; it is a wish. But "our support team spends four hours a day sorting sixty percent of incoming emails into three typical categories" — that is a problem. Measurable, bounded, with a clear definition of success. A good candidate problem usually has three traits: it recurs often, you do not wait months to see the outcome, and a human spots a wrong answer the moment they look at it.
One warning: the most attractive problem is not always the right starting point. It is tempting to pick the company's most critical, most visible process as your first test subject — but it is risky. For your first project, choose somewhere the world will not end if it goes wrong, yet where everyone will clearly see the benefit if it goes right. Trust is built with small, concrete wins, not big, vague promises.
Start Small: a Pilot, Not a Revolution
After choosing a problem, the most common mistake is to immediately think big. "If we're going to do it, let's transform the whole department" is the approach that burns money and reputation the fastest. The right method is a narrow pilot: a single process, a single team, a clear window of a few weeks, and a success threshold defined up front. The point of a pilot is not to change the world but to answer one question: "Does this actually work, and by how much?"
The hidden benefit of a good pilot is less the result it produces than what it teaches you. During a pilot you learn how messy your data really is, how users route around the tool, where the model stumbles, and where the real savings are hiding. That knowledge is worth more than the shiniest business plan on paper, because it is real. Even a failed pilot is a cheap lesson — cheap because you learned it before pouring a seven-figure investment in the wrong direction.
When designing the pilot, adopt the "human in the loop" principle from the outset. The system produces suggestions, but for a while a human makes or approves the final decision. This both reduces risk and lets you measure the model's true hit rate. Instead of putting AI behind the wheel overnight, seat it in the passenger seat first; as trust grows, you hand over responsibility gradually.
If You Can't Measure It, You Can't Know It Works
The most insidious trap in AI projects is the feeling that something "looks cool." The demo is impressive, everyone nods, the project gets a green light — but no one can say in numbers what we actually improved. The only way to prevent this is to write down the success metric and the current state (the baseline) before a single line of code is written. A sentence like "this task currently takes forty minutes on average with an eight percent error rate" is the only honest ground on which to later claim "it got better."
The right metric is usually a business metric, not a technical one. The model's accuracy is interesting, but it is not what the boss cares about. The boss cares about hours saved, errors reduced, response time shortened, conversion rate lifted, or returns brought down. Where possible, use a control group: run part of the work the old way and part with the new system, then set the two side by side. Otherwise you cannot tell genuine improvement from a seasonal swing or some other change that happened to ship that month.
Measurement is also a discipline of honesty. Being able to admit when a pilot's numbers do not hold up is half the battle. A threshold defined in advance ("if it doesn't cut the error rate by at least a third, we don't continue") protects you both from fooling yourself and from the endless "let's give it one more week" loop. Good teams hear bad news early and clearly; bad teams postpone it until the budget runs out.
Build vs Buy: an Honest Decision Tree
At some point the question arrives: do we buy an off-the-shelf product, or build our own? The general rule is simple: if your need is the same as your competitors', buy. For tasks like reading invoices, summarizing meetings, or answering customer questions, there are mature, cheap, continuously updated products. Building these from scratch is like generating your own electricity — possible, but sensible for almost no business. If your competitive advantage does not come from that task, do not build it yourself.
Building (or commissioning a custom build) makes sense in three situations: when your business is genuinely unique and ready-made products cannot capture your nuance; when your data is so sensitive or regulated that it cannot leave the building; or when this capability is precisely what sets you apart from competitors. In these cases a generic tool does the job halfway and traps you on the same baseline as everyone else. Most needs of most companies fall on the 'buy' side; the core that truly demands 'build' is small but valuable.
The third and often smartest path is between the two: take the base intelligence from an external model, but wrap it in your own data, your own rules, and your own domain knowledge. That is our approach in building İçtiHub: we take the general capability of language from strong foundation models, and on top of it we build the legislation, case law, and verification layer of Turkish law ourselves. The real value lies not in the model itself but in that thin yet laborious layer that makes it reliable, domain-specific and verifiable. Seeing this distinction also clarifies where to put your budget.
Data Readiness: Boring but Decisive
Most AI projects fail not at the model but at the data. There is an old engineering saying: "garbage in, garbage out." Even the most powerful model cannot shine on data that is messy, incomplete, contradictory, or sitting in ten different places in ten different formats. Most companies have far less 'ready' data than they assume, because data was kept for years for humans, not machines. This is why a surprisingly large share of real projects goes not into building the model but into gathering and cleaning the data.
The good news is that this cleanup produces value on its own. Organizing, labeling and consolidating your data into a single source of truth helps your business even if AI never arrives — reporting improves, errors drop, institutional memory strengthens. So it is healthier to see data readiness not as AI's tedious precondition but as an investment that pays off in its own right. What's more, this work shows you, in the most honest way, which AI idea is actually realistic.
A warning comes from the privacy and compliance side too. If you work with customer data, personal data, or regulated information, clarifying data-protection law (in Turkey, the KVKK) and sector rules before feeding any of it to a model is not negotiable. Where the data goes, where it is stored, who can access it — all of this must be designed from the start. This is not only a legal obligation; it is the foundation of your customers' trust, and it should be part of the architecture, not a patch bolted on later.
Common Pitfalls and How to Avoid Them
A handful of mistakes recur so often they almost form a pattern. The first is choosing the solution before the problem: "We bought such-and-such tool, now where do we plug it in?" That is like buying a hammer and wandering around looking for nails. The second is treating it as a one-off project: AI systems are not set-and-forget but living systems that must be monitored, fed, and can degrade over time. The world changes, the data shifts, the model may not be as accurate as it was yesterday; this is called 'drift,' and you need a maintenance plan for it.
The third and perhaps most expensive mistake is blindly trusting the model's confident errors. Large language models can fabricate something they do not know in extremely convincing language; this is called 'hallucination.' In domains where accuracy is costly to get wrong — law, health, finance — this is the biggest risk. The fix is not to set the model free but to tie it to verifiable sources, run its output through a checking layer, and keep a human in the loop for critical decisions. That is exactly why, in İçtiHub, we anchor every answer to the legislation and case-law source it rests on: the user should see not just the answer but where the answer came from.
The fourth is the human side, and it is often more decisive than the technology itself. Even the best system gathers dust on the shelf if the team meant to use it does not trust it, fears it, or cannot fit it into their workflow. Projects stick when they are presented to staff not as "the tool that will replace you" but as "the tool that will take the boring part off your hands," and when they come with training and a feedback channel. Installing the technology is easy; getting people to actually use it is the hard and truly valuable part of the work.
Calculating ROI Honestly
In the end it all comes down to one question: is this investment paying for itself? The ROI (return on investment) calculation sounds simple — gains divided by cost — but done honestly it is more thorough than most presentations. The gain side is not only 'hours saved'; reduced errors, faster delivery, better decisions, opportunities not missed, and sometimes simply staff focusing on more meaningful work are all gains. Some of these are easy to measure, some hard; rather than ignoring the hard ones, at least flag them honestly.
On the cost side, the biggest mistake is forgetting the invisible line items. The license or model fee is usually just the tip of the iceberg. Beneath it lie 'hidden' costs like data preparation, integration, maintenance, monitoring, training, and correcting wrong answers. A realistic calculation puts these on the table from the start; otherwise the project's return looks bright on paper but never materializes. A good rule: estimate the first-year cost a little higher than it seems and the return a little lower — surprises usually run in that direction.
Finally, keep the time horizon realistic. Some AI projects pay for themselves within weeks; some take months; some never do — and recognizing that early is not a failure but good management. Treat ROI not as a one-time gate but as a continuously updated indicator. The healthiest approach is to start with a small pilot, see the real number, then scale what works and honestly shelve what does not. Hype promises you a revolution; good engineering and good management offer you a measurable, repeatable and honest return. Over the long run, it is the latter that wins.