Development
AI systems you can run yourself afterwards
We design, build, operate and maintain production AI systems — on Swiss infrastructure, against measurable acceptance criteria, with source code and operations manual in your hands. Ordered in stages, with an exit after every stage.
How we think about development
What «development» means here — and what it does not
An AI system is not a project that ends at go-live. It has a model version that ages, a knowledge base that drifts, and an answer quality nobody knows until it is measured. Order only the build and you buy an artefact; plan for operations and maintenance and you buy a capability.
So we build towards handover from day one: containerised, documented, with test questions and gold sets that make quality verifiable. Whether we operate the system afterwards or your IT takes it over is a decision you make — not one you drift into because nobody else understands the code.
To be clear about the boundaries: a workshop transfers knowledge. Consulting frames, prioritises and accompanies. Development delivers a running system. The three interlock but are ordered separately — and if a workshop is enough, we say so.
Four phases, four sets of deliverables
Design
Requirements, architecture and the yardstick — before a line of code exists.
- Requirements workshop with the business unit, IT and the eventual users
- Architecture decision covering data storage, model choice and hosting location
- Test-question catalogue and gold set — the criteria acceptance is later measured against
- Feasibility assessment: what is realistically achievable given this data
Engineering
Implementation as a versioned, containerised system — not a prototype that gets rewritten later.
- Data ingestion and preparation from your existing sources
- Processing pipeline, web interface and interfaces to your systems
- Automated tests plus quality measurement against the gold set
- Docker setup that can be moved to your own infrastructure
Operations
Running operations on Swiss infrastructure, with a console that shows what the system is doing.
- Hosting in Swiss data centres, no US providers
- Operations console for runs, errors and retries
- Logging and alerting with defined exit codes
- Data backup and documented restore
Maintenance and evolution
An AI system ages faster than classic software. Models get deprecated, data changes.
- Model swaps including regression measurement against the same gold set
- Security and dependency updates
- Onboarding of new knowledge sources and use cases
- Periodic architecture reviews instead of an open-ended retainer
How we assess an enquiry
Almost every enquiry arrives already phrased as a solution — «we need an AI chatbot», «we want a RAG system». Our first job is to find the question behind it, and then pick the simplest technique that answers it. It often sits further down this ladder than the enquiry assumes.
Structure and metadata
If content is neither structured nor tagged, no retrieval layer will save it — it will just reliably find the mess. «Nobody can find anything» is more often an organisation problem than an AI problem, and fixing the organisation costs less than any model.
Full-text search
Deterministic, explainable, in milliseconds, without a model and without recurring model costs. On exact terms, proper names, article numbers and years it regularly beats vector search — precisely where embeddings are weak.
Hybrid search with reranking
Full-text and vector search combined, with the hits reordered afterwards. Covers exact terms and loose paraphrases at once and in practice is almost always better than vector search alone. For many knowledge bases this is already the end of the road.
Structured query or knowledge graph
As soon as questions involve relationships and aggregates — which, where, how many, since when — a query over structured data is more precise than any text search. Text search cannot count. A graph or a database query can, and the result can be recomputed.
RAG with a generated answer
Warranted when the answer has to be assembled and phrased from several sources rather than sitting in one place. It presupposes the rungs below: a RAG system is only as good as the search it stands on.
Fine-tuning a model
Reliably changes style, format and tone — factual knowledge barely, and new knowledge not at all without retraining. Almost never the first step, and practically never the answer to «our knowledge is hard to find».
What a generated answer buys — and what it costs
A generated answer brings a failure mode that search does not have: the model can misrepresent correctly retrieved evidence. A search hit may be irrelevant, but it cannot lie. Anyone asking for source attribution is essentially asking for exactly that traceability.
Then there is the question of how many enquiries need a phrased answer at all. In practice a large share are «where is this documented?» rather than «summarise this for me». For the first kind a good result list is the better answer — faster, cheaper, and without an intermediate layer that can distort anything.
Measurability differs too. Whether the right documents were found can be checked against a gold set cheaply and unambiguously. Whether a generated answer is good costs more to measure and remains partly a matter of interpretation — which is why acceptance thresholds for generated answers so often end in dispute.
None of this argues against RAG. It argues against starting with RAG before it is clear which questions actually get asked. We settle that in the stage 1 architecture workshop — and we tell you when rung 2 or 3 of this ladder is enough. That is the smaller engagement for us, but the honest one for you.
Order in stages instead of signing a blank cheque
Each stage has its own outcome and its own price. After every stage you decide whether the next one follows — and you keep whatever exists by then.
Stage 1
Requirements and architecture
A moderated workshop with everyone involved. The output is an architecture decision, a test-question catalogue and jointly defined acceptance criteria. This stage pays for itself even if you then build elsewhere — you hold a specification you can put out to tender.
Stage 2
End-to-end slice
One complete path runs in production — from data source to result in the interface. Not every feature, but every layer. This is where the assumptions from stage 1 prove out or do not, and it happens before the bulk of the budget is committed.
Stage 3
Build-out and acceptance
Feature scope, quality optimisation and formal acceptance against the test-question catalogue from stage 1. One rework cycle is included. After that comes handover to your IT, or transition into operations with us.
What you hold at the end
- The runnable source code in the repository, including configuration and prompts
- An operations manual: start, stop, monitor, what gets logged and what the exit codes mean
- The test questions and gold sets the quality was measured against
- A container setup that can be moved to your own infrastructure
- A handover session with your IT — not just a zip file
- A data-processing agreement and NDA before the first data is handed over
Three operating models
- We operate, you use
- We host the system in a Swiss data centre, monitor operations and keep it current. Sensible while the system is young and its scope is still moving.
- You operate, we maintain
- The system runs on your infrastructure, your IT holds control. We handle model swaps, updates and further development on a time-and-materials basis.
- Full handover
- Operations and maintenance sit with you. We remain available as a sparring partner for periodic architecture reviews. This is the model we work towards — not the one we resist.
Hosting location and data protection
Hosting exclusively in Swiss data centres, no US providers. The language model is either one operated in Switzerland or the EU, or a self-hosted open-weights model — which of the two is decided in the architecture workshop, because the quality threshold depends on it. Only the text passages needed for a given request are processed.
Indicative pricing
All amounts are starting prices in Swiss francs, excluding VAT. What a project actually costs depends on the scope and structure of your data, the required quality threshold, and whether a hosting environment already exists. Nobody knows those three honestly before the architecture workshop — which is why this is a floor, not a fixed price.
- Stage 1 — requirements and architecture workshop
- from CHF 12,500 (flat)
- Stage 2 — end-to-end slice
- from CHF 19,000
- Stage 3 — build-out and acceptance
- from CHF 25,000
- Operations, maintenance and evolution
- time and materials, day rate from CHF 2,500
- Third-party infrastructure (hosting, compute, model usage)
- from CHF 80 per month, billed by the provider
We never exceed a ceiling stated in a quote without your prior written approval. Universities and NGOs receive special conditions.
Two projects from practice
In operation
Feedback pipeline for a Swiss wholesaler
Customer feedback from several touchpoints runs automatically through an AI evaluation into a database and from there into the company's reporting views. Ordered in stages, running end to end in production since August 2026, with code handover to the client part of the engagement.
Read the full case →A typical enquiry
Internal enquiry desk — from request to assessment
This is how enquiries arrive: already phrased as a solution. The case stands for a type we see regularly — and shows which questions we ask first, why RAG does turn out to fit here, and where we contradicted the client.
Read the full case →Frequently asked questions
- What does an AI system cost with you?
- A pilot with architecture workshop, end-to-end slice and build-out typically starts around CHF 56,500, spread over three separately orderable stages. The floor assumes a manageable data set and an existing hosting environment. We give a reliable number only after the architecture workshop — before that it would be a guess.
- Who owns the code in the end?
- Everything project-specific is yours: the data, the knowledge base built from it, configuration, prompts and customisations. We hand those over in a common, reusable format. Our reusable architecture and methodology base remains ours; you receive a non-exclusive licence to it. That split is precisely why a pilot with us costs less than a build from scratch.
- What happens if the quality falls short?
- The quality threshold is defined jointly before the project starts and measured against a test-question catalogue supplied in advance, not accepted on gut feel. One rework cycle is included. If the threshold is still not met, we assess what was achieved together and agree how to proceed — rather than signing off on an acceptance nobody can evidence.
- Where does our data run?
- In Swiss data centres. No US providers. The language model is either operated in Switzerland or the EU, or self-hosted from open weights. A data-processing agreement and an NDA are signed before any data is handed over.
- How long until the first working result?
- Roughly six weeks after the project starts, provided data access is in place and the acceptance criteria from the architecture workshop exist. In our experience data access, not development, is the most common cause of delay.
- Can we develop the system further ourselves later?
- Yes, and the build is designed for it. The system is containerised, the processing pipeline documented, the test questions sit with you. Your IT can extend the pipeline without asking us. If you bring us back for reviews afterwards, that should be a choice and not a dependency.
- Do we need a workshop or consulting first?
- Only if the use case is not yet settled. If it is unclear in-house which AI initiatives take priority, consulting is the cheaper entry point. If the team lacks the fundamentals, it is a workshop. But if you already know which system you need, the stage 1 architecture workshop is the direct route.
Book a discovery call
30 minutes, free. We listen to the use case and tell you whether it warrants a development project — or whether a workshop or consulting engagement gets you there faster.