AI integration, from demo to production
— Short answer
AI integration means connecting a model to your product or workflow and making it work with real users. The gap between an impressive demo and a system in production shows up in questions of errors, data, cost and latency. With senior engineers, we put those questions in writing before work starts, then build a working system. Not every job needs AI; when yours does not, we will say so.
What AI work do we do?
On our home page, under "AI Products & Automation", we list four kinds of work. When we say AI integration services, this is what we mean:
- Chat and support assistants. Assistants that answer questions from your customers or your team using your knowledge and your systems. Designing what the AI knows, and what it does not, is a major part of the job.
- Automation and agents. Systems that take over repetitive steps in a workflow and are designed so that a wrong move does limited damage.
- Personalization. Features that show a user or a customer different content and recommendations based on their behavior.
- Decision-support systems. Systems that prepare a decision, suggest and show their reasoning; the decision stays with a person.
One example in our portfolio is the AI App Generation platform: a user describes the app they want in chat, a production pipeline turns that into working code, and a live preview and one-click publishing sit right behind it. Every generated app is built and run in its own isolated Docker container, so trying an idea risks neither the platform nor anyone else's app. Handing back a real, live application rather than a mock-up is a different problem from the one most chat tools solve.
From demo to production: seven risks
An AI demo can look impressive; in production there are real users, real data and real consequences. The table below lists the seven risks you meet on the way from demo to production, and the question that has to be answered at the start of the project for each.
| Risk | How it shows up | Question to answer at the start |
|---|---|---|
| Made-up or wrong answers | The model states false information with confidence | Which answers must be grounded in a source, and what does the system do when it is unsure? |
| Data leakage and prompt injection | User input or an outside document tries to change the model's instructions | What data goes to the model, and can the model reach more than the user could? |
| Unmeasured quality | It ships because it "seems to work", and decline goes unnoticed | What does a good result look like, and how do we measure it before and after launch? |
| Cost overrun | The provider bill climbs past expectations as request count and input length grow | What does one request cost, and where is the ceiling if usage grows? |
| Latency | The user waits and the page or chat hangs | How long is acceptable to wait, and can long jobs run in the background? |
| Provider and model dependence | A model version changes or terms are updated and the system behaves unexpectedly | If the model changes, what must we re-verify? |
| Irreversible action | The system decides wrong and the effect cannot be undone | Which actions can the system take on its own, and which need human approval? |
A real example of the last row is in our engineering notes: Proposals, Not Actions: The Control Plane Behind Autonomous Infrastructure Agents. There, an AI agent has no direct access to a cloud system. The only thing an agent can produce is a plan, and whether the plan is carried out is decided not by the model but by a rule-based, deterministic gate. We argue that the dangerous failure is not uncertainty but confident wrongness, so we put safety in a control layer outside the model rather than inside it.
AI or rule-based automation?
Not every automation needs AI; for some, a plain rule is cheaper, faster and more predictable. AI earns its place where the input is free text, ambiguous or highly varied.
| Situation | A rule-based solution may be enough | AI may make sense |
|---|---|---|
| Input format | Regular, fixed fields | Free text, documents in different formats, everyday language |
| The right answer | Always the same, well defined | Depends on context; several answers are acceptable |
| Cost of a mistake | High and unacceptable | Low, or easily caught by a person |
| Explainability | Every decision must be shown with certainty | A suggestion is enough, the final decision stays with a person |
Questions to answer before you start
On some topics there is no single right answer; it depends on the project, the data and the risk. Whichever AI provider you use, these questions should be asked at the start. We also write down the reasoning behind every technical decision.
How will quality be measured and monitored?
- Before launch, what does a "good result" look like, and can we measure it with a set of examples?
- After launch, if quality drops, who notices and how?
- What does the user see when the AI is unsure?
Where does the data go?
- Which data is sent to which provider, is it stored there, for how long and how is it deleted?
- If personal data is processed, what are the obligations under Turkish data protection law (KVKK) or the GDPR? This is something to assess together with your legal counsel; this page is not legal advice.
- If data leaves the country, do your own contracts and the commitments you made to users allow it?
Which model, and which channel?
- Is it written down which model was chosen and why?
- How is the system affected when the model changes or a provider updates its terms?
- Where will the assistant live: on your site, in your mobile app, or in a messaging app such as WhatsApp? Every channel has its own usage and messaging rules, and they shape the design.
AI consulting or a working system?
We are not a consultancy that delivers a strategy deck. We aim to build software that works without the theatre. We talk through where AI makes sense for your work, then turn it into a working system. If AI is not the right answer, we tell you so; as we say on our home page, we are honest about whether it is the right time and the right fit.
Adding AI to your existing product
AI is more often a layer added to an existing product than a product built from scratch. Adding an assistant, recommendations or automation to your web application or your mobile app also brings up integration with what you already have, data flow and permissions. If you do not have a system yet, or you are starting from an idea, building the first version with an MVP development approach is often the more direct route.
How we work
Every project goes through the same four steps from the first conversation to delivery; the Process page has the details. In AI projects, most of the value is created in the first two steps, because that is where we decide what AI will and will not solve.
- Discovery. We talk until both sides describe the same thing: what you expect from AI, whether it could be solved without it, and what a good outcome looks like. Nothing gets built before that picture is shared.
- A scoped proposal. What is being built, in what order and what it costs, written down; work does not start until you approve it.
- Building, visibly. In the live project panel you follow real progress from week one and see early how the AI behaves, so you can steer.
- Review and handoff. You review it, we refine it, then we hand it over.
What to bring to the first conversation
You do not need to prepare; the first conversation is a real one. In AI projects these four things speed it up:
- Real examples. A few inputs the system will receive and the answers it should give; the shortest way to describe a "good result".
- The state of your data. Where it lives, who has access, and which parts must not be shared.
- The cost of a mistake. If the system says something wrong, what happens and who bears it?
- The user and the channel. Who will use it, where and how often?
Source code, infrastructure, access and handover
Once the project is paid in full, the delivered work is yours; what we had before your project, such as our own tools and libraries, stays ours (Terms). AI projects add third-party services. API keys and similar access for model providers follow the principle on the Process page: anything you share for infrastructure work is stored encrypted, used only for your project, and you are free to rotate or revoke it when the work is done.
Unless you would rather handle it yourself, we provision and manage hosting and the deployment pipeline; if you have your own cloud accounts, we deploy there. If you ever want to bring the infrastructure in-house or move it to another team, we help you transfer it cleanly, with accounts, domains and documentation. Nothing we run for you is a reason you cannot leave.
Who we are not a fit for
- You only want an AI strategy deck. We build working systems; strategy is only where it starts.
- You are looking for a guarantee that the AI will never make a mistake. No software, ours included, can be guaranteed to run without interruption or error, and that is even more true for AI. We do not ignore mistakes; we make them part of the design.
- A ready-made chatbot subscription already does the job. Then there is no need for a custom build, and we say so.
Frequently asked questions
How long does AI integration take and what does it cost?
It depends on the scope, so we do not quote figures on this page. Duration and cost are set by the job the AI is for, the systems it connects to, the quality you expect and the cost of a mistake. Scope, timeline and cost are written down before work starts, and the price does not move afterwards.
Does our data go to the model provider?
That depends on the architecture. When a hosted model is used, the content of the request goes to the provider; in some cases it may be possible to filter the data before sending or to build a different setup. Which option fits depends on the nature of the data. We write the decision down with its reasoning.
Which model do you use: ChatGPT, Claude or Gemini?
The choice depends on the type of work, the data, the quality you expect and the cost. We write down the choice with its reasoning; the questions to settle on your side are listed above under "Which model, and which channel?".
Can AI be added to my existing system?
Often yes; AI is usually a layer added to an existing product. What matters is how the system's data will be reached and how permissions will be protected. We look at your current system together and put where to start into a written proposal.
What is the difference between a chatbot and an AI agent?
A chatbot talks and answers questions. An agent can plan steps to complete a task and take actions using tools. That difference changes the level of risk: a talking system's mistake is a wrong answer, while an acting system's mistake can be an irreversible result. That is why, for agents, we decide up front which actions need human approval.
What happens when the AI makes a mistake?
It will; so we treat the mistake as an input to the design from the start. Where a wrong answer is costly, the system does not decide, it suggests, and the action is tied to human approval. The control plane article in our engineering notes describes a real application of this principle.
Selected work

AI App Generation Platform
A pipeline that turns a request made in chat into working code; each app runs in its own isolated Docker container, so trying an idea never risks the platform or anyone else's app.
View case studyRelated services
Engineering notes
Let's pin down your project
Tell us what you want to build. We put scope, timeline and cost in writing before any work starts.
Last updated: