Muhamed Isabegovic
All projects

Post-Dayton BiH

A card game where you build a political career in the most complex country in the world. You see what each decision costs; the consequences stay hidden until after you decide.

Role
My own game: I design and build it
Engine
Pure TypeScript, about 110 modules
Tests
4,161 tests in 193 files, all passing
Decisions
42 decision records, kept honest by a pre-push hook
Languages
Bosnian, Croatian, Serbian (Latin and Cyrillic) and English
The landing page of Post-Dayton BiH: a seal, the line Be the politician: your past follows you, your dossier gives you away, and a Play button.A turn: the card Tender for school renovation, with four choices around it and the instruction Drag the card toward your decision.
The landing page and a turn on the municipal council.

A career, one card at a time.

You start on a municipal council and climb, through the canton and the entity, to the state. Each turn is one card and four choices; you see what a choice costs, not what it causes. Press, coalitions, crises and campaigns interrupt the deck, and elections run from the platform to the morning after.

The dossier remembers everything. A choice from years ago can come back at the worst moment, which is the point.

What it does.

  1. It starts before the first election.

    A five-card prologue covers 1991 to 1996, so the career begins with a past. The game is free on the web, here on this site; the phone apps are on the way.

    The prologue card Summer 1991: a graduation dance in the house of culture, smoke from the power station, and the question what do you do when war is rumoured.The desk: a new dossier, load dossier, archive, badges and office settings.
    The prologue, and the desk where a career is kept.
  2. An engine held by tests.

    The rules live in a pure TypeScript engine of about 110 modules, apart from the interface, so every rule is tested on its own. The suite runs 4,161 tests in 193 files.

    The engine's test suite (Vitest), at c3aa816, 22 Oct 2026

    Test Files  193 passed (193)
         Tests  4161 passed (4161)
  3. Decisions that block a push.

    Every rule of the game’s design is a decision record, 42 of them. A pre-push hook refuses a push while an accepted decision is not yet implemented, and enola refuses one that breaks the layers of the code, from the screens down to the engine and the data. The decision check has no way around it, by design.

    .husky/pre-push · the refusal it prints

    [husky/adr-check] BLOCKED: accepted ADRs without completed implementation:
    The hook's own message, from its script.
  • Four languages, one engine.

    Bosnian, Croatian, Serbian in Latin and Cyrillic, and English, chosen on the landing page.

What it shows about how I work.

I hold a side project to the standards of production: the rules apart from the screens, thousands of tests, decisions written down, and a hook that will not let the code and the decisions drift apart. It is the same discipline I bring to a team’s codebase, with agents or without them.

Building something?

Tell me what you are building, and I will tell you honestly whether I can help.

Get in touch

Want a second opinion?

Start with an architecture review. Fixed scope, one to two weeks, and a plan your team can act on.

About the review

Or email info@muhamed.at