Qt development in Gothenburg — for industrial products, embedded, and desktop

Intunio is a design and development studio in Gothenburg. Qt is the framework we choose when software runs close to the hardware: operator panels, on-product screens, control interfaces, and desktop applications that need to behave identically on Windows, Linux, and macOS. We build the interfaces in QML and the logic in C++.

Qt development here follows the same principle as all our app development: designers and engineers share the backlog from day one. That matters even more in Qt projects, where the interface often lives on a physical product and every design decision is also a decision about performance, hardware, and certification requirements.

What we've done with Qt

We've built Qt-based software for clients like BlackBerry and Axis — products where performance, security, and long-term maintainability were requirements from day one. That experience is what we bring into every Qt engagement: interfaces that work close to the hardware, in products that live for a long time.

When Qt is the right call

Qt is rarely the first framework mentioned in an app project — but in some situations it's the obvious choice:

• The interface lives on a device. Operator panels, instrument clusters, medical equipment, on-product screens. Qt is built for embedded Linux, QNX, and other platforms close to the hardware, and performs well on constrained hardware without the interface feeling sluggish.

• The same application needs to run on desktop — on every OS. One Qt codebase ships to Windows, Linux, and macOS, with native performance and no browser in between.

• Performance and real-time behavior are requirements, not wishes. Qt combines declarative UI in QML with logic in C++ — graphics-heavy views, real-time data, and hardware-level integration in one application.

• The product will live a long time. Industrial products are maintained for ten years or more. Qt has been around since the '90s, is owned by a listed company, and is used by companies like Bosch, LG, and Rockwell Automation — a choice you can stand behind over time.

Qt is less right when the product is a pure mobile app — Qt can ship to iOS and Android, but native or Flutter is usually the better call there. And when the interface is a web product, we look at web instead. We pick the tool to fit the product, not the other way around.

What we do

• QML and Qt Quick development: declarative, graphics-heavy interfaces with full control over the expression — from design system to pixel

• C++ integration: application logic, integration with existing C++ backends, drivers, and protocols

• Industrial interfaces and HMI: operator panels, control interfaces, and monitoring views — in close interplay with our industrial UX service

• Cross-platform desktop: one codebase for Windows, Linux, and macOS

• Embedded targets: Qt on embedded Linux and other platforms close to the hardware, tuned to the screen, memory, and CPU budget

• UX and design for Qt products: we design the interface and build it — same team, same backlog

Design and engineering belong together — especially in Qt

Qt projects rarely fail on the technology. They fail in the gap between design and reality: the interface is designed in front of a screen in an office, but used with gloves, in glare, on a factory floor. That's why we don't do handovers: the designer drawing the operator view sits in the same team as the engineer implementing it in QML.

QML makes that collaboration concrete. The interface is described declaratively, which means a design system translates almost directly into components in code — the same thinking that makes us like Flutter on mobile. Design decisions become testable on real hardware early, not at the end of the project.

How we work

A Qt project follows the same setup as the rest of our development: pre-study, design and technical foundation, sprint-based development, release and maintenance — with designers and engineers in the same team. We often start with a pre-study that lands scope, architecture, and whether Qt really is the right call before a line of code is written. If a Qt codebase already exists, we like to start with a product validation that gives an honest picture of the current state.