The future of digital
Discover the trends, tech, and strategic insights shaping tomorrow's digital landscape. Written by experts, curated for innovators.
.avif)
When Bluetooth devices compete: how we solve multi-device BLE challenges
The challenge most apps underestimate
Once the platform scaled, new needs emerged:
- Reliable location detection: To ensure users could always end their rides, even in GPS-poor environments like underground stations, we implemented Beacon technology as a vital fallback.
- Maintenance access: Service teams needed dedicated BLE access to battery locks for maintenance purposes.
Suddenly, the app wasn’t talking to one device anymore. It was juggling multiple Bluetooth interactions at the same time.
And that’s where things started to break.
One BLE radio, multiple demands
Smartphones only have one Bluetooth radio. Yet many apps treat it like an unlimited resource.
In practice, this leads to:
- Silent scan interruptions (especially on Android)
- Features interfering with each other
- Device-specific bugs that are hard to reproduce
- “Works most of the time” experiences that frustrate users
For platforms like Blue-bike, this directly impacts both user experience and operations. To solve this, we leveraged our partnership to build a robust architecture that treats Bluetooth as a shared system resource.
Our approach: treat BLE as a shared resource
At icapps, we’ve seen this pattern before across multiple projects. When apps evolve, Bluetooth complexity grows with them.
Instead of patching issues later, we design for it upfront.
The key insight is simple: Bluetooth should be managed like any shared system resource.
Meaning: just as a processor decides which app gets processing power, there needs to be a system that determines which function is allowed to use the Bluetooth antenna at any given moment. Without this central management, different parts of the app (such as unlocking the lock versus searching for beacons) will compete with each other for the connection, leading to failed actions and a frustrated user.
The solution: a scan coordinator
To prevent conflicts between BLE features, we implemented a centralized scan coordinator.
In short, it:
- Controls who can scan at any given time
- Assigns priorities (user actions over background processes)
- Temporarily pauses lower-priority scans
- Applies rate limiting to avoid OS restrictions
- Ensures consistent behavior across devices
This creates a predictable and stable Bluetooth layer, even as new features are added.
Why this matters for your product
If your app connects to just one device, you might never notice this problem.
But if you’re building:
- A connected product ecosystem
- A mobility or IoT platform
- A feature roadmap with future integrations
…this challenge will surface sooner or later.
And when it does, it won’t show up in testing. It will show up in production.
Designing for scale from day one
What we built for Blue-bike is not a workaround. It’s a scalable foundation.
By centralizing BLE coordination:
- User interactions become reliable
- Background processes stay invisible but effective
- New integrations don’t introduce new risks
Most importantly, it allows teams to keep innovating without breaking existing functionality.
What this says about how we work
This project reflects how we approach digital products at icapps.
We don’t just build what’s needed today.
We anticipate what your product will need tomorrow.
Because in connected ecosystems, small technical decisions can have a big impact on user experience.
If you’re working on a product with Bluetooth, IoT or multiple device integrations, it’s worth asking: Are we building for today’s use case… or tomorrow’s complexity?
FAQ: Bluetooth and multi-device BLE
What is multi-device BLE?
It refers to apps interacting with multiple Bluetooth Low Energy devices, common in IoT, mobility, and connected products.
Why does Bluetooth fail with multiple devices?
Because smartphones only have one BLE radio. Multiple scans or connections can interfere, causing unreliable behavior.
How do you manage multiple BLE interactions?
By using a centralized approach, like a scan coordinator, to control access, prioritize actions, and prevent conflicts.
What are common BLE issues in mobile apps?
Unstable connections, background limitations, Android restrictions, and conflicts between multiple Bluetooth processes.
When do you need a scan coordinator?
As soon as your app connects to multiple devices or combines background and foreground BLE features
All insights

