AI inside software that has to run, not inside a demo
Most requests that reach us open with "we need a chatbot". Behind a good half of them sits a search problem or a process problem, and a conversational agent is the worst available shape for either. So the first conversation is about the problem, not the technology.
The request arrives as a chatbot, the problem is elsewhere
When a company asks for a chatbot, what it almost always wants is for an employee or a customer to find something in ten seconds instead of ten minutes. That is a search problem. Decent search, with filters, dated results and a link to the source, answers better, costs less to maintain and does not make things up.
The other half of these requests is a process problem. A form retyped by hand, a document passing through five inboxes, a business rule applied out of habit. There too, the answer does not start with a language model. It starts with looking at the flow and deleting the steps that no longer have a reason to exist.
There are real cases where conversation is the right interface: when the question is open ended, when the user does not know what to ask for, when answering means combining several sources. Those are worth building. For the rest, you hear it before the quote rather than after.
A retrieval system is only as good as the documents behind it
Retrieval augmented generation has one property that demos hide: it answers with whatever you hand it. If your knowledge base holds two contradictory procedures, one of them three years out of date, the model will repeat the contradiction with exactly the same confidence as everything else.
So the expensive part of this kind of project is neither the model nor the vector store. It is deciding who owns each document, which source wins when two disagree, and by what mechanism a stale version leaves the index. If nobody inside the business will take that on, the project ships a confident and wrong assistant, which is worse than shipping nothing.
In practice we ask for the real corpus before pricing anything. Not a curated sample: the whole thing, with its duplicates, its 2019 revisions and its crooked scanned PDFs. Its condition decides the rest of the project.
Generative output facing customers, and what it requires
Anything generative and customer-facing will eventually produce a sentence the business has to answer for. That is not a risk to eliminate, it is a risk to contain, and it gets decided before launch rather than after the first complaint.
You need a path out to a human, one click away, not buried behind six attempts. You need an evaluation set, meaning a list of real questions with the answers you expect, replayed on every change of prompt, model or corpus. You need to be able to roll back and switch the feature off within minutes, without redeploying half the product.
You also need a record of what was asked, what was answered and from which sources. The day a customer disputes a reply, that record is the only way to find out what actually happened.
Where your data goes
Sending company documents to a third-party model provider is a decision, with contractual and regulatory consequences. It can be the right one. It should not be made by default, in a configuration file, because that was the fastest thing to wire up.
Where it matters, the work stays with you. Our engineers can work inside your tenant, on your infrastructure, under your access controls, with the model your organisation has already approved. The data does not move. The contract runs through JADEV GROUP SARL in Belgium, in euros, under Belgian law.
On security, stated precisely: our practices follow ISO/IEC 27001 principles and are mapped against CyberFundamentals from the Belgian Centre for Cybersecurity, with the Stage 2 audit planned with a BELAC-accredited body in 2027. We are not certified today, and you will never read otherwise on this site.
Where we are the wrong answer
We are not a research lab. We do not train foundation models and we are not about to start. If what you need is a domain model trained from scratch, or a paper, this is not the place.
We are not a reseller and we have no partner status to put on a slide. If what reassures you in a tender response is a partnership badge with a model provider, other suppliers have one and we do not.
If your need fits an off-the-shelf product, buy the product. A generic support assistant, meeting transcription, writing help: these exist for a few euros per user per month, and commissioning the equivalent costs far more for a worse result. We are for the work that has to plug into your systems, your data and your rules, which off-the-shelf software does not do.
And if your procurement process requires a valid ISO 27001 certificate at signature, we do not clear that filter today. That is a legitimate reason to rule us out.
How it gets built
The technical base is the one we use everywhere else: Azure, .NET, Node, Next.js, React, TypeScript, PostgreSQL. An AI feature is still software, with tests, CI, environments and someone to call when it falls over. What makes it different is that it can fail by producing something plausible, which is why evaluation and logging matter more here than error monitoring alone.
We run an AI-assisted development cycle internally and we write about it publicly. That means people who have seen where these tools hold and where they give way, on their own code, before putting them anywhere near yours.
The formats that produce something usable. The first one is often the only thing you need before deciding anything else.
- Scoping before building1 to 2 weeksLook at the problem, the corpus and the process, then say whether AI is the right shape.
- Internal document searchNode or .NET, PostgreSQL, AzureCited answers over your documents, with a named owner per source.
- Customer-facing assistantNext.js, TypeScript, logging, human handoverNarrow scope, evaluation set replayed on every change, rollback ready.
- Internal process automationAzure, .NET, PostgreSQLOften with no generative model in the critical path, and that is deliberate.
- Work inside your environmentYour tenant, your access, your modelFor when the data must not leave your estate.
- Taking over a prototypeDepends on what existsA pilot that impresses in a meeting and now has to survive daily use.
Common questions
- We want a chatbot. Are you going to talk us out of it?
- Sometimes, yes. If the real question is where a document is, proper search answers better and is easier to keep alive. If conversation is genuinely the right interface, we build it. Either way you get the answer before the quote.
- Will the model make things up?
- It can, and it will do so confidently. You reduce how often by forcing it to cite sources and keeping its scope narrow. You do not remove it. That is exactly why an evaluation set, a human path out and a kill switch are not optional.
- Do you train models?
- No. We are not a research lab and we do not train foundation models. We integrate existing models into software that has to run in production, and that is where nearly all the work sits.
- Does our data go to a model provider?
- Only if you decide it does. That is a contractual and regulatory call, not a technical detail for a developer to settle. Where it matters, our engineers work inside your environment with the model you have approved, and nothing leaves.
- Are you ISO 27001 certified?
- Not today. Our practices follow ISO/IEC 27001 principles and are mapped against CyberFundamentals from the Belgian Centre for Cybersecurity, with the Stage 2 audit planned with a BELAC-accredited body in 2027.
- How long until we have something usable?
- Scoping takes one to two weeks. A first useful scope in production is measured in weeks rather than days, and the duration usually depends on the state of your documents or how long access takes to grant, not on the model.
- Why not just buy a tool?
- Often you should. If the need fits an existing product, buy it, you will move faster and pay less. We are for the part that has to connect to your systems and your rules.
Describe the problem, not the solution
Tell the scoping assistant what your teams are looking for today and how long it takes them. It asks the questions a senior engineer would ask, then returns an estimate with a format and a start date. If the right answer is not AI, that is what you will read.
Scope an AI project- Technical debt: what it costs and when to repay itHalf of what gets called technical debt is not debt. How to tell deliberate borrowing from ordinary mess, how to make the cost legible to a board, and why some of it should be left exactly where it is.
- Regression testing for critical user journeysCoverage protects nobody. Three rings of tests, a ten-minute rule, and the only metric worth putting on a wall.
- System architecture principles that survive productionAn architecture is not judged on a diagram. It is judged the night a service goes down, the month the team doubles, the year the product pivots. These are the principles we apply to every system we build.
- Extended development team: how it actually worksHiring eight engineers in 2026 takes nine months and costs you the year. An extended team is in place in three weeks. But the real point isn't speed. It's balance.
- IT staff augmentationNamed engineers inside your existing team, on a European working day, contracted through Belgium.
- Nearshore vs offshoreA straight comparison for European teams who already offshore and are weighing a move closer.
- Nearshore development teamA dedicated group that owns delivery end to end, from architecture through production support.
- CTO as a servicePart-time senior technical leadership, to arbitrate without a full-time hire.
- Managed IT and cloudCloud, pipelines, domains, mail and access, held by the team that also knows the code.
- Cloud migrationInventory, batched cutovers and a tested rollback, so the move does not depend on luck.
- Infrastructure as codeEnvironments described in code, reviewed and rebuildable, instead of configured by hand once and never again.
- Shopify developmentFor Shopify stores that have to talk to an ERP, a stock system or a payment flow.
- Data engineeringWarehouse, pipelines and reconciliation, so the numbers can be trusted.
