An independent studio in Aarhus building AI products for everyday life.
Run by Dennis Boehme — Engineer for Product Development and Innovation, living and working in Denmark since 2014, AI & Operations Lead by day. I build by directing AI tools, LLMs and agents rather than writing code, which means no excuses to experiment and get fast results.
AI-generated · can be wrong · questions are saved · don't type anything personal · privacy
Everything destbo labs has started, including the parts that didn't survive.
One person, in my spare time. A lot of what gets started here will never make it to a finished product, which is the whole point of running it as a studio — or a sandbox, as I tend to call it. The log stays honest so the shipped things mean something. And everything counts as learning.
This website. The question behind it: can someone who directs AI tools rather than writing code produce something that reads as deliberate rather than generated?
Everything here — the design system, the copy, the structured data, this log — was built by working with AI agents against a written brand file and a decision record, then verified against the actual files rather than against what the conversation claimed. The failures are part of the record: a patch that did not match its own description, a database field silently emptied while reporting success, a photograph still carrying GPS coordinates.
The method is the experiment. This page is only the artefact.
An AI assistant that lives in iMessage and helps a family run the household: calendars, birthdays, appointments, kid logistics, groceries, the invisible admin. No new app, no complicated signup, no group chat that quietly turns into a to-do list nobody reads.
Built EU-first on data sovereignty: European hosting, a written retention rule, and no training on family data. In private testing with real households.
A planner and log for gym sessions, on my phone, backed by a Google Sheet. Three of the four programs come from my own health plan — paired supersets, zone 2 cardio, and an abs pair that rotates so I get a different one each session. The fourth I build myself from the exercise library. It records reps and weight for every set.
The part that makes it more than a spreadsheet is that the log feeds the plan. It proposes which program to run next based on what I have already done, and on the progressive overload exercises it tells me what to put on the bar that day instead of leaving me to remember. Settings hold my own numbers and the increment per exercise, and where it makes sense I can switch a lift between dumbbell and barbell.
It started as a Google Form, which I abandoned once it was obvious that a nine-exercise session meant submitting the same form twenty-seven times. Most of what came after was failure. An exercise-illustration API returned the wrong pictures and was ripped out. A single two-thousand-line file broke twice from duplicate declarations and had to be rewritten from scratch. And for two sessions the backend silently wrote nothing at all, because the script was never bound to the spreadsheet.
That last one is the entry worth reading twice. The app called the server with no-cors, which meant it could not read its own error — so it showed a green success screen every time while saving nothing. One big learning.
A Claude project that turns one person's health information into an individual plan. Two parts: an instruction set defining how to read the input and what to produce, and a bilingual English and German questionnaire — 57 questions across eleven sections, covering medical history, injuries and mobility, diet, sleep, stress, mental wellbeing, budget and equipment. The intended output is two documents: a master plan and a weekly tracker.
It began as a plan I built for myself and then generalised. The design constraint is that it adapts rather than templates — age, hormonal status, culture and religious diet, budget, equipment access, disability and mental health history all change the output.
The first run on someone other than me found the weak point immediately. The questionnaire alone did not produce a workable dataset: one section came back barely filled in, a page of an attached document was missing, and several values the plan depended on were absent. Closing the gap took a purpose-built six-page follow-up, seventeen questions and a second round trip. For anyone with a complicated history, intake is not one step — and the second step currently has to be written by hand each time.
Started roughly twenty years ago. The expectation was that there would eventually be a free weekend. There has not been a free weekend.
I go deep and want to understand how things work. That started early enough that my dad still tells the story.
He brought home one of the first laptops either of us had seen. I figured out how it functioned faster than he did, so after I could show him. I was a kid at the time, but I've been doing a version of that ever since. Opening things up to see what's actually inside and understand how it functions. This is more or less what I do now for a living, but in a more complex setting.
I collected comics from six to roughly eighteen and never really stopped. Marvel came first, Spider-Man and X-Men, then manga and anime as a teenager, both of which I still read and watch today. The manga is what made me curious about Japan, its history and its culture. I especially value their attention to detail — the honour in craftsmanship, the care put into services nobody would have complained about anyway. That standard sits somewhere behind how I work and build things.
I studied five months in Shanghai during my bachelor's and spent three weeks travelling China afterwards — Beijing, Hong Kong, Hainan. That time abroad opened my eyes to the world and sparked the feeling that everything is possible. Six years later I spent two weeks alone in Japan, mostly Kyoto and Tokyo. In every city I ended up doing things with people I'd met that day or that week, and I'm still in touch with some of them. It carries into professional life too: I build relationships rather than collect contacts. If we met once and connected over a good conversation, I'd like to know what happened since.
Worth saying plainly: I failed the final retake of an exam in my Mechanical Engineering Bachelor and lost the programme. I had taken it too lightly, and never really failed at anything until that point, so it had a big impact. I walked out already knowing the answer, which was to switch to Industrial Engineering, carry the engineering subjects across, pass the business ones. It turned out to be the better fit. Better grades, and a great deal more ambition than I had before.
I can be direct. I would rather get to the point than circle it, and I prefer being told something doesn't work than being managed around it. That can read as blunt occasionally, but is definitely not meant unkindly.
destbo labs is the studio I run alongside my job — roughly ten hours a week, self-funded, deliberately small. When something works, it moves forward. When it doesn't, it stays in the log above.
Four things have to line up: the AI, the data, the process, and the people who use it.
My first experience as an engineer was at BMW, measuring car body panels on coordinate measuring machines. Quality assurance: the most literal possible version of checking whether a system does what it claims.
Then EffiMat in Odense, shipping automated storage machines to customers in Europe, the US and Asia — where the hard part stopped being the machine and became the coordination around it. After I joined helphouse.io, first as Project Manager, then Head of Operations with a team of eleven consultants and developers, and forty-odd implementations for Matas, Coop, Salling Group and many others.
Then four years as a Business Controller at Advansor and PowerMart, where I learned what it actually takes for a company to trust its own numbers: clear ownership, agreed definitions, and a lot of hard work underneath the dashboard.
Now I lead AI and operations at Dripdrop, a thirty-person hardware-as-a-service scale-up in Aarhus. I own how the company adopts AI — the framework, the team enablement, the EU AI Act posture, and the data foundation in the systems underneath. I also built Raindrop, a Slack assistant that queries our CRM, support desk and ERP and returns the answer to a question, correlations included.
That's my day job, and what I build there stays there. destbo labs is where I test the rest: new tools, new agent setups, small builds that answer a question I actually have. Most of them will probably not survive, which is the point of running it as a studio and keeping the log honest. The ones that earn their place get built properly.
Three things I know properly.
AI enablement & operations
Showing a team what is actually possible, and building the habit of reaching for AI when they hit a problem. Getting it out of the pilot deck and into the work people do every day.
AI governance & the EU AI Act
What the regulation requires, what it does not, and how to build so compliance is a property of the system rather than a document.
Operations & data
Processes, systems, integrations, and the teams working with them every day. Twelve years of navigating and improving all four, with the people at the centre.
That is where I go deepest, but it is not where it ends. Process design, systems integration, project delivery, reporting, and getting a team to actually use what was built — I have spent most of my career on those. If your question is close to any of it, just ask.
Building something in this direction, have a question you think I can help with, or want to test something I am working on?
Write to me. I answer my own email, and I am not shy about asking things back. If you are in Aarhus and building something, a coffee can be easier than a thread.
hello@destbo.com