The future of digital

Choosing the services

To build a truly sovereign European cloud stack, we needed a provider that could compete with the feature sets of US tech giants while keeping data strictly within European borders. We chose Scaleway as our foundation. 

To create a highly available, production-ready environment, we selected the following core services:

• Containers: Managed Kubernetes (Kapsule) to handle orchestration effortlessly, backed by their own Container Registry to store Docker images.
• Database: Managed PostgreSQL to ensure data persistence with automated backups.
• Storage: S3-compatible Object Storage for static assets and secure backups.
• Networking: VPCs and Private Networks to ensure isolated, secure communication between resources without exposing them to the public internet — with a ssh-bastion service out of the box!
• Domains & Web Hosting: DNS management for easy access to our publicly exposed services, with the option to acquire additional domains natively.

Challenges and our solutions

No cloud provider is perfect, and moving away from AWS or GCP comes with specific engineering challenges. US hyperscalers offer highly specific, fully managed niche services that Scaleway does not yet provide. We choose to default to open-source self-hosted tools on Kubernetes. For example, instead of relying on a proprietary AWS-managed service, we will use containerized alternatives directly on our Kubernetes cluster.

Here are the major tradeoffs we encountered and how we solved them.

1. AWS Loadbalancer Controller

The Challenge: AWS EKS comes with a dozen of add-ons and helm charts that integrate seamlessly out of the box. In our EKS stack, we heavily depend on the AWS Loadbalancer controller, so we needed to find a suitable sovereign alternative. 

Our Solution: Kubernetes Gateway API with Envoy Gateway

+------+    +---------+    +-------------------+    +-------------+    +------+

| DNS  | -> | AWS LB  | -> | K8S Ingress       | -> | K8S Service | -> | Pods |

|      |    |         |    | (annotations)     |    |             |    |      |

+------+    +---------+    +-------------------+    +-------------+    +------+

+------+    +---------+    +--------------------------------------+    +------+

| DNS  | -> | SCW LB  | -> | K8S GATEWAY API (Envoy Gateway)      | -> | Pods |

|      |    |         |    | (Unified Routing & SecurityPolicies) |    |      |

+------+    +---------+    +--------------------------------------+    +------+

With the official Kubernetes Ingress NGINX retirement we decided to implement the modern Gateway API straight away. On top of that we also had to choose for an implementation. For our implementation, we chose Envoy Gateway because it is feature-complete and industry-recognized. It gives us a great open-source alternative to AWS vendor lock-in. A major bonus is that we can now attach application-specific SecurityPolicies. This yields two massive advantages: first, it lowers the need to spin up extra cloud load balancers, directly decreasing cost; second, it shifts security left to the application layer, granting us fine-grained control.

Key Takeaway: We reduced cost and vendor lock-in while gaining increased application control and security.

2. AWS Certificate Manager

The Challenge: AWS Certificate Manager supports DNS approval with autorenewal.

Our Solution: Certmanager with Letsencrypt certificates

In our current AWS EKS setup we have a strict separation between application development and certificate management. While the latter remains an ops responsibility it collides with our shift left principles. We could just ignore that and move on with the Let’s Encrypt integration Scaleway offers out of the box. Unfortunately it lacks DNS validation and here’s the tradeoff. ACME HTTP-01 validation takes time, which can cause issues during service migrations. On the other hand DNS-01 validation has an ops dependency/bottleneck. Therefore we choose to implement Cert Manager for Kubernetes.

Key Takeaway: We empowered developers with Cert-Manager while keeping DNS control gated for complex migrations.

Coding the infrastructure

To make this proof of concept repeatable, auditable, and cost-effective, we strictly adhered to Infrastructure as Code (IaC). Hand-clicking in a console is fine for a quick test, but production requires automation. 

Terraform (cdktf): We used the official Scaleway Terraform provider to declare our VPCs, Kubernetes clusters, and managed databases.

