AI
AI implementation
Most AI projects I hear about do not die for technical reasons. They die because nobody changed the way the work is actually done.
- Same-day reply
- Fixed price
- No lock-in
- One area at a time
- Measured against a baseline
- Training built in
- A realistic timeline
Service
AI implementation
How I approach it
I start by finding the work that gets done many times a week, follows a fixed pattern, and annoys the people doing it. That is nearly always where the first win is, and also where people will actually adopt it.
Then we measure how long it takes today. Without that number you cannot say afterwards whether anything improved, and the discussion becomes one gut feeling against another.
What usually gets in the way
- The data lives in four places and disagrees with itself. That has to be solved first, and it is rarely fun.
- Nobody owns the project after launch. So it never gets adjusted when reality changes.
- The solution sits outside the systems people work in daily. So it does not get used, however good it is.
- The expectation was that it would save half a department. It will not, and the disappointment kills the project.
On policy and guidelines
Most companies I meet either have no guidelines for AI, or a memo nobody has read. Both end with people using AI anyway, just without it being agreed.
I am happy to help write something short and usable: what may be put where, what needs checking, and who to ask. Two pages people actually read beat twenty sitting on the intranet.
Deliverables
What you get
Concrete deliverables, not a report of recommendations someone else has to find time for.
- A map
Where in the business there is genuinely something to gain, and where there is not. Based on talking to the people doing the work, not only to management.
- A measured baseline
How long the task takes today and how often it happens. Without that number you cannot decide afterwards whether anything improved.
- A first solution in production
One area, four to six weeks, used by real people. Not a platform meant to cover everything from day one.
- Guidelines
Two pages on what may go where and what needs checking. Short enough that people actually read them.
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 implementation
Why most AI projects stall
It is rarely the technology. The models have become good enough for most ordinary tasks, and the technical work is manageable. Projects die somewhere else.
The most common cause is that the solution sits outside the systems people work in daily. If there is a new tab you have to remember to open, it does not get opened. After a fortnight usage has dropped to the three enthusiasts who helped build it, and after two months it is zero. This is not resistance to change — it is that nobody has time to remember one more thing.
The second most common is that nobody owns the project after launch. There is a project group up to go-live, and then it dissolves. Reality then changes — new products, new rules, a new way of phrasing cases — and there is nobody to adjust it. Quality drops slowly, people stop trusting it, and then it is dead.
The third is expectations. If a pilot was sold internally as something that would halve a department's workload, a twenty percent improvement is a disappointment, even though twenty percent is a great deal. I try to get expectations written down beforehand, precisely because they otherwise grow on their own.
Where to start
Look for the work that repeats many times a week, follows a fixed pattern, and annoys the people doing it. All three have to be true. Repetition gives enough volume to justify it. Pattern makes it buildable. And the annoyance ensures somebody actually wants to adopt it.
Avoid starting with what is most visible to management. The customer service bot on the front page is tempting because it can be shown off, but it is also where a mistake costs most and where expectations are highest. Start internally, where you can learn without it costing customers.
And keep it small enough to change your mind. Four to six weeks, one area, and a real decision afterwards about whether to do more. Being locked into a two-year platform agreement is worse than having spent six weeks on something that did not work.
Reviews
What people say about me
Mikkel is a man after my own heart. Executes at lightning speed, has an eye for detail and is always there when you need him. It does not get better than that.
Tini Owild(translated from Danish) He is simply a pro. Highly competent and precise, brings good input, and is a huge support.
Carsten Johan Thessen(translated from Danish) I have never come across a developer as dedicated and capable as Mikkel.
Jonas Krogslund(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
- How big do we need to be for this to make sense?
- There is no lower limit on headcount. What matters is whether there is a piece of work repeated often enough. A ten-person company can easily have one.
- Can we start small?
- It is the only way I recommend. One area, four to six weeks, and a decision afterwards about whether to do more. Large platform projects meant to cover everything from day one almost always end badly.
- What about the EU AI Act?
- For most ordinary uses the requirements are manageable, but they depend on what the system is used for. I am not a lawyer and will say so if you need one involved.
- Do we need our data in order first?
- Not all of it. But the data the first solution needs has to be retrievable and reasonably trustworthy. If it is not, the cleanup is part of the project, and it belongs in the timeline rather than arriving as a surprise.
- What if staff are sceptical?
- Then they are usually sceptical for a reason, and the reason is worth hearing. I always talk to a couple of people on the floor first, and their objections are often the most useful information in the whole engagement.
- Can we use what we already pay for?
- Often yes. If you have Microsoft 365 or Google Workspace, there are AI features included that cover a fair range of ordinary needs. I say so before proposing to build anything new.