AI development
AI development that reaches production and keeps working
AI development means building solutions on top of language models that survive daily use. The demo is the easy part. I have been a developer since 2010 and write the code in every project myself. We start small, measure the result and expand from there.
- I usually reply the same day
- Written estimate before work starts
AI development
From prototype to production
A prototype only has to convince in one meeting. A solution in production has to handle the inputs nobody predicted, respond within reasonable time, cost the same next month and fail in a way you can detect.
That distance is larger than it looks, and it is usually where I get brought in. Either to build from scratch with production in mind, or to make a promising prototype robust enough for real users.
Typical projects
- Customer service: suggested replies, case summaries and search across previous enquiries.
- Document handling: extracting data from contracts, invoices and technical documents.
- Internal tools: search and answers on top of your own documentation, with sources you can click through to.
- Integration with existing systems: function calling against your CRM, accounting system or own API, so the model works with real data instead of guessing.
Evaluation and measurable quality
Without an evaluation setup you cannot know whether a change made the solution better or worse. You only have a feeling, and feelings are unreliable when the answer differs every time.
So I build a test set of real examples with expected answers early, and measure against it every time the prompt or model changes. It is the single thing most often missing in the projects I take over from others.
What you get
Concrete deliverables, not a report of recommendations someone else has to find time for.
- A working system
A solution running in your own infrastructure that handles errors and can be monitored in production.
- An evaluation set
A test set of real examples with expected answers, so you can measure for yourselves whether a change improves quality.
- A running-cost estimate
A calculation of what the solution will cost to run at your volume, done before we build.
- Documentation
A description of how the solution fits together and what to do when things go wrong, written for whoever takes over.
How it works
Four steps. You know what happens when, and you can stop after any of them.
- 01
Pick the process
Together we find the piece of work that repeats often enough for automation to pay off. The more contained the task, the faster the first version reaches production.
- 02
Set a baseline
We record how long the task takes today, how often it occurs, and how many errors slip through. Without those numbers, nobody can tell afterwards whether the solution was worth the effort.
- 03
Build against a test set
I collect real examples from your day-to-day and test every prompt and model change against them. That keeps quality stable when the solution is tuned later on.
- 04
Production with logs and a kill switch
The solution is wired into your existing systems with full logging and a switch that can turn it off. I document the setup and train someone on your side to maintain it.
Brands I've worked with
Frequently asked questions
- How does AI development differ from ordinary software development?
- The foundation is the same, but a language model does not answer identically every time, and that changes how you test and handle errors. Evaluation and monitoring therefore take up far more room than in a classic project. The craft of integrations and data models is familiar territory.
- What does AI development cost?
- It depends on the scope. The three things that drive the price most are the number of systems to integrate, the quality of your data and the precision requirements. Describe the task in an email and I will ask a few clarifying questions and come back with a concrete quote, with a reply the same day.
- Which models do you work with?
- Mainly Claude and OpenAI, but I always build with a thin layer in between so the model can be swapped later. Price and quality in this field change fast enough that locking into one vendor is a bad idea.
- How do you handle GDPR and data security?
- We start by clarifying what data the solution actually needs, because personal data can often be kept out entirely. Where it has to be included, I use EU-hosted models or agreements where data is not used for training, and I document the processing so your DPO or advisor can assess it.
- Do you only work with companies in Copenhagen?
- No. I live in Herlev outside Copenhagen, but a large share of my clients are elsewhere in the country, including Aarhus, Odense and Aalborg, and a few abroad. Development works fine over video and in writing.
- How long before something is in production?
- A bounded solution on one system is typically four to eight weeks including testing. If data has to come from several systems, the integrations set the pace, not the AI part.
- Who owns the code and the prompts?
- You do, from the first commit. The code lives in your repository, the prompts are documented, and you can take everything to another developer at any time. I do not build anything that leaves you dependent on me.
- Who maintains the solution afterwards?
- We agree on that before we start. If your own team can take over, I build it so they can and write the documentation for them. If they cannot, we set up an ongoing arrangement instead of leaving the question hanging.