OpenTofu & Pulumi: Since HashiCorp officially deprecated CDKTF in late 2025, evaluating the future of our IaC framework is on the horizon. While we are sticking with our current CDKTF setup for this PoC, the deprecation offers a perfect opportunity to reconsider the broader ecosystem and evaluate options like Pulumi or OpenTofu—but that is a subject for a whole separate blog post.

Leaning on open source frameworks has huge benefits when it comes to migrations. For us, it meant we could smoothly re-use our Kubernetes External Secrets Operator setup, making it easy to plug into our existing 1password integration. Of course, 1Password is not a European entity, but since their main headquarters is located in Canada, they are not subject to the US CLOUD Act. If we want to strictly sovereignize this later, we can switch to Scaleway’s native Secret Manager without hassle using their off-the-shelf Scaleway Provider.

Plugging in CI/CD

Once infrastructure was deployed we could start deploying workload.

Since our applications share the same reusable kubectl templates and helm charts, it was merely a small configuration exercise. Only a few modifications to our pipelines to manage authentication and authorization with our new Scaleway project were needed. Then we simply had to add new deployments with the appropriate configuration values in our Bitbucket pipelines and we could spin up our applications.

Last (but not least) bit in this exercise was migrating the data. However with our knowledge and experience, it was just a matter of a couple of CLI commands to push data from one S3 bucket to another and export-import a couple of databases.

Wrapping up

This proof of concept illustrates that European cloud sovereignty is no longer just a theoretical ideal or a compliance checkbox. It is a highly practical, cost-effective reality. By accepting a few engineering tradeoffs and leaning heavily into open-source tooling, we successfully built a first-class hosting environment capable of standing toe-to-toe with US hyperscalers.

The European cloud ecosystem is moving fast. While we initially bypassed queuing, IoT, and serverless options during our scoping phase, Scaleway’s rapid portfolio expansion means these services are already mature enough for production consideration today. Migrating away from the US tech giants no longer means compromising on engineering standards. It means taking control of your stack, shifting security left, and ensuring absolute data sovereignty on European soil.

What does an ISO 27001 certificate entail?

An ISO certificate is more than a badge. It’s official proof that an organization operates according to internationally recognised standards. ISO 27001 specifically focuses on information security, ensuring that data is handled responsibly, securely, and consistently across every process.

‍

Unlike common perception, it isn’t just about firewalls, passwords, or encryption. It’s about people, processes, and accountability. It ensures that information security is integrated into every layer of our organization, from HR and finance to software design and client delivery. It’s about embedding security into the way we think and work.

‍

As cyberattacks become a daily headline, they remind us how fragile digital ecosystems can be: data leaks, ransomware, systems brought to a halt. Meanwhile, regulations like the NIS2 directive are tightening across industries, making robust information security a requirement.For icapps, this certification confirms that information security is built into our DNA and into every digital product from day one.

‍

‍

Security in every layer

At icapps we’ve mapped out every process that could affect information security. Throughout this journey, security stopped being “someone’s responsibility” and became everyone’s mindset.

‍

It starts internally with clear policies, structured processes, and shared responsibility. We are certified across our full operational scope, meaning that every process within our organization, from HR and finance to design, engineering, and project delivery, adheres to the ISO 27001 standards. Take our joiner-mover-leaver process: when someone joins the team, they receive access only to the systems and data relevant to their role. When responsibilities change, so do access rights. And when someone leaves, all permissions are revoked immediately. It’s a simple principle that prevents small oversights from becoming big vulnerabilities.

‍

That same thinking flows into our projects. From the very first design phase, we ask:


• What kind of data will this platform process?
• Where will that data live?
• What safeguards are needed to protect it?

Our CI/CD pipelines automatically perform security checks, dependency scans, and code analyses to catch vulnerabilities early. Every product we build adheres to OWASP ASVS standards, which define best practices for secure application development.

This way, every release meets the same high standards for performance and protection.

The numbers & corporate adoption