European cloud alternatives: A shortlist of AWS replacements
Rather than listing every available option, we focused on providers that could realistically replace large parts of an existing AWS setup without disrupting modern development workflows. We are fully aware that there is no true drop in replacement for AWS and that a small number of services remain provider specific.
Instead, we deliberately focused on the areas where a well considered tradeoff is possible, aiming for a setup where at least 80% of applications can be deployed on either platform while prioritizing the most achievable wins.
How we defined “viable” European cloud alternatives
We didn’t start with vendors. We started with requirements.
Our selection was based on European initiatives that map cloud providers operating fully under EU jurisdiction. From there, we applied a set of practical criteria rooted in day-to-day product development.
Our non-negotiables:
- Kubernetes as a first-class citizen
- Managed database services
- Object storage as an alternative to S3
- Compatibility with CI/CD pipelines
- Scalability for internal and customer-facing applications
The goal was not ideological purity, but feasibility.
The shortlist
Based on this approach, three European cloud providers stood out.
Hetzner is widely respected for its cost efficiency and reliable infrastructure. However, it lacks the managed services needed for teams that rely heavily on Kubernetes and managed databases. That would introduce additional operational complexity, which made it less suitable for our use case.
OVHCloud offers an extensive and powerful portfolio. While that breadth is impressive, it also comes with complexity. Evaluating and adopting the right subset of services would require more effort than we were aiming for at this stage.
Scaleway struck the right balance.
Its services closely mirror common AWS workflows, particularly around Kubernetes, managed databases, and object storage. From a team perspective, this made the transition feel realistic rather than disruptive.
Why familiarity matters when leaving AWS
One of the biggest misconceptions about switching cloud providers is that everything has to change.
In reality, the closer a platform aligns with existing patterns, the lower the cognitive and operational cost for teams. Scaleway’s approach allowed us to keep our development philosophy intact while moving infrastructure under European jurisdiction.
What this shortlist tells us
There is no single “best” European cloud provider. But our first choice is Scaleway.
What this shortlist proves is that European cloud alternatives have matured. For organizations running modern, container-based workloads, moving away from US cloud providers is no longer a theoretical exercise.
Is your business truly protected under EU jurisdiction?
As Belgian companies navigate evolving privacy laws and the complexities of international data access, European alternatives have matured into powerful, high-performance solutions. Use this checklist to evaluate your current "Cloud Sovereignty" score and discover if a move to a local provider is your next best move.
What’s next in this series
In the next blog, we’ll move from selection to execution. We’ll share how we’re migrating applications to Scaleway and what that looks like in practice.

Artificial intelligence in construction: how we built intelligent roof analysis for SCOPR.AI
Understanding the goal of SCOPR.AI
SCOPR.AI is designed to automatically assess roofs by focusing on their structural quality and layout. The system looks at key architectural features like how straight the eaves, ridges, and tiles are. By using advanced computer vision, the platform aims to make roof inspections faster, safer, and far more efficient.
However, building an AI model that delivers fast and accurate predictions in real time comes with significant technical hurdles. Our development team ran into several complex challenges along the way, from optimizing the model for mobile hardware to ensuring cross-platform stability. Here is how we tackled these problems.
1. Making the artificial intelligence model fast and accurate
For SCOPR.AI to provide real value to construction professionals, it needed to be both precise and exceptionally quick. Achieving high precision often requires heavy computational power, which naturally slows down processing times.
To solve this, we used special compression techniques to streamline the AI model and clean up the data it processes. This allowed us to maintain high accuracy while significantly increasing speed and processing efficiency.
2. Getting artificial intelligence to run on mobile devices
Mobile devices have limited processing power and battery capacity compared to cloud servers, which makes running complex computer vision models tricky. If an AI model is too heavy, it slows down user devices and drains the battery rapidly.
Our team resolved this by converting the original AI model into a lightweight version using TensorFlow Lite. We applied advanced size-reduction techniques without sacrificing the integrity of the results, allowing the software to work smoothly in real time on standard smartphones.
3. Improving computer vision accuracy
AI models can occasionally make mistakes or misinterpret visual data, especially when analyzing complex outdoor structures from different angles. We wanted to ensure that SCOPR.AI provided the most reliable assessments possible.
To maximize performance, we experimented with different AI structures, integrated pre-trained models to boost baseline recognition, and fine-tuned the way the system processes raw images.
4. Making artificial intelligence predictions understandable
Raw data generated by an AI model is rarely helpful to an end user. While the system can detect lines and angles, that data must be structured into clear, meaningful insights for a contractor or inspector.
We applied mathematical analysis to the raw output of the AI. This translation layer turns complex data points into intuitive, actionable information that anyone can read on site.
5. Connecting artificial intelligence to different platforms
SCOPR.AI needed to deliver a consistent experience across different platforms, from native mobile apps to web applications, without any technical hiccups.
To build a unified ecosystem, we linked our core AI systems, which were built using Python and TensorFlow, with Flutter for the mobile interface and Django for backend operations. This architecture ensures smooth, reliable communication between systems.
6. Creating a scalable system architecture
An intelligent application requires a solid backend system capable of handling multiple requests simultaneously and delivering predictions instantly.
We built a robust API using Django to act as a digital bridge between our systems. This allows the AI model to communicate seamlessly with different applications, ensuring the platform can scale as the user base grows.
7. Keeping the artificial intelligence model up to date
Machine learning models can become less accurate over time if they are not continuously updated with fresh data. This phenomenon, known as model drift, can compromise the reliability of structural checks.
We solved this by creating an automated retraining pipeline. This setup allows the system to learn from new data inputs continuously, meaning the artificial intelligence improves and adapts over time.
Building smarter digital products
Building SCOPR.AI was a journey full of technical challenges, but each obstacle provided an opportunity to innovate. From making computer vision mobile-friendly to ensuring long-term model accuracy, our team learned how to perfectly balance speed, efficiency, and scalability.
If you are currently planning an AI project or looking to modernize your current systems, these engineering lessons can help you build smarter, faster, and more adaptable digital solutions.

