Software studio · Norway

Software that works when the network does not.

Daemroen builds products that hold up where software usually gives up — a tunnel, a plane, a cabin with no signal. Six platforms from one codebase, written from scratch or forked deliberately, and shipped only once it holds up on a real device.

See the work shakmate.com ↗

6 platforms, one codebase

11 languages shipped

351 automated tests, green

2 upstream forks carried in-tree

The work

One product, finished to the edges.

The studio would rather ship one thing that survives contact with a real device than four that demo well. Here is the one thing.

Shakmate

Live

Chess across a table, with no internet

Chess for web, Android, iOS and desktop. Play online, play the engine on eight levels, walk back through a finished game, or use the phone as nothing but a clock beside a real wooden board.

Every chess app assumes a connection. This one pairs two phones directly and runs the whole game between them — on a plane, on a train through a tunnel, in a cabin with no bars. That is why it was started; the rest followed because a chess app has to be a chess app first.

Open Shakmate↗

Status: Live
Platforms: Web · Android · iOS · Windows · macOS · Linux
Languages: 11
Client: Dart · Flutter · WebAssembly
Service: TypeScript on Cloudflare Workers
Nearby play: Bluetooth, no server in the middle

Engineering

What is underneath

The app is the visible part. Under it are seven packages with boundaries that are enforced rather than intended: nothing outside chess_core reasons about the rules, and nothing outside chess_clock does arithmetic on time. That is what lets the engine under it be replaced later without touching anything else.

chess_core Rules, variants, game state, PGN, position fingerprints. Perft-validated. pure Dart
chess_clock Every time control, derived from timestamps rather than ticking, so it survives a sleeping phone. pure Dart
chess_engine Evaluation and alpha-beta search behind one interface, on eight strength levels. pure Dart
chess_link The peer-to-peer wire protocol and transport layer for nearby play. protocol
chess_ui Design system, board widget and the components shared across every screen. Flutter
chessground Fork of lichess's board UI. Upstream declares ~40 piece sets as assets, many of them non-commercial, and Flutter ships every declared asset. fork
dartchess Fork of lichess's rules engine with a web-safe bitboard — upstream cannot compile to JavaScript at all. fork

Client

Dart
Flutter
WebAssembly
Bluetooth LE
Eleven locales

Service

TypeScript
Cloudflare Workers
Durable Objects (SQLite)
D1
KV
Push (FCM)

Method

Perft-validated rules
Typed end to end
Run in workerd locally
Reviewed against a real device

How it is built

Four decisions everything else follows from.

Offline is the requirement

Two phones on a table should play a full game with the radio off and nothing in between them. Every other decision in the product is made so that stays true.

One concern per package

Rules live in one place, time in another, transport in a third. Nothing outside the rules package reasons about rules. A boundary that is enforced is a boundary you can move behind later.

It ships when it holds up on a device

Not when it compiles, and not when it demos. Nearby play is not finished until two physical phones have played a game through it, radio and all.

A fork is a decision, not a shortcut

Both forks in this tree exist for a stated reason, carry a notice explaining it, and are maintained rather than abandoned at the commit they were taken from.

Studio

Small on purpose.

Developer and architect

Marius

Decides what gets built, how it is put together, and what it has to do before it ships. Works out of Norway.

Work to discuss

Offline-first apps, cross-platform clients, edge services. If it has to keep working when the connection stops, this is the right desk.

marius@daemroen.no