• Market Dominance: Kotlin is used in 92% of Play Store apps, and 86% of Android devs call it their primary language.
• KMP Growth: The number of KMP apps in stores doubled over the past year, supported by 3,600+ ready-to-use libraries on klibs.io.
• Enterprise Trust: Google Docs has been completely rewritten in KMP as part of a full Google Workspace migration, and Google Search is largely converted to Kotlin. Sony also demonstrated successful, phased KMP adoption in complex setups.

Tooling & performance gains

Kotlin 2.4 has officially gone stable, bringing core features like context parameters and explicit backing fields into production setups. The tooling updates focus heavily on optimizing performance and widening the ecosystem:

• iOS & Build performance: Moving from Kotlin 2.2 to 2.4 yields a 25% reduction in build times and a 58% decrease in build RAM usage. Swift Export (now supporting suspend functions and Flows) and Swift Package Manager (SPM) integration have both successfully reached Alpha. Additionally, Liquid Glass UI-interop allows native components to blend seamlessly with Compose UI.
• New Ecosystem tooling: A new uniform Kotlin CLI, a streamlined project structure for production applications, and an Alpha VS Code extension are expanding Kotlin's footprint far outside traditional IDE boundaries.

Android is officially "Compose-first"

Google has officially declared Android Compose-first, shifting traditional Views to maintenance mode. Writing a native app in Compose today ensures a much easier port to Compose Multiplatform (CMP) later since the UI layer is already portable. On the multiplatform side, Navigation 3 is now stable, CMP for Web is in Beta (with accessibility and HTML interop), and Hot Reload for Desktop is stable by default.

How the Ecosystem validates the icapps workflow

The announcements from KotlinConf '26 didn't catch us off guard; rather, they heavily validate our long-term roadmap and internal standards.

We were already compose-first

While the broader industry is currently adjusting to Google's massive push toward Jetpack Compose and KMP, Compose-first has been our internal standard for years. A prime example is our work for Bolero.

By minimizing our legacy XML footprint early on, our architecture is already optimized for modern development. For our partners, this mature foundation means any future transition to KMP or CMP will be significantly faster, cleaner, and more cost-effective. To capitalize on this, we are executing immediate action items to phase out our remaining legacy XML Views and test how Android’s new CLI can augment our automated testing.

Navigating the AI Shift: SDD and EDD

With JetBrains shaping future AI tooling via the open Agent Client Protocol (ACP), software engineering is actively shifting away from manual coding toward two new structural paradigms:

• Spec-Driven Development (SDD): Writing highly precise technical specifications beforehand to act as a contract and regression check for AI agents.
• Eval-Driven Development (EDD): Setting up rigorous evaluation guardrails (such as "AI as a judge") to actively combat hallucinations and context drift.

Moving forward, we will actively investigate how to integrate these key insights and guardrails into our own AI SDLC workflow to broaden its power even further.

While we are experimenting with the new Android CLI and Journeys to see how automated agents can safely speed up routine testing, we are balancing this with a healthy note of caution. Conference leaders highlighted critical industry nuances, including ethical concerns, potential senior burnout from a shrinking junior pipeline, and impending pricing "rugpulls" as VC-subsidized AI tools inevitably shift to heavy usage-based billing. Our focus remains on using AI to augment, not replace, our strict quality standards.

The bottom line: What it means for you

• For Mobile Developers: The shift is absolute. Android is officially Compose-first, and KMP is rapidly narrowing the iOS gap with 25% faster builds and smoother Swift integration.
• For Tech Leads & CTOs: KMP is enterprise-proven. With Google migrating Workspace and Search to Kotlin, KMP has graduated from an experimental framework to a risk-reduced strategy for scalable architecture.
• For icapps clients: While we work purely native today, we are closely monitoring these advancements. We stand ready to adopt KMP and Compose Multiplatform (CMP) the moment the timing is right for your business.

‍

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

‍

‍