Why inclusive design is the key to creating better digital solutions
What is inclusive design and why does it matter
Inclusive design is a framework that addresses the full spectrum of human diversity. This includes physical, cognitive, and emotional capabilities, as well as temporary or situational limitations. For example, a person trying to read a screen in bright sunlight experiences a situational visual limitation, much like someone with a permanent visual impairment faces a physical one.
When you design with these diverse scenarios in mind, you inherently create a product that is cleaner, easier to navigate, and more intuitive for every single user. At our agency, we believe that technology should empower people, not create barriers. By adopting an inclusive mindset from the very first wireframe, we build digital products that are naturally more flexible and resilient.
How accessibility improves the overall user experience
Many businesses treat accessibility as an afterthought or an extra feature to implement later in the development cycle. However, integrating accessible design principles early on elevates the entire user interface. Clear typographic hierarchies, high contrast ratios, and intuitive navigation loops benefit everyone, not just those using assistive technologies.
- Enhanced readability: Clean spacing and straightforward typography help users process data faster and with less cognitive strain.
- Better navigation: Logically structured layouts and clear interaction points make mobile applications easy to navigate with one hand.
- Increased reach: Making your platform usable for people with different needs opens up your business to a massive, loyal audience that is often underserved.
Turning strategy into action with Febelfin
A great example of this is our work with Febelfin, the Belgian federation of financial institutions. They wanted to tackle the digital gap in banking services and reach communities who are digitally vulnerable. Through research, stakeholder interviews, and a digital product strategy workshop, we identified low threshold, feasible solutions to support these audiences.
These included simplifying access to reliable information about online banking and fraud, both directly for users and via partner networks. By mapping pain points and barriers, Febelfin gained concrete steps to make digital banking safer, more understandable, and more inclusive for everyone.
Three ways to integrate inclusivity into your digital strategy
Implementing a truly inclusive design process requires a shift in how your team approaches product development. It is not an overnight fix, but rather a continuous practice of learning, testing, and refining.
- Involve diverse user groups in testing: Do not make assumptions about how people interact with your software. Gather feedback from users with varying abilities and tech savviness early in the prototyping phase.
- Prioritize clear content hierarchy: Use straightforward language and structural headings to guide users through their digital journey naturally.
- Design for multiple input methods: Ensure your product can be easily navigated via touch, voice commands, keyboards, and other assistive hardware.
Building digital experiences that empower everyone
The digital landscape changes quickly, but the need for human centered design remains constant. When we build digital tools that value every individual, we create experiences that feel personal, impactful, and trustworthy. Inclusive design is not a limitation on your creativity; it is a catalyst for innovation that drives better business outcomes and happier users.

AI as your coding partner: insights from our GenAI research
“The research started as a simple idea: compare several GenAI tools that have generated a lot of buzz lately,” explains Maarten Anckaert, our Innovation Manager. “At icapps, we encourage our developers to experiment, but we also wanted to list the tools that genuinely empower experienced developers. Most online comparisons focus on tools for people without a technical background. We wanted to do it differently: which tools actually help our developers work smarter, free up time for what they enjoy, and create real value?”
To structure the research, we set up a clear baseline project and divided the tools into three categories. To make the comparison more tangible, we coined our own names for these categories. Simple labels that capture the level of guidance each tool provides:
- Hold-your-hand tools: Lovable, Bolt and Firebase Studio
- Code-first tool: Claude CLI
- Middle-ground tools: Cursor and Co-pilot via Visual Studio Code
Each category tackled the same set of tasks, small enough to explore the tool in a limited timeframe, but realistic enough to replicate our daily workflows. Every tool was examined in depth: what works, what doesn’t, and how developers can maximize its potential. The goal wasn’t just testing functionality, it was understanding how AI can genuinely boost productivity, creativity, and control in real development workflows.
“AI isn’t here to replace our developers, it’s here to be a strategic partner. Our research shows how to leverage these tools wisely, so teams can deliver smarter, faster, and with greater impact”, Maarten concludes.
Want to explore the full results and insights from our research?
Clarity to your digital challenge?
Whether you’re modernising a complex IT landscape or building a digital product that must scale and last, it always starts with the right conversation.