Your Team Can Build AI. But Can They Make It Work?
Contents
A developer can connect to a large language model in an afternoon. An IT team can add an AI step to a workflow in a week. A business analyst can assemble a working prototype with no-code tools, and AI coding assistants make all of it faster. That is good news for any organisation that wants to use AI.
It also creates a quiet misconception: because AI has become easier to build, it must also have become easier to engineer, operate and pay for over time. It has not. A demonstration is not a dependable enterprise system, and the distance between the two is where many AI investments meet their hardest problems.
So the useful question for a leadership team is not “can our people build AI?” Most good teams can. It is which parts of the lifecycle your team should own, what the whole system will cost to run, and where specialist experience changes the outcome. A simple way to think about it is the difference between being capable, competent and proficient.
Capable, competent, proficient
These are three levels of engineering maturity. Each level keeps what the one before it has, and adds to it. None of them is a verdict on how talented a team is. They describe experience with a particular kind of system, and any good team can move through them.
ReadoutHover or tap a level to read it.
Capable: we can build it
Capability means making something work. The chatbot answers a question. An AI workflow pulls the right fields from a sample invoice. A dashboard produces an insight nobody had before. That is a real achievement, and prototyping is the cheapest way an organisation can learn what is possible.
A prototype answers one question: can this be done? Usually it is a working demo on sample data, run by the person who built it, along the path they expected users to take.
It does not show whether the system will stay reliable, secure and affordable when it meets documents nobody tested, a provider that changes its model or its API, an answer that is confidently wrong, sensitive customer data, or the day the person who built it moves to another project.
Capability gets the system working. It does not show that it will keep working.
Competent: we can make it reliable
Competence means reproducing the result under conditions you did not choose. For an enterprise AI system, most of that is engineering that never appears in a demo:
- Data pipelines that cope with what actually arrives, not only with what was expected.
- Evaluation: a test set drawn from real inputs, run again before every change of model, prompt or retrieval, so that “it seems better” becomes a measurement.
- Observability: logs, accuracy, latency and cost per request, watched over time so that drift is caught before users notice it.
- Permissions and data boundaries: what the system may see, who may use it, and what it must never send outside.
- Integration with the systems of record the business already runs, including identity, approvals and audit.
- Exception handling and recovery: a fallback when a provider is down, and a way back to the last version that worked.
AI adds complications of its own. Model outputs are probabilistic, so the same input does not always produce the same answer. Provider behaviour can change between versions. And the quality of the system depends on the information and tools it is given, not only on the model.
A competent team also decides deliberately where AI may recommend an action and where a person must approve it, and it records those decisions. That is how REKA approaches intelligent automation: review checkpoints wherever judgement matters, and every step logged.
Deployment is the start of operational responsibility, not the finish line.
Proficient: we know what should, and should not, be built
Proficiency is judgement. It grows from repeated experience with different problems, constraints and trade-offs, and from seeing which approaches held up in operation and which quietly failed.
A proficient team knows when a conventional workflow, better data, an existing product or simple automation will outperform a custom AI application. It balances accuracy, latency, security, maintainability and cost, rather than optimising one of them at the expense of the rest. REKA’s own AI research starts from one such trade-off: on a bounded task, retrieval over your own sources beats a bigger model, and the answer is usually a smaller, private, grounded system. The Lab explains that choice in AI & LLMs: stop starting with the model.
A proficient team also asks a question that is easy to skip: better than what, exactly? A result without a baseline is not a result, and the real alternative includes doing nothing. It is one of the five questions the REKA Lab asks before building anything.
The objective of enterprise AI is not to deploy more AI. It is to create better business outcomes. Sometimes the best engineering recommendation is not to build anything new.
The hidden costs of building AI in-house
An organisation may already employ capable developers, have inexpensive access to models and give its engineers AI coding assistants. Why would it engage an external specialist at all?
That is a reasonable question, and sometimes the honest answer is that it should not. But the comparison has to cover the total cost of ownership across the system’s life, not only the first build. Most of the cost of enterprise AI development sits around the model, not in it, and existing payroll does not make internal development free.
| Cost | The question to ask before you start |
|---|---|
| Engineering | Beyond the prototype, who prepares the data, builds the evaluation set, integrates and deploys, and what do they stop doing meanwhile? |
| Reliability | Who watches accuracy, latency and cost after launch, and who is called when it fails out of hours? |
| Security and governance | Who manages data access, permissions, audit trails, data-protection obligations such as Malaysia’s PDPA, and human oversight? |
| Integration | How will the system work with legacy systems, approvals and the way people actually work? |
| Maintenance | Who responds to model updates, retired APIs, price changes, outages and drift? |
| Knowledge concentration | What happens if the one or two people who understand the system leave? |
| Opportunity cost | Which existing priorities are delayed while the team builds this? |
| Time to value | What does the business lose for every month the system remains unfinished? |
| Exit | What would it take to change the model, the provider or the system itself later? |
These costs exist in every delivery model. An external partner does not make them disappear: it changes who carries them, and how much has been learned elsewhere before your project starts. An in-house build can be the best option for a team with the right skills, the capacity to spare and a long-term reason to own the system.
The most expensive AI system may be one that is inexpensive to develop but costly to operate, repair or abandon.
An illustrative example: the invoice assistant
A finance team’s developer builds a prototype in a few days: a language model reads supplier invoices and extracts the supplier, amounts, dates and purchase order number. On a small set of sample invoices it works well, and the demo goes down well with the leadership team.
The road to production then shows what the demo could not:
- Real invoices arrive as phone photos and scans, in Malay and English, with handwritten notes and credit notes mixed in.
- Now and then the model returns a purchase order number that looks plausible but does not exist, so someone has to decide which fields are checked against the ERP before anything is posted.
- Supplier bank details are sensitive, so access control, logging and an audit trail become requirements, not extras.
- The provider releases a new model version and accuracy on one supplier’s layout changes. Without an evaluation set, nobody notices until a payment goes wrong.
- The developer is reassigned to an ERP upgrade, and the system now has one owner who is no longer available.
Every one of these is solvable, and a competent team will solve them. None of them appeared in the demo, and each one takes time the original estimate did not include.
A proficient review might change the plan altogether. If most of the volume comes from a handful of suppliers who can already send structured electronic invoices, the better first step is to take structured data where it exists, automate the routing and approvals, and keep AI for the long tail of unstructured documents. Less AI, more value, and a smaller system to maintain.
A working AI system is not necessarily a successful investment
Measure enterprise AI against business outcomes: processing time, operating cost, accuracy, revenue, customer experience and capacity your team did not have before. Decide which of these should move, and record where each stands today, before anything is built.
A technically impressive system can be a poor investment. A simple automation can create significant value when it solves the right problem.
The most important work often comes before any code: understanding the process, the constraints, the data and what success will look like. Without that foundation, teams risk becoming very efficient at building the wrong thing. That is why REKA’s method starts with the business, not the technology: see what is worth changing, then prove what is worth building. A valid result can be: don’t build it.
In-house, partner or both: questions to settle first
The decision is often framed as building AI in-house versus outsourcing it. In practice there are three delivery models: your team builds and runs the system; an external partner builds and runs it; or a hybrid, in which your team owns the system and a specialist works alongside them on the hard parts. These questions usually show which one fits.
- Is it core to how you compete? If you will want to own and evolve it for years, plan for your team to own it, even if someone helps at the start.
- Can you staff the whole lifecycle? Evaluation, operations and security as well as the build, from people who can be spared from current work.
- Has anyone on the team taken a similar system into production and run it? Building a prototype and running a production system are different kinds of experience.
- What does delay cost? If time to value matters more than building the capability yourself this year, that changes the answer.
- How sensitive is the data, and where must it stay? This can rule out some architectures and providers before cost is even considered.
- What happens if the people who build it leave? Documentation, handover and shared knowledge are part of the cost in every model.
- Would an existing product or plain automation do most of the job? If so, start there.
- How will you know it worked? Name the baseline, and the number you expect to move.
Why REKA works with internal teams, not instead of them
Organisations should strengthen their own technical capability. They should not have to develop deep expertise in every emerging technology on their own, from scratch, on a live project.
REKA is a technology R&D and innovation partner based in Kuala Lumpur, and its experience spans applied AI, autonomous systems, sensing, automation and software integration. In 2016 it retrofitted a Proton Waja with its own controller board and a single webcam, and drove it from Melaka to Kuala Lumpur on the PLUS Highway. It localised Murata’s traffic-counting sensors in Malaysia and analyses their data in real time, and it built an on-demand cloud platform for UMW’s heavy-equipment service. Because it builds AI that runs on real vehicles and machines, it treats AI and enterprise systems as an engineering problem involving technology, people, processes and operating constraints, not as a model to be plugged in.
As an AI engineering partner, we work alongside internal teams to understand the problem, evaluate approaches and develop the right solution. Sometimes we build. Sometimes we improve what already exists. Sometimes we help a team avoid development it does not need. When we build, the client owns the IP, the code and the system by default, and the handover includes full documentation, source code and training. If a team would rather not run it, we can run it for them as Managed AI.
Your team knows your business. We bring the specialist engineering experience to help them build the right solution, faster and with fewer costly mistakes.
A successful partnership should leave the organisation stronger, with better systems and more of the knowledge that runs them in its own hands. For organisations in Malaysia and the region that want an outside view first, enterprise AI consulting and advisory gives an honest read on where AI creates measurable value and where it should not be used. Where the answer is a new system, custom build and R&D takes it into production with your team.
The better question is not whether you can build it
As AI development tools improve, creating software keeps getting more accessible. Engineering judgement becomes more important, not less.
So before the next AI project starts, ask: can we operate this reliably? Can we maintain it as the technology changes? Can we justify its total cost? Can we measure its business value? And is internal development the best use of our people right now?
Being capable means you can build it. Being competent means you can make it work reliably. Being proficient means you know how to deliver value, and when not to build at all.
If you are weighing an in-house build, a partner or a mix of both, talk to us about your AI project. We will tell you what is worth building, and what is not.
Questions people ask
What is the difference between capable, competent and proficient AI teams?
Capable means making an AI system work, such as a prototype. Competent means reproducing the result under conditions you did not choose. Proficient is judgement: knowing what should, and should not, be built.
Should we build AI in-house or work with a partner?
There are three delivery models: your team builds and runs the system; a partner builds and runs it; or a hybrid, in which your team owns the system and a specialist works alongside them on the hard parts. Whether it is core to how you compete, whether you can staff the whole lifecycle and how sensitive the data is usually decide which fits.
Why can an AI system that works still be a poor investment?
A working system is not the same as business value. Measure enterprise AI against business outcomes: processing time, operating cost, accuracy, revenue, customer experience and capacity your team did not have before.
