Why we don't put 'AI' in our hero (and what we actually use it for)

The thing missing from our hero

If you visit our homepage you will see the word "Custom-engineered." You will not see the word "AI." That choice is deliberate, and we have been asked about it enough times that it is worth writing down what we think and what we actually do.

The 2026 default for a B2B software firm is to lead with AI. Pages open with AI-first, agentic, GenAI-native, intelligent-by-design. The marketing budget went to the same workshop and came back with the same answer. We chose to opt out of that workshop, and the choice was not about being late.

AI is a tool. It is a useful one, sometimes the right one. It is not a strategy. Clients hire us to make their software deliver outcomes for their business. The interesting question is never "can we use AI here." The interesting question is always "what is the cheapest, most defensible, most maintainable solution to this specific operational problem, and is AI part of it." About half the time the answer involves an AI component. About half it does not. We try to be honest about which half each project sits in.

The shape of this post: where we use AI today, the three filters that decide whether AI ships in a client deliverable, and the kind of buyer this position serves well.

Where AI lives in our work today

We are open about this. The places AI is part of how we operate fall into two buckets.

Internal tooling

Code review. AI as a first-pass reviewer on pull requests, catching the categories of issue that get tired humans to miss them at end of sprint - dead code, error-handling gaps, schema-drift warnings. Final review is still a senior engineer; AI shortens the loop.
Brainstorming. Architecture discussions, naming, debugging unfamiliar stack traces. Used the way an engineer uses a thoughtful colleague who never gets bored.
Project management. Surfacing risks across sprint changelogs, drafting status notes that the project lead then edits and signs.
System documentation. Generating first drafts of architecture documents, runbooks, and onboarding material from the codebase, so the human author starts at draft three rather than draft one.

The pattern across all of these: AI accelerates the boring portion of well-defined work, freeing senior engineering attention for the parts that actually require judgment. We do not bill clients for AI-generated work product. The leverage shows up as faster cycle times and more attention on the hard decisions.

Client deliverables

When AI ships in something a client uses, the use cases we have shipped most often:

Customer support and member-facing chatbots. Triage layer that resolves common questions, escalates the rest cleanly to humans, and logs every interaction for compliance.
Recommendation systems. Product, content, or member-experience recommendations driven by behaviour patterns - retail, e-commerce, and member loyalty platforms.
Logistics path optimisation. Routing engines that handle multi-stop optimisation with capacity and time-window constraints, with deterministic fall-back routing when the model output fails sanity checks.
Learning content tooling. In our NusaLMS deployments: syllabus generation drafts, learning-content summarisation for revision, and learner-facing Q&A chatbot that answers questions on top of the course corpus.

Each one of these is a specific operational problem AI happens to be a good fit for. None of them was the answer to "where can we put AI in this project." All of them were the answer to "what is the lightest defensible solution to this problem."

The three filters before AI ships

We do not ship AI into a client deliverable because the brief mentions AI. We ship it when it clears three filters. If any one of these fails, the answer is no, even if the buyer requested AI explicitly.

Filter 1: Has it earned its place against the deterministic alternative?

For every problem there is usually a deterministic alternative. Sometimes a rule engine. Sometimes a SQL query. Sometimes a hand-tuned heuristic that took an engineer half a day to write. The first question is always: can this be solved without statistical machinery?

If a regex would do the same job 99 percent of the time at 1 percent of the operating cost, the answer is regex. Statistical solutions carry permanent maintenance costs - model drift monitoring, retraining cadence, evaluation infrastructure, prompt versioning - that deterministic solutions do not. We add that maintenance burden only when the problem actually demands it.

The honest version of this question: would a senior engineer who is not impressed by AI use it here, given the same problem? If the answer is "they would not bother, they would write 30 lines," we don't ship the AI version.

Filter 2: Can it survive an auditor?

We work in regulated industries. Financial services, healthcare, public sector, energy operators. These environments have a non-negotiable property: every operationally-meaningful decision the system makes has to be explainable, traceable, and reproducible.

AI components fail this test by default. A model that recommends an outcome without producing the rationale behind it is unshippable into a context where a regulator asks "why did the system reject this transaction." We require:

An auditable rationale alongside every consequential output. This often means a hybrid - rules-based decision engine that the AI feeds inputs into, rather than AI directly producing the final call.
A logged input, output, and model version for every inference that touched a customer record, retained at least as long as the regulatory data-retention window requires.
A complete training-data provenance trail for any model trained on client data.

If a feature cannot clear this filter, the alternative is usually to keep the AI in the operator-facing tooling (where the human reviewer provides explainability) rather than in the customer-facing decision layer.

Filter 3: What happens when the model fails?

Models fail. Sometimes silently. The version-3.2 release of an upstream API changes behaviour in ways your test suite did not catch. A vendor's model gets deprecated. The training data drifts. The prompt you wrote for GPT-class-X stops working when class-Y rolls out.

For every AI feature in production we require a fall-back. The fall-back is what the system does when the AI component returns garbage, timeout, or refusal:

For a recommendation feature, the fall-back is usually a curated default list. Worse experience for the user, but never broken.
For path optimisation, the fall-back is a deterministic shortest-path solver. Worse routes, but routes that always arrive.
For a customer-support chatbot, the fall-back is an escalation queue to humans, with reasonable wait-time expectations set.
For content summarisation, the fall-back is the original content with a "summary unavailable" notice.

If we cannot specify a fall-back that the operator finds acceptable, the feature does not ship. This is the filter that fails most often in early scoping conversations. It is also the filter that prevents the most production incidents.

Who this position serves well

This is not a position that wins every brief. Some buyers want to lead with AI in their own marketing, and they want a partner who will mirror that. We are not the right partner for that engagement, and we are honest about it during scoping.

The buyers this position serves well:

Heads of IT in regulated industries scoping AI features that have to survive audit. They want a partner who treats the auditor's question as the starting point, not as a problem to work around.
Procurement teams evaluating proposals that mention AI. They want a vendor who can explain, in writing, where the AI is and why, with a defensible fall-back plan, before signing.
CTO who has been burned by AI demos that didn't survive production. They want practical, conservative AI integration where the cost of failure has been thought about by the same team that built the success path.

If your AI brief is more honest than your investor pitch, we are a good fit. If you need AI everywhere because the deck demands it, there are louder vendors who will help you.

What to bring to a scoping call

If you have an AI feature in a brief and you want a sanity check before committing:

The deterministic alternative. What would this look like without AI? If you have not asked, we will ask.
The audit story. Who is the regulator (or internal auditor) for this system, and what do they need to see for every consequential decision?
The failure mode. What does the user experience look like when the AI component fails for one week straight while we resolve the root cause?

Bring those three answers (or admit you don't have them yet, which is also a useful starting point) and we can usually scope the AI portion of a build in 30 minutes.

If that matches the kind of conversation you want, book a 30-minute call.