AI
AI development
It has become easy to build something that works on ten examples. It is still hard to build something that works on a thousand and does not need babysitting every week.
- Same-day reply
- Fixed price
- No lock-in
- Runs in production
- Evaluation from day one
- Vendor independent
- Cost under control
Service
AI development
The difference between a demo and something that runs
A demo only has to impress once. Something that runs has to handle the inputs nobody thought of, respond within a reasonable time, cost the same next month, and fail in a way you can detect.
That is the part I get brought in for. Not because the prototype was bad, but because the distance from there to production is larger than it looks from outside.
What I build
- Search and answers on top of your own documentation, with sources shown so people can check.
- Function calling against your own systems, so the model looks things up in real data instead of guessing.
- Bulk data work: classification, extraction from documents, product copy across thousands of SKUs.
- Internal tools where a team saves hours a week on something otherwise done by hand.
Evaluation
Without an evaluation setup you have no idea whether a change made things better or worse. You have a feeling, and feelings are unreliable when the answer differs every time.
I build a test set of real examples early, usually twenty-five to a hundred, 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.
Deliverables
What you get
Concrete deliverables, not a report of recommendations someone else has to find time for.
- A working system
Not a prototype in a notebook. Something running in your infrastructure that handles failure and can be monitored.
- An evaluation set
25 to 100 real examples with expected answers, so you can see for yourself whether a change made things better or worse.
- A cost estimate
What it costs per call and per month at your expected volume, worked out before we build rather than after.
- Documentation
How it fits together, where the limits are, and what to do when it behaves oddly. Written for whoever takes over.
Process
How it works
Four steps. You know what happens when, and you can stop after any of them.
- 01
Find the task
We look for the work that gets done many times a week, follows a pattern and annoys the people doing it. That is where the first win is.
- 02
Measure the baseline
How long does it take today and how often does it happen. Without that number you cannot say afterwards whether anything improved, and it becomes one gut feeling against another.
- 03
Build and evaluate
I build a test set of real examples early and measure against it every time the prompt or model changes. It is the single thing most often missing in projects I take over.
- 04
Put it into production
Into the systems people already work in, with logging on everything and a way to switch it off. Plus an agreement on who owns it once I am gone.
Who does the work
I am the person you will be working with
My name is Mikkel and I have been building for the web since 2010. There is no project manager in between, and you will not get a junior on the job because the senior was busy. What you agree is what gets built, and I am the one building it.
Day to day I am a partner at Bigum&Co, and I have worked on more than 400 projects across ecommerce, pharma, construction and the public sector. Call or write — I usually reply the same day, and I will say straight away if the job is not a fit.
- Experience
- 16 yrs
- Projects
- 400+
- Rating
- 5.0
- Reply time
- Same day
In depth
AI development
What AI development actually involves
The part people imagine — writing a prompt and getting an answer back — is usually less than a tenth of the work. The rest is everything that has to be in place for the answer to be useful.
First there is data. A model cannot answer something it has no access to, and company data is almost always spread across several systems in formats that do not line up. For a model to answer "what do our delivery terms say for business customers", those terms have to exist somewhere retrievable, in a form that can be searched. It is dull work, and it is where most projects spend the first month.
Then there is the question of knowing whether the answer is right. A model has no sense of its own uncertainty the way people do. It answers just as convincingly whether it knows or is making it up. So I build source citations in wherever possible: the user should be able to click through to the document the answer came from and judge for themselves.
And then there is operations. Models get updated, APIs change, prices fall, and a better option appears in eight months. Build yourself locked to one vendor and moving gets expensive. So I always put a thin layer in between, letting the model be swapped without rewriting everything else.
When it is not worth building
A share of the ideas put in front of me would be better solved with ordinary software. If something needs classifying by three fixed rules, three if-statements are cheaper, faster and comprehensible. A model adds uncertainty where none needs to exist.
Volume is the other thing. If something happens fifteen times a month and takes ten minutes each time, we are talking about an hour and a half. That is hard to justify a development project for. I say so when the arithmetic does not work, even when it means I do not get the job.
Reviews
What people say about me
Mikkel is seriously good, helpful, lightning fast to reply — and on top of that he is a nice person.
Trine Handskemager(translated from Danish) Mikkel delivered competent, professional work setting up my website. Everything ran quickly and without a hitch.
Sisse Find(translated from Danish) Mikkel Tschentscher is my lifeline when something is urgent and nobody else can work it out.
Torben Wiese(translated from Danish)
Services
Why me
- 16 years of experience
I have built for the web since 2010 and seen most of the ways a project can come off the rails. It makes the estimates more honest.
- 400+ projects
Across ecommerce, pharma, construction and the public sector. Chances are I have seen something close to your job before.
- You talk to the person coding
No project manager in between, and no junior on the job because the senior was busy. What you agree is what gets built.
Brands I have worked with
A selection. Some freelance, some through agencies, some across several years.
Questions
Frequently asked questions
- Which models do you work with?
- Mainly Claude and OpenAI, but I build with a layer in between so you can switch. The price and quality of these models change fast enough that locking in is a bad idea.
- Does our data have to leave the building?
- Not necessarily. There are EU-hosted options and agreements where data is not used for training. If everything must stay internal, there are models that run on your own infrastructure, but they are weaker and that belongs in the decision.
- What does it cost to run?
- Entirely down to volume and how much text goes along with each call. I work out an estimate early, because it often changes how the solution should be built.
- Can you build on what our current vendor made?
- Often yes. I start by reading the code and say honestly whether building on it or starting over makes more sense. Both answers happen.
- 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 maintains it afterwards?
- That has to be agreed 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 make an arrangement instead of pretending the question does not exist.