AI Is 10% of the Job. The Other 90% Is Engineering.

Everyone wants to talk about the model. We spend most of our time on everything around it. In this conversation, we lay out how we think about AI and automation — where it earns its place, where it doesn’t, and why the engineering around the model matters far more than the model itself.

How do you define what your company does — and what’s really behind “development + AI + automation”?

We’re an engineering company. We build complete systems — software, and where it’s needed, the electronics and firmware underneath. “AI + automation” isn’t a service we bolt on to sound current; it’s simply what a modern system is expected to do: run itself, learn from its own data, and take work off people’s hands.

The honest version is this: nobody actually wants “an AI.” They want a specific job done reliably — reconcile these numbers, catch this anomaly, answer this customer, flag this risk. The model is maybe 10% of that. The other 90% is the engineering around it: clean data, integrations, security, monitoring, and a plan for what happens when the model is wrong.

The model is maybe 10% of that. The other 90% is the engineering around it.

And a growing part of that 90% is economics. This is the thing people underestimate: an AI feature that looks brilliant in a demo can be quietly unaffordable in production, because unlike traditional software, your cost scales with every single request. So a real part of our work is making AI solutions cheaper and faster — choosing the smallest model that actually solves the task instead of the most impressive one, caching aggressively, routing easy requests to cheap models and escalating only the hard ones, batching what can be batched.

And where it makes sense, taking inference off the API entirely and running it on hardware the client owns. We build infrastructure for running models locally on AI accelerators — Hailo, for example — for workloads that run constantly. Because we also design electronics, that’s not exotic territory for us; the same team that specs the board deploys the model on it. For the right workload it turns an unpredictable monthly bill into a one-off cost, and the data never leaves the building.

How does designing AI and automation differ from “classic” development?

Classic development is deterministic: you write a spec, the same input gives the same output, and “done” is well defined. AI is probabilistic. You’re designing for uncertainty — the model will sometimes be wrong, your data will be messy, and behaviour drifts over time.

But the biggest practical difference is how cheap exploration became. In classic development, comparing three architectural approaches means building three things — so you argue about it in meetings instead, and pick one based on opinion. Now an engineer can play out a scenario in an afternoon: take real data, run it through several different approaches, and watch where each one breaks — long before anyone writes production code. You can be wrong quickly and at almost no cost. That’s a genuine change in how engineering decisions get made.

Which shifts where the effort goes. Less time on “how do we build this,” far more on “how will we know it works.” Designing the evaluation is now the hard part and the valuable part: what does correct look like, how do we measure it, what error rate is acceptable, and what happens on the 5% where the system is wrong. In classic development the code is the product. In AI work, the data and the feedback loop are the product — and the test plan is the design document.

A project you’re proud of — and how AI solved a real business problem

One I’m proud of less for what it does than for how it’s built: an automated system that assesses geopolitical risk by continuously analyzing publicly available sources.

The problem is that the relevant signal is scattered across a moving landscape — news sites, Telegram channels, Discord servers, forums, social platforms. Each has its own format, its own API or no API at all, and all of them change without warning. Anyone who has integrated with ad platforms knows this pain intimately: you build to a contract, and then the contract quietly changes.

The traditional approach would be an integration per source, each with a fixed schema and a fixed contract, then maintained forever. Realistically that’s years of work and a permanent maintenance burden — and part of it is obsolete the moment a platform ships a change.

So we built it the other way around. The foundation is deliberately conventional: the databases, the access control and the core business logic are all traditional engineering, because that part has to be predictable, auditable and boring. What’s AI is everything at the edges — the connectors, adapters and analyzers are either AI-driven or generated by AI, with no fixed model of the world baked in.

The result is the part I find genuinely new. When X changes its API, or Reddit changes a response format, or a new source needs to be added, the system adapts itself. Engineers don’t write a new integration — they review the proposed change and approve it. It evolves alongside the world it’s watching instead of decaying against it.

We didn’t build a product and then maintain it; we built something that keeps rebuilding its own edges, with humans on the approval step.

Where automation delivered a return that surprised even you

Four kinds of return, and the one that surprised me most isn’t the obvious one.

The obvious one is team size. Work that used to require a certain number of engineers to build and support now needs meaningfully fewer — same delivery, smaller team. That changes the economics of every project we quote. The one I didn’t expect: the time it takes to understand what a client actually wants has collapsed. Clients now arrive with an AI-generated MVP — a rough, running version of the thing they’re imagining. Requirements used to be weeks of documents and mutual misunderstanding; now they show us something working and say “like this, but real.” That single change removed one of the most expensive and frustrating phases of software projects.

Infrastructure is where the hard savings sit. One of the biggest wins we deliver is simply the cost of running AI: moving a constant workload — classification, monitoring, extraction — from paying per API token to a smaller, domain-tuned model on hardware the client owns. A recurring, unpredictable monthly bill becomes a fixed one-off cost, and for a workload running around the clock the payback period is short.

And the one that produces profit rather than savings: raw data. Almost every business is sitting on years of logs, transactions, tickets and sensor readings that nobody ever analyzed — not because it wasn’t valuable, but because analyzing it couldn’t be justified. That’s no longer true. Pointing AI at that pile routinely surfaces things worth real money: which customers behave a certain way weeks before they churn, where margin quietly leaks, which combinations actually sell together. The savings were nice; the decisions that got better because someone finally read the data — that’s the actual return.

How do you decide where AI genuinely fits — and where it’s premature?

Clients usually arrive with an idea or a hunch, not a specification. So we run three checks before anyone gets excited.

Is there data?

Do you have it, or is there a source we can legitimately get it from? No data, no AI. That ends more conversations than you’d expect — and ending them early is a service, not a lost sale.

Can it be done at the accuracy the decision actually requires?

This is the question people skip. If the output will drive a business decision, “usually right” may or may not be good enough — and the bar is completely different for suggesting a product than for approving a payment or flagging a risk. So we define upfront what accuracy would make the result trustworthy enough to act on, then check whether the available data can support it. If it can’t, we say so before anyone spends money.

What does each option cost — AI, or plain deterministic automation?

We compare both the build cost and the running cost, near-term and long-term. AI is often cheaper to build and more expensive to run; conventional automation is usually the reverse. If a rule-based solution does the job, that’s the honest recommendation.

We tell clients “you don’t need AI here” more often than you’d think. A company that can say “not here” is stronger than one selling neural networks for everything — it usually means they’ve done the work and know where the value actually is. AI layered on broken data doesn’t fix the mess; it automates it faster and wraps it in something that sounds confident.

Where is the industry heading over the next 2–3 years?

Everything is converging on two questions: does this increase profit, or does it cut cost? The experimentation-budget phase is ending. AI now has to earn its line in the P&L like every other tool.

That leads somewhere quite specific. I expect the cost of tokens to rise rather than fall — inference demand is growing faster than the supply of compute, and today’s pricing reflects a land-grab more than the underlying economics. The moment AI is embedded in daily operations, an unpredictable per-request bill stops being a cost and becomes an operating risk.

So I think a serious share of inference moves in-house: bare metal with AI accelerators, running smaller models tuned to one business domain instead of a giant general model answering everything. A model that only needs to understand your documents, your products and your customers doesn’t need to know Renaissance poetry. Smaller, domain-specific, on your own hardware — cheaper per request, predictable, lower latency, and your data stays where it belongs. We’re already building exactly this, on accelerators like Hailo, for the parts of a workload that run constantly.

For AdTech there’s a second force running alongside it: signal is getting scarcer while AI makes the surface-level work — creatives, landing pages, simple dashboards — nearly free. When everyone can generate those in an afternoon, they stop being an advantage. The edge moves down the stack, to whoever owns clean first-party data, trustworthy measurement, and real-time decisioning.

