Eclipse Holdings Group Eclipse Holdings Group

Belgian software atelier

We build the app. You watch it ship.

Eclipse Holdings Group is a software development studio based in Belgium. We build mobile apps, desktop applications and web products for businesses — and we stay on the project after release.

Start a project conversation See how we deliver

Brussels · working hours Monday to Friday, 9:00 AM – 6:00 PM

Services Stack Support
Blueprint-style drawing of a phone and laptop on a workshop bench with copper boards and a soldering iron.

Bench view · live build

The same window the studio ships to a client, held open mid-work.

Stack shelf · the choices we make

Frameworks written down, not assumed

Every stack decision on a project is documented during scoping, with trade-offs the client can read. The rail below names the tools we actually reach for — nothing decorative, nothing claimed that isn't shipped.

Read about our stack

The tools we reach for

  • React Native
  • Expo
  • Flutter
  • Tauri
  • Avalonia
  • Supabase
  • Firebase Test Lab
  • Fastlane
  • GitHub Actions
  • Sentry
Close-up blueprint drawing of a copper trace on a circuit board with via holes and a lit indicator.

How a project actually runs

The bench in eleven honest rows

Not a pitch deck — a working list. Each row is one thing we do on a real engagement, written so a business reader can judge whether it fits their situation.

Mobile iOS & Android Most mobile work ships from a shared codebase — React Native with Expo for the majority of cases, Flutter when the interface leans on animation. one codebase Desktop Windows · macOS · Linux For work that stays at a desk — local files, scanners, label printers, weighing equipment. Tauri for small binaries, Avalonia when the surroundings are .NET. native installers Web Connected products External audience, unknown devices, no install: the web app is often the front end to the same backend the mobile app already uses. shared logic Scoping Two to four weeks A written scope, a screen inventory and a build sequence. Nothing gets built during this phase, which is deliberate — it is cheaper to find the three approval exceptions now. before code UI/UX Runs in parallel Wireframes, then a clickable prototype, then the visual layer. Dutch, French and English get decided here, before the interface hardens around one language. states defined Sprints Two-week cadence Every fortnight ends with something you can install and open — running against a test database, not a demo with fake data. If a sprint ends empty, ask. installable Testing Real devices Firebase Test Lab against a matrix of devices and OS versions, plus handsets in a hand — camera behaviour and Bluetooth pairing are not judged by an emulator. hands on Release Fastlane + Actions Certificates, provisioning profiles, version numbers and release notes are automated, so the gap between "the fix is done" and "the fix is on your phone" stays short. repeatable Monitoring Sentry wiring Runtime errors arrive with a stack trace, the device and the version — an invisible crash becomes a fixable issue with a name, not a vague complaint. traceable Maintenance After launch OS updates, store policy changes, dependency upgrades and the small feature requests that always follow real usage. Launch is the midpoint, not the finish. ongoing Where Belgium, in person Meetings in your timezone, in Dutch, French or English; contracts under Belgian law with Belgian invoicing. Remote runs on the same sprint rhythm. Brussels studio

Delivery timeline · four sprints, one release window

The full process Start a conversation

What each fortnight looks like

Development runs in two-week sprints. The window above stays put; the columns below travel past it. Each column carries the artefacts a client can actually see at the end of that stretch.

Sprint A · weeks 1–2

Foundation

  • Kickoff card and agreed screen inventory
  • First installable build on a test database
  • Written note on what changed and what's next

Sprint B · weeks 3–4

Main flows

  • Clickable prototype signed off
  • First backend integrations connected
  • Empty, loading and error states defined

Sprint C · weeks 5–6

Test pass

  • Firebase Test Lab run across device matrix
  • Physical handsets on camera and Bluetooth
  • Regression fixes folded back into the build

Sprint D · weeks 7–8

Release candidate

  • Fastlane pipeline rehearsed end to end
  • Store submissions prepared with certificates
  • Sentry wiring verified before launch
See how we deliver

No fixed package, no surprise invoice line. Time on the bench, invoiced against work that has been shown.

Stack selection, written down

The three choices that matter

Two decisions repeat on almost every project: which framework carries the front end, which backend holds the data, and how the release gets out the door. This is how we compare them with a client before a sprint starts.

Framework Fits when Choose instead if
React Native + Expo Team familiarity, fast iteration, most business apps Flutter — when animation or custom rendering carries the product
Flutter Animation-heavy interfaces, unusual rendering needs React Native — when the JS ecosystem or team skill decides
Tauri Small binary, web technology on the front end Avalonia — when the surrounding systems live in .NET
Avalonia .NET shop, IT department reads and maintains the code Tauri — when the front-end team is strongest in web tech
Supabase Postgres-shaped data, auth, realtime, clear SQL Firebase — when push, analytics and mobile SDKs dominate
Firebase Mobile-first features and a mature device test lab Supabase — when the data model wants a relational core

A typical decision, rendered

  • Front endReact Native + Expo, one codebase, one release pipeline
  • Data layerSupabase — Postgres schema shared with the web front end
  • ReleaseFastlane + GitHub Actions, certificates and version numbers automated
  • After launchSentry monitored, maintenance retainer, monthly review

The trade-offs behind every choice above are written down in the scoping document, so you can read them before a line of code exists.

"Most of our clients arrive with a process that lives in spreadsheets and email, and leave with something their staff actually opens every morning."

Eclipse Holdings Group · Brussels

Blueprint-style drawing of a hand holding a small tablet on a workshop bench next to copper boards.

Bench top · checking what a user sees

Support & maintenance

The bench keeps running after launch

Four bays of care, each with its own rhythm. Every app we ship lands in all four within the first weeks after release.

Monitoring

  • Sentry wired into every release, errors surface with a device and version
  • Weekly reading of what fired, triaged against severity
  • Alerts routed to the studio, not to your inbox

Security patches

  • Dependency upgrades reviewed against the shared backend
  • OS-level changes tracked and tested before they bite
  • Store policy changes handled as part of the retainer

Release cadence

  • Fastlane pipeline kept green between feature work
  • Patch releases shipped on a rhythm you can plan around
  • Small feature requests slotted into the same track

On-call

  • Belgian working hours, Monday to Friday 9:00 to 18:00
  • Direct line to the developer who last touched the code
  • Critical issues come first, and stay there until closed

Before you write

Common questions

The four questions a business reader usually asks before sending a first message. If yours isn't here, the phone number works too.

Do you build native apps or cross-platform?

Mostly cross-platform, because one codebase and one release pipeline suits most business products. We recommend native code when the app depends heavily on platform-specific hardware or performance-critical work. The decision is documented during scoping, not assumed.

How long does an MVP take?

It depends on scope, integrations and how many systems the app has to talk to. A focused mobile MVP with one backend and no legacy integration is a different project from a tool that must read from three existing platforms. You get a calendar in the scoping phase, before development begins.

Can you take over an app someone else built?

Yes, and it starts with a review of the codebase and the current release setup. Sometimes the answer is to continue and improve it; sometimes it is a rebuild. We will tell you which one, with reasons.

Do you work with clients outside Belgium?

Yes. We are a Belgian company and most of our meetings happen in Belgian working hours, but remote projects run on the same sprint schedule.

Where to start

Send us the problem, not a spec

If you have a process that is outgrowing its spreadsheet, or an app that someone else built and nobody maintains, send a short description of the problem. You do not need a specification or a wireframe. The first reply will be a few questions, and if it looks like a fit, a scoping conversation. If it does not look like a fit, we will tell you that too, and point you somewhere more useful.

Start a project conversation Meet the studio

Or reach us directly