I’ve spent my career between business and technology.
I’m Dennis Cassøe, founder of FluxQ. I help leadership teams make technology decisions with the business outcome in view.
More than two decades from code to company.
01Developer
02Architect
03Technology / product leadership
04Founder
05SaaS company builder
06Acquisition
07Data & analytics
08FluxQ
Over more than two decades I’ve worked with technology from several sides: building software, designing systems, leading technology, building companies and helping others work through difficult decisions.
Operating technology
At Wupti I spent approximately five years in technology leadership, managing a team and working across the systems behind what was then one of Denmark's larger online retailers, from customer-facing platforms to integrations, fraud detection, pricing automation and data.
It was an early lesson in something I have seen repeatedly since: technology decisions rarely stay inside technology. They quickly become questions about processes, data, people, economics and operations.
The titles changed over time, but the recurring problem did not: how do you make good technology choices when the business is changing?
WakeupData
One of those journeys became WakeupData. It was international from the beginning. I co-founded the company and helped build it with colleagues from different countries and backgrounds over roughly a decade, before it was acquired by Channable.
That international mix was deliberate. People with different experiences saw problems differently and challenged assumptions the rest of us might not even realise we were making.
I have never minded losing an argument, whether to an intern, a colleague or a CEO, if their argument was better. The point is not to be right; the point is to arrive at a better decision.
When WakeupData was acquired, one of the things that mattered most to me was that the international team stayed on. WakeupData was not something I built alone. It was something we built together, and much of what it became came from many people bringing different abilities and perspectives to the same problems.
Short, focused advisory work
Alongside full-time roles and companies I've built, I've periodically been brought into shorter engagements to help companies work through specific technology and business questions. Some lasted a few hours, others days or weeks.
The common thread was rarely 'build this feature'. It was usually closer to: What should we build? How should this fit the rest of the business? What needs to integrate? What is the simplest viable approach? And what will this decision mean later?
Not everything I've built worked.
I've started and worked on several products and companies over the years. WakeupData became a successful SaaS company and was eventually acquired. Others never became sustainable businesses.
I consider both useful experience. Building software is often the easier part. Finding a problem important enough, a solution simple enough and a business model strong enough to make it last is harder.
Good decisions make more sense when you understand how the current situation came to exist. I’ve built systems, inherited systems, changed systems and led people responsible for systems. That is a big part of why FluxQ starts with context before recommendation.
Leadership outside technology
Alongside my professional work, I serve voluntarily as chairman of Fællesrådet for Tilst, True og Skjoldhøj.
The role involves representing local interests and working with the municipality, residents, organisations and other stakeholders on questions such as urban development, infrastructure, traffic safety and local facilities.
A significant part of that work is analysis. Over the years, I have submitted numerous analyses and proposals to Aarhus Municipality, with an emphasis on establishing the facts, documenting the reasoning and making the consequences of different choices visible.
Those contributions have generally been received constructively, and I have often had feedback afterwards from both the administration and elected representatives that the analysis was useful. In several cases, the work has also contributed to changing the direction of decisions or proposals as they developed.
That matters to me-not because everyone needs to agree with my conclusion, but because good analysis should make a difference. It should improve the basis for a decision, expose consequences that might otherwise be overlooked, and help move the discussion toward a better outcome.
There will inevitably be disagreements. My approach is to keep those disagreements focused on the issue rather than the people involved. You can challenge a proposal, an assumption or a conclusion quite strongly while still respecting the people on the other side of the table. The objective is not to win an argument. It is to improve the situation and find a way forward.
Part of the reason I spend time on voluntary work is simpler. I believe we should try to leave things a little better than we found them. That may sound slightly idealistic, but I mean it quite practically. I have become increasingly convinced that there is only so far any of us can move things on our own. If you want something to improve, at some point you have to contribute rather than just have an opinion about it.
It is very different from software, but many of the habits are the same: understand the history, work from evidence, listen to different perspectives, challenge assumptions without making disagreement personal, make the consequences visible, and keep working toward a practical outcome.
Education and technical grounding
My background is cand.merc.(dat.), an interdisciplinary MSc that combined business administration, information systems, organisation, economics, project and technology management, strategy, implementation, psychology and law. It shaped how I think about how organisations choose, implement, manage and get value from technology.
My perspective is also grounded in hands-on engineering. I spent a substantial part of my career building software, working with databases and designing systems before moving further into architecture, product, leadership and business. I also spent roughly two years teaching SQL and database design.
Outside work
I’m married with three children. I run for the exercise, which does end up taking a few hours most weeks, and I have a somewhat darker sense of humour than this website probably suggests.
What history taught me
One lesson from working across companies and roles is that the current system always has a history. Decisions that look strange today were often reasonable responses to yesterday’s constraints. I want to understand that history before recommending the next move. The goal is not to preserve old decisions; it is to avoid throwing away the context that explains them.
Principles
Technology decisions are business decisions.
Understand history before prescribing change.
Curiosity before certainty: start with questions, distinguish what we know, what we assume and what remains uncertain.
Business before technology.
Simplicity over unnecessary complexity.
Independent advice.
Long-term consequences matter.
FluxQ is my independent company for selected advisory work. It is deliberately small today. If you work with FluxQ on an advisory engagement, you work with me.