What to prepare now is unglamorous: own your data, clean your pipelines, fix your measurement. And be honest about which of your AI workloads are constant and predictable — those are the ones worth bringing in-house first.

The misconceptions clients bring — and what actually matters before you start

The big one: people treat AI as a universal solution rather than as a tool. It’s a tool — an exceptionally good one — and like every tool it amplifies whoever is holding it.

Give the same model to an experienced engineer and to someone who has never shipped a system, and you get radically different outcomes. The experienced one knows what to ask for, recognizes when an answer is subtly wrong, and knows what will break in production at three in the morning. The inexperienced one gets code that looks like it works and no sense of which parts are dangerous.

A fool with a tool is still a fool.

I think AI ends up like the computer — everyone will use one, and using one won’t be a skill. What doesn’t change is that judgment and experience decide the outcome. AI raises the ceiling for people who know what they’re doing; it doesn’t remove the requirement to know.

Two more, quickly. That AI is a feature you switch on — it isn’t; it’s a system with data behind it, a way to measure it, and ongoing maintenance, because models drift. And that a bigger, smarter model makes good engineering unnecessary — it’s the opposite, because a powerful model turns bad data into confident, convincing mistakes.

Before launching, be able to answer three things: what decision is this AI actually making, what data feeds it, and how will you know when it’s wrong. If you can’t answer those, you’re not ready to build — and a partner worth hiring will tell you so.

Starting in-house — so a partner can build on it later, not bin it

Start with a process that a competent person in your company already does well — and keep that person involved.

Most people get this backwards. They pick the process nobody understands, or the one whose owner left, precisely because it hurts the most. But then nobody can tell whether the automated version is doing it right. AI fails quietly: it produces plausible output. Without someone who knows what “correct” looks like, you can be wrong for months and feel fine about it.

So choose a process with a qualified owner. Let them verify the output, tune the system, and keep it aimed at the actual business question rather than at a technical metric that looks good on a dashboard. That person is not overhead — they’re the reason the automation stays honest.

Underneath, three habits decide whether a partner can later extend your work or has to bin it and start over. Keep your data clean and in one place, not scattered across ten spreadsheets and one person’s head. Choose standard, interoperable tools over exotic ones nobody else can pick up. And write things down, even lightly — documented process, tidy data, sane tooling.

Do that, and someone like us walks in, understands your system in days, and builds on top of it. Skip it, and the “cheap” DIY version becomes the expensive rewrite eighteen months later.

What’s non-negotiable — even when it’s harder or more expensive

Three things, and none of them are glamorous.

Security and data integrity

We don’t ship systems that treat someone’s data casually — encryption, access control, audit trail, and knowing exactly where data lives and who can reach it. AI projects make this harder, because data starts flowing to places it never went before. That’s a reason to be more careful, not less, and it’s part of why we invest in running models on the client’s own hardware: sometimes the only correct answer is that the data doesn’t leave the building.

Clear metrics

If we can’t state what success looks like as a number before we start, we don’t start. “Better” is not a target. This matters more with AI than anywhere else, because a probabilistic system without a metric is unfalsifiable — it can be quietly wrong forever while everyone assumes it’s fine.

A real test plan

Not “we’ll test it at the end,” but what gets tested, how, against which data, and what the acceptance threshold is. For AI that includes the unglamorous parts: evaluation sets, edge cases, and drift monitoring after launch, because the system that was right in March can be wrong in June without anyone touching it.

Clients almost never ask for these by name. But they’re the difference between a system you can trust with a business decision and a demo that impressed everyone once.

Being the team that still says the true thing when nodding would be more profitable is the part we won’t trade away.

And one that isn’t technical: we tell clients the truth even when it costs us the sale — “you don’t need this,” “this won’t work the way you hope,” “start smaller.” Technology can always be learned. Being the team that still says the true thing is the part we won’t trade away.

Have a workload that’s constant, predictable, and quietly expensive to run? That’s exactly the kind we like to bring in-house. Get in touch.