What problem did this project solve?

A game server outage does not wait for the admin to sit down at a desk, and a client wants to order and pay for a server wherever they happen to be. We wanted to give the Flaem operator and client full control from a phone, but without a website wrapped in a WebView, with a native interface on each platform.

Separate native apps: Android in Kotlin and iOS in Swift; Operator on-call duty with alarms, a queue of cases and node status; A shop with a package, a billing period and BLIK payment; The client's servers with status, console and power actions that match the service type; Invoices, tickets, referrals and account settings; Push notifications that lead straight to the right screen; The same API as the panel in the browser.

How much does a project like Flaem cost?

We price every project individually, because two projects with the same name can differ in scope several times over. For a rough outline we give a range, and the quote is free.

How long does a project like this take?

It depends on the scope. We give the deadline in the quote together with the stages, and you accept each stage on a test version before it reaches people.

Will I see the design before any code?

Yes. We show the mockup on our server and you correct it before any code exists, so changes at that stage are quick.

You do. After acceptance and full payment, the economic copyright in the code and the materials made for you passes to you.

Mobile apps

Flaem

Q: What is Flaem built on?

Type: Mobile apps; Android: Kotlin, Jetpack Compose; iOS: Swift, SwiftUI; Notifications: FCM, APNs.

Native apps of the Flaem hosting platform, separately for Android in Kotlin and for iOS in Swift. The operator carries on-call duty with alarms and a queue of cases, and the client gets a shop with BLIK payment, their servers with console and power actions, invoices, tickets and push notifications. Both apps talk to the same API as the panel in the browser.

TypeMobile apps

AndroidKotlin, Jetpack Compose

iOSSwift, SwiftUI

NotificationsFCM, APNs

Overview

On the web, Flaem is the client's full command center: ordering servers, console, files, stats, billing. Everything an admin needs to keep their game server up and running. The catch is that this command center is chained to the desk.

An admin does not work nine to five in front of a monitor. An outage does not check the calendar - it comes on the bus, at lunch, in the middle of the night, when the server happens to be full of players. Then only one thing matters: how fast the phone in your pocket gets you to a restart and a console before players start leaving.

So we built the Flaem mobile version as a first-class way to run the platform, not a bolt-on to the web panel. In practice that is two separate apps written in each platform's native language - Android in Kotlin, iOS in Swift - reaching for the exact same API as the browser panel.

An outage does not ask where you are

When a server goes down in the middle of prime time, every minute is players who do not come back. In that moment you do not boot a laptop, log into the web panel, hunt for a tab. You pull out the phone you are already holding and you want to be on the console in two taps.

That changes what the app has to be. A tool you reach for under the stress of an outage has to launch instantly, respond without stutter and lead to the goal without wandering through menus. Every second of delay between tapping the icon and seeing the console is a second the server stays down.

Why not a page in a frame

The simplest and cheapest route to mobile is to wrap the existing web panel in a WebView and ship it to the store as an "app". The code is already there, you just surround it with a window. But the shortcut shows at every step: the app starts slowly, because the browser engine has to wake up first, drops native gestures, notifies poorly or not at all and looks like a page in a thin frame.

For a panel you tap once in a while that would be an acceptable compromise. For a rescue tool it is not. So we took the harder road: a separate, native interface on each platform that looks and behaves like an app from its system, not the same mockup crammed onto Android and iOS at once.

A page in a frame versus native

Trait	WebView	Native (Flaem)
App start	waits for the browser engine	instant
Gestures and scrolling	often stuttery	smooth, system-level
Push notifications	limited	full, with a deep link
System access	behind a sandbox wall	native
Look	a page in a frame	an app of its platform

Two languages, one API

What both apps share is what sits underneath: the API and the data model. What differs is the interface, because Android and iOS have their own navigation patterns, their own gesture language and their own expectations of how an app should behave. Forcing one shared UI onto both ends with it looking foreign on both.

The key point is that the mobile client talks to the exact same API as the web panel. There is no "mobile shortcut version" with trimmed capabilities - a server restart from the phone goes through the same contract as a restart from the browser. So on the phone you genuinely do what you do at the desk, not a chosen subset.

Two native apps

Android in Kotlin, iOS in Swift; shared API and data model, a separate interface tuned to each platform's patterns.

Live console

a stream of server logs and command entry from the phone, with a keyboard that does not cover half of what you type.

Status and power actions

start, stop, restart and a view of resource use without reaching for the desktop.

Billing

invoice view and payment, so the server does not expire just because you were away from home.

Push notifications

the server is down, the billing period is ending, a backup failed; you tap and land on the right screen.

Operator on-call and the client's shop

The app has two sides. The operator carries on-call duty in the phone: alarms with the time of the event and a button to take the case, a queue of KSeF, ticket and approval items, and node status with memory and backups. The client gets a shop where they pick a package, a variant and a billing period and pay with BLIK typed straight into the app, plus a service status page and a server invite with an address to copy and joining instructions.

Push that leads straight to the console

Notifications are not decoration but the core of the whole idea for mobile. They are what lets you learn about an outage before the first player does. Without them the app would be a passive window you have to open yourself at the right moment - and the right moment is usually the one when you know nothing.

A backend event has a simple, unambiguous shape, and it is that shape which decides where a tap on the notification drops you. The deep link leads not to a home screen but straight to the console of the specific server in trouble. No searching, no navigation - from the phone's sound to the place where you can act is one tap.

push-event.json · json

{
  "type": "server.down",
  "serverId": "srv_4192",
  "serverName": "SkyPvP",
  "severity": "critical",
  "deepLink": "flaem://servers/srv_4192/console"
}

A server saved from a bus stop

The result is a tool that genuinely rescues a server from a phone, not an emergency path you use once and go back to the laptop. The admin gets the full panel on the phone: status, console, power actions, billing - and learns about a problem the moment it happens, not when they happen to look.

On Flaem's side the gain is just as concrete: mobile is not a separate product living its own life but another client of the same API. A new capability in the backend is reachable from the phone just as from the browser, without rewriting the logic a second and third time.