Ralf built CARIM because the tools that existed were asking FutureLab to become a different company in order to use them. Four different tabs open at once, too many fields, too many clicks, and too many assumptions baked in about how tasks should be categorised and who should own them. The team ended up using each tool for a different purpose on the same projects, which created exactly the kind of fragmented picture you buy software to avoid.
CARIM is built around five things: what the task is, who owns it, what it is connected to, who the client is, and how you know when it is done. As we used it, extra fields got added when we realised there were things we needed to track that we had been missing. Now everything sits in the same system and connects to each other. If we need a change, we ask for it. If a client needs a feature, it is a simple email. Sometimes the changes are things like adding a daily message with silly dad jokes to lighten the mood. But more importantly, there are no mandatory workflows that force the team to do things in a way that does not match how they actually move. It is fast to update and hard to overthink, which is why people use it, and why we have managed to bring the entire FL team onto it along with a couple of clients. When giving updates, clients can log in to see how tasks are progressing and leave comments directly.
The interesting part is not the tool itself. It is the principle behind it: a system should fit the organisation, not reshape it.
The real problem with most digital tools
What we built for ourselves with CARIM reflects something we have seen consistently when building systems for other companies. Most digital tools arrive with a fixed idea of how a business should work. They have a logic and a structure that can be inflexible and hard to understand, and because each tool organises information differently, you can end up with multiple versions of the same data living in three different places. The expectation is that the organisation will adapt to the tool, not the other way around.
When the tool’s logic happens to match how a team already works, that is fine. When it does not, what follows is predictable: the tool gets used for two weeks, creates more friction than it removes, and everyone quietly goes back to the spreadsheet without much discussion. Nobody makes a decision to stop. The tool just stops being opened.
The most important question before building anything is not how the system should work but how the organisation actually works right now, and whether the solution being proposed genuinely respects that.
And then AI walked in
Because CARIM is flexible and built on a structure that AI can read, something opened up that we had not originally planned for, and it has turned out to be the most useful part of the whole system.
Every morning, a bot posts in the team Slack channel with a suggested task list for the day. You review it, approve it, and get redirected to CARIM where you can see your suggested plan, add or remove tickets, and adjust priorities before the day begins. Once you are happy with it, you post your plan to a public channel where every team member can see what everyone is working on. No status meeting required and no chasing anyone for updates.
From there, the rest of the day lives in a Kanban board. Tickets move as you work through them, time is tracked automatically, and the whole team has visibility on where things actually stand rather than where someone said they were in the last meeting.
Working with Claude or ChatGPT connects directly into this. You can create a CARIM task from a conversation, turn emails or Slack messages into tickets, or ask for a plain-language summary of what is open. The AI does not replace the system. It plugs into it and makes the parts that used to take time take almost none.
That is what we mean when we say a system should fit how you work. We did not change how the team communicates or how we track work. We built something that connects those things and lets AI sit on top of it in a way that is actually useful.
The resistance that makes sense
Knowing all of this, it is easy to look at a team that is reluctant to move away from their current system and see the problem as stubbornness. In our experience, it almost never is.
When creating software solutions for companies, we encounter a version of the same conversation more often than not. Someone, usually the person who has been there longest, says: we have always done it this way and it works. And they are not wrong. It does work. That is exactly why it is so hard to move away from it.
We have learned to stop treating that reluctance as an obstacle and start treating it as information. When a team resists digitalising a process, it almost always means one of two things: either the process is more complicated than it looks from the outside, or they have been burned before by a tool that promised to make things easier and made things worse. Both of those things are worth paying attention to before proposing anything.
What happens when a system actually fit
When a tool respects how an organisation already works, something changes that is genuinely hard to predict until you have seen it. The team stops managing the tool and starts using it. Data stays current not because there is a meeting reminding everyone to update an app, but because updating it is fast and the workflow is clear. Decisions start being made from information rather than from memory and instinct.
That last part is the real value. Not the automation or the dashboards, but the fact that you can finally see your operation clearly. Once you can see it, you make different decisions. Not because the system told you to, but because you have the information to.
We have seen this pattern in projects where the system was built around the organisation rather than the other way around. The adoption is faster, the complaints are fewer, and a couple of months later people genuinely cannot remember how they managed before. That is the signal you got it right.
The thing worth saying out loud
Digitalising your business does not mean changing how your organisation works to fit a platform. It means finding or building a platform that fits how your organisation actually works, and then using it to see things you could not see before and do things that were not possible before.
The companies that get this right do not end up looking like they went digital. They end up looking like a sharper version of themselves. Same people, same knowledge, same culture, just with better information, less time spent on things a system should be handling, and occasionally an AI that knows your task list better than you do.
If your team has been resistant to a tool or a process change, it is worth asking whether the tool is actually the problem. In our experience, it usually is.
Invent the future with friends
