The complexity comes from a fundamental architectural challenge - how do you allow multiple applications to share a single piece of hardware (your sound card) without introducing massive lag or stability issues?

Nowadays, we’ve reached a relatively stable era with the widespread adoption of PipeWire² in the late 2010s and early 2020s³, but to understand where PipeWire came from, we have to look at the gradual revolution which attempted, in various forms of success, to fix the Linux audio problem decades ago.

ALSA (Advanced Linux Sound Architecture)

• Layer: Kernel
• Focus: Hardware Drivers
• Mixing: Hard (dmix)
• Hotplugging: Bad

PulseAudio

• Layer: Sound Server
• Focus: Desktop Ease
• Mixing: Automatic (software)
• Hotplugging: Good

JACK

• Layer: Sound Server
• Focus: Low Latency
• Mixing: Manual (Graph)
• Hotplugging: Bad

PipeWire

• Layer: Multimedia Framework
• Focus: Unified Stability
• Mixing: Automatic + Graph
• Hotplugging: Great

The Prehistoric Era: OSS

Before we even get to the modern stack, it helps to understand that the “never-ending cycle” of audio servers is a Linux tradition. Before the current foundation existed, there was OSS (Open Sound System). It was the original UNIX sound system and was the standard in the Linux kernel throughout the 1990s.

It was eventually deprecated because its creators made it proprietary in 1998⁴, which forced the open-source Linux community to scramble and build a replacement from scratch. That replacement was ALSA - Advanced Linux Sound Architecture.

We start again with ALSA

ALSA is a kernel-level framework which talks directly to the hardware (your sound card).

In the early days (and still technically nowadays), ALSA followed a strict rule of “one pipe, one process”. If your music player was using the audio ‘pipe’, your web browser was locked out. You wouldn’t be able to hear a notification sound if your sound card was occupied with playing some Radiohead. After various attempted framework-level solutions⁵, collectives of developers began to build a sprawling and fragile scaffolding of pipes on top of ALSA.

Enter PulseAudio

PulseAudio entered the stage as an ambitious project which tried to fix the ‘one user, one pipe’ problem⁶. It acted as a middleman, standing in front of ALSA, accepting audio from every app, mixing it together, and then shoving it into the ALSA pipe, pretending it was all one audio stream⁷.

On paper, PulseAudio was a revolution. In practice, for at least the first five years, it was a thorn for everybody who used a Linux desktop. It was famous for stuttering, high CPU usage, and the dreaded Internal Error that would leave your system entirely mute until you gave it a full reboot⁸. Sometimes, if you killed PulseAudio after it bugged out, your sound card would be overwhelmed with every queued audio event, and you would be gifted with a loud SCRMZMNEKEJEIOWJSANNSDMN before you reached for the power button. Another key problem was it would often ‘hang’, which is where a program stops responding, which would often be caused by resource overloading or crashing - but this would often block other programs from running⁹.

Glitch-Free Architecture

Admittedly, these were early days for PulseAudio - and many bug reports and patches were submitted over the years^{10 11} which improved the experience massively for the average user¹². The PulseAudio developers hit back at criticism, claiming that it was only natural that new software released to so many people at once would result in many bugs being found¹³, especially such complex software as a sound server. The developer, Lennart Poettering, even developed a ‘Glitch-Free’ version of PulseAudio¹⁴. Yes, all software should be glitch-free, you say - a ‘glitch’ in terms of a sound server is a moment where the CPU is busy and the sound card has a moment where the audio stream is interrupted - you may have heard this when your speakers go pop or a click or a brief moment of silence. PulseAudio, as of 0.9.11 in 2008¹⁴, moved from a simple push system to a smart timer system.

Historically, audio worked in ‘fragments’, scheduled via hardware Interrupt Requests (IRQs). The playback buffer is divided into a fixed number of ‘fragments’. The sound card plays one fragment, and then sends an interrupt to the CPU to request the next one. The interrupt interval T_int can be defined as buffer_size / (number_fragments * rate). This results in a significant trade-off - to achieve low latency, you have to use smaller and smaller fragments, which increases the number of interrupts per second, forcing the CPU to wake up more frequently and consume more power¹⁵. Poettering’s ‘glitch-free’ model replaces hardware interrupts with high-resolution system timers¹⁴. Instead of the sound card asking for data when it’s done, the audio server (PulseAudio in this case) proactively schedules CPU wakeups based off the system clock.

The system configures your sound card with the largest possible buffer (even up to 2 seconds). This provides a massive safety margin for any potential CPU scheduling delays. PulseAudio calculated the ‘time-to-empty’ based on the current playback position, and scheduled a wakeup 10ms before the buffer is projected to empty. If a buffer underrun¹⁵ occurs, the system will also dynamically increase the safety margin it assigned itself to prevent future glitches, essentially learning how jittery your system typically is, and adapting to it.

Now, you may think that a 2-second buffer would result in 2 seconds of latency in the case of a dropout. However, Glitch-Free architecture allowed for zero-latency interaction via something called buffer rewriting. Whenever a user interacted with the audio (ie hitting pause, or playing a new sound), the server would recalculate exactly which samples have not yet been processed, rewrite the samples in-place, and re-align the buffer to request new data dynamically.

This was a hugely impactful update and moved away from static, hardware-defined timing to dynamic, software-defined scheduling, which improved PulseAudio’s power efficiency (fewer CPU wakeups) while also improving the ability to react to user input with lower latency. These fixes worked, but also introduced a multitude of new bugs and made it less stable overall.

JACK

While the average user struggled with Pulse, audio professionals opted for JACK.

JACK built on top of ALSA, to create an experience where the most important thing was zero latency. In JACK, every app is forced to stay in perfect lock-step. If you have a digital guitar pedal and your recording software open, JACK will ensure they are synced down to the microsecond. It allows you to use ‘Patch Cables’ - you can literally route the audio out of one app and into another¹⁶. JACK aimed to prevent xruns - essentially buffer underflows, which created what we talked about before - ‘glitches’, or pops.

The main problem with JACK was that it was exclusive. It required a real-time kernel, and if you started up JACK to record some music, it would often ‘kick’ PulseAudio off the soundcard, meaning you couldn’t watch YouTube while trying to use your recording software.

But while JACK was inconvenient for daily use, it was vital for people who worked with audio professionally¹⁷. Paul Davis, the creator of JACK, is also the creator of Ardour, a free and very popular open-source ‘digital audio workstation’ (or DAW). Older versions of Ardour even required you to use JACK¹⁸, but modern Ardour works with all sound servers (like PipeWire, which we will get onto soon!)

Finally, PipeWire

The reason we talk about all of this in the past tense is thanks to the introduction of PipeWire in 2017. As you can read more about in the 2025 Linux Audio Conference, PipeWire has effectively ‘won’ the audio battle because it is so adaptable¹⁹.

PipeWire, originally called Pinos, was actually created to fix video, not audio. With the gradual shift to the Wayland display server (from X11), sharing screens and video suddenly became a problem. Pinos was built to route video streams securely between sandboxed apps. Because audio and video naturally need tight synchronisation, the developer Wim Taymans realised the framework he built for video was perfectly suited to replace PulseAudio and JACK²⁰.

PipeWire acts as a single, unified connector. It has a PulseAudio-compatible interface for your browser and all old platforms, a JACK-compatible interface for your music production software, and it talks to ALSA using modern high-speed logic. It also helps massively with video/audio synchronisation, which you can read more about from the original creator, Wim Taymans²¹.

Another massive win for PipeWire was finally waking up from the Bluetooth nightmare. PulseAudio historically struggled heavily with modern Bluetooth audio. Getting high-quality codecs (like LDAC or aptX) working without stuttering often required users to install third-party modules or hack configuration files. PipeWire effectively solved Linux Bluetooth audio overnight, supporting all modern codecs out of the box with zero configuration²². For the average user, this alone was enough to make the switch.

PulseAudio was also a security nightmare on Linux for Flatpaks. Flatpaks are essentially ‘sandboxes’ apps, and they are a popular way to distribute apps on Linux if they don’t need system-wide access or permissions. PulseAudio tended to mess this up by blurring the line between system and apps - PipeWire uses a session manager (like WirePlumber)²³ to handle routing logic, and a ‘portal’ system (called XDG Portal)²⁴ to ensure sandboxed Flatpaks can’t access your mic without permission - which finally fits modern Linux security models²⁵. PipeWire can also switch from ‘power-saving mode’ (a la PulseAudio) to a more high-performance and low-latency mode (JACK style) on the fly, depending on what devices you have plugged in and which programs you have open.

PipeWire adopted JACK’s graph-based approach - it essentially took the ‘everything is a node’ architecture from JACK that allowed users to connect inputs to outputs, and added the stability and adaptability to PulseAudio to make the best system we have today.

The End

For the first time in desktop Linux history, the audio stack is boring - and that is a compliment. I no longer have to choose between PulseAudio or JACK - I can have both. Today, I can open up Ardour to record a drum track, hop on a Discord call, and stream a YouTube tutorial, all at the same time.

I knew from the outset I didn’t want to build a billing engine from scratch (why would you?). Dealing with global tax compliance, VAT MOSS, and currency conversion is a nightmare I wouldn’t wish on anyone. So Stripe wouldn’t cut it - I needed a Merchant of Record (MoR), not just a payment gateway. Enter Lemon Squeezy.

Here is a quick dive into how I wired up Next.js, Supabase, Capacitor, and Lemon Squeezy to build “CashCat Pro” - without getting my app nuked from the Google Play Store.

Friction and Free Trials

Pricing psychology is a dark art. I eventually settled on a “CashCat Pro” tier priced at £4.99/mo and £39.99/yr. It safely clears the £1.99 “dead zone” (where you get all the support tickets but none of the actual revenue) and severely undercuts the £100/yr VC-funded juggernauts I’m competing against.

But how do you handle onboarding? The standard SaaS playbook dictates a 7-day free trial. However, a time-based trial for a personal finance app is a massive vulnerability. Users can sign up, import three years of historical CSV bank data, let the app generate all their categorical insights, take screenshots of their spending habits, and then cancel on day 6. The classic “hit-and-run.”

Not only that, I want users, not just paying users. I need a solid free plan. So, I implemented a strict freemium model governed by action limits, rather than time limits. New users are granted exactly 2 free CSV imports and 3 free CSV exports. They are given unlimited transactions, categories, and budgeting abilities.

From a technical standpoint, this is incredibly simple to implement. I don’t need complex CRON jobs running every minute to check if trials have expired. I don’t need to juggle timezone offsets. I just increment integers in the database.

It also guarantees the user reaches the “Aha!” moment that I found was so crucial in premium subscriptions. They see the magic of their automated dashboard. But next month, when they need to import their new data, they encounter the friction. The value proposition is already proven; now they just pay for continuity.

Supabase Schema

My entire backend relies on Supabase. To handle this new logic, I had to extend my central profiles table.

I evaluated Lemon Squeezy’s built-in “License Keys” feature, but that’s really designed for downloadable electron apps, not a continuous cloud SaaS. Instead, I wired everything manually by adding three columns to the profiles schema:

• pro (boolean, default: false)
• free_imports_used (integer, default: 0)
• free_exports_used (integer, default: 0)

Row Level Security (RLS)

Of course, securing this is paramount. You can’t just have a client-side update flipping pro to true. I updated my Supabase Row Level Security (RLS) policies to ensure that these specific columns can only be modified by the service_role key - meaning only my secure server-side API endpoints can touch them.

The Founder Bypass

There is nothing worse than deleting a test user during development and accidentally locking yourself out of your own Pro features. It halts development while you scramble to manually edit rows in the Supabase Studio dashboard.

To save my sanity, I added a “Founder Bypass” into my core Next.js utility function:

export async function checkSubscription(userId: string, email: string) {
  // The ultimate developer override
  if (email === "cashcat@indigonolan.com") {
    return { isPro: true, importsUsed: 0, exportsUsed: 0 };
  }

  const { data, error } = await supabase
    .from('profiles')
    .select('pro, free_imports_used, free_exports_used')
    .eq('id', userId)
    .single();
    
  // ... handle errors and return state
}

It’s a tiny shortcut, but it’s a lifesaver when you’re rapidly wiping the local database.

Webhooks in Next.js

Integrating the checkout flow wasn’t too bad. I set up an A Record to map pro.cashcat.app directly to Lemon Squeezy’s IP address (3.33.255.208), giving me a beautiful, white-labeled checkout page.

The critical requirement during checkout initialization was passing the authenticated Supabase user_id into Lemon Squeezy’s custom_data object. When the payment clears, Lemon Squeezy fires a webhook back to my server, carrying that ID with it so I know exactly whose database row to update.

The real headache was securely receiving that webhook. Next.js App Router (app/api/...) does some aggressive abstraction, especially around raw request bodies. To verify a Lemon Squeezy webhook signature, you must hash the absolute raw body of the request against your signing secret using crypto.createHmac. If Next.js parses the JSON first, the whitespace changes, the hash fails, and the webhook is rejected.

Building the receiver looked something like this:

// app/api/webhooks/lemonsqueezy/route.ts

import crypto from 'crypto';
import { createClient } from '@supabase/supabase-js';

export async function POST(req: Request) {
  const secret = process.env.LEMON_SQUEEZY_WEBHOOK_SECRET;
  const signature = req.headers.get('x-signature');
  
  // You HAVE to get the text exactly as sent
  const rawBody = await req.text(); 
  
  const hmac = crypto.createHmac('sha256', secret);
  const digest = Buffer.from(hmac.update(rawBody).digest('hex'), 'utf8');
  const signatureBuffer = Buffer.from(signature, 'utf8');

  // Guard against timing attacks
  if (!crypto.timingSafeEqual(digest, signatureBuffer)) {
    return new Response('Invalid signature', { status: 403 });
  }

  const payload = JSON.parse(rawBody);
  
  if (payload.meta.event_name === 'subscription_created') {
    const userId = payload.meta.custom_data.user_id;
    
    // Elevate privileges to bypass RLS
    const supabaseAdmin = createClient(
      process.env.NEXT_PUBLIC_SUPABASE_URL,
      process.env.SUPABASE_SERVICE_ROLE_KEY
    );

    await supabaseAdmin
      .from('profiles')
      .update({ is_pro: true })
      .eq('id', userId);
  }
  
  return new Response('OK', { status: 200 });
}

Using crypto.timingSafeEqual is absolutely necessary here to prevent timing attacks. Once the signature clears safely, the server role elevates its privileges and flips the boolean.

Dodging the “Google Tax” on Android

Here is where the architecture really gets put to the test. As I detailed in my Capacitor post, CashCat is shipped as an Android app.

The Google Play Store has a draconian policy: if you unlock digital content or features natively inside an app, you must use Google Play Billing. If you route them to an external payment gateway like Stripe or Lemon Squeezy, your app will be banned and permanently removed. They want their 30%. Because I refuse to manage two completely separate billing architectures, at least until I start making profit, I opted for the “Reader App” loophole.

Essentially, you are allowed to have an app where features unlock based on a user’s web subscription, as long as you do not link out to the payment page from within the app itself.

Thanks to Capacitor, this was remarkably elegant. I created a generic helper to detect if the React code was executing inside a native shell.

export const isNativeApp = () => typeof window !== 'undefined' && !!window.Capacitor;

I then wrapped my paywalls and upgrade components in a conditional render. If you hit the import limit on the web version, a beautiful gradient “Upgrade to Pro” button appears, routing you to Lemon Squeezy.

If you hit the exact same limit inside the Android app, isNativeApp() evaluates to true. The button is completely stripped from the DOM. Instead, a plain text paragraph appears:

“You have reached your free import limit. To unlock unlimited imports, please manage your subscription by logging into your account at cashcat.app from a web browser.”

No hyperlinks. No buttons. No Google policy violations. A single unified codebase.

The Paywall UX and Final Polish

The final piece of the puzzle was the user experience of the paywall itself. “Surprise paywalls” are a dark pattern that instantly destroy user trust.

Instead of a hard block on their 3rd attempt to export data, the UI acts as a constant, transparent dashboard. The Export and Import buttons continuously read the free_exports_used column from Supabase and display dynamic subtitle labels. Before they even think about exporting a second time, they see “1 of 2 free exports remaining”.

Once that integer hits the limit, the UI morphs dynamically. The action buttons transform into a sleek, dark-mode call-to-action modal. This modal doesn’t just ask for money; it clearly outlines the actual value proposition of CashCat Pro: custom date ranges, complex money flow diagrams, and unlimited data handling.

It converts the user at the exact point of friction, but only after clearly outlining what they stand to gain. Transparent pricing is what I’ve always wanted in a SaaS product, and it’s what I’m trying to build here.

If you’d like to check out the finished product (and perhaps hit that import limit yourself), visit cashcat.app.

To use CashCat on mobile, for quick transaction adding, I originally added PWA (Progressive Web App) support. You may have seen this before it’s when you visit a website on your phone, and it prompts you to add it to your home screen. It’s supported on both Android and iOS, and most major browsers (Firefox, Chrome, etc.). As far as I was concerned, it worked flawlessly, and I used it daily.

But of course, I know that any app which takes itself seriously should have a presence in both the Google Play Store and the Apple App Store. Telling somebody, “No, we do have an Android app, you just have to go to the website, click the three dots, click ‘Add to home screen,’ and then look, it works!” is embarrassing. It’s not the experience I want to offer.

Not only that, but the offline capabilities of PWAs - even with service workers and aggressive localStorage and indexedDb caching - are severely limited compared to a native shell.

So, after the MVP of CashCat was shipped to the web, we began exploring the options available to us for mobile apps.

Why not React Native?

At first, we looked into React Native. As the web build is a Next.js app (where the frontend is React), this seemed like the logical next step. However, it quickly became clear that the amount of effort it would take to convert our entire framework into native components would be disproportionate. We wanted to reuse logic, not rewrite UI.

We quickly began searching for easier and more purpose-built alternatives, looking at tools like Expo and PWABuilder.

Capacitor Saved the Day

Eventually, I spotted Capacitor being mentioned in a thread on Reddit. Apparently, it worked perfectly for Next.js apps. The core strategy was simply to wrap your app, with little to no rewriting.

By choosing Capacitor, we decided to wrap the existing Next.js code. This allowed us to save massive amounts of time by reusing our existing TanStack Query logic (which we used for aggressive caching into localStorage) instead of rewriting the UI in native components. We adopted a “Single Codebase” philosophy, configuring the project to deploy to both Web (Vercel) and Mobile (Google Play) from the exact same git repository.

With Capacitor, you can use Ionic if you want their material UI library, or simply stick with your original web code. We chose the latter.

Here is how we actually pulled it off.

1. The Next.js Config Shift

The first hurdle was getting Next.js to output something a mobile phone understands. Phones don’t run Node.js servers, so standard server-side rendering (SSR) was out.

• Static Export: We switched Next.js to output: 'export' mode. This generates the static HTML/CSS/JS files required by Capacitor.
• Image Optimization: We had to disable standard Next.js Image Optimization (unoptimized: true) because, again, there is no Node.js server on the phone to process and resize images on the fly.
• Conditional Logic: We didn’t want to lose these features on our web deployment. We updated next.config.js to only apply these static settings when process.env.CAPACITOR_BUILD is true.

2. The Backend Disconnect (The Biggest Challenge)

This was the tricky part. We quickly realized that Next.js API Routes (/api/...) and Server Actions ('use server') crash the mobile build.

To fix this, I had to spend a couple hours trawling through each element.

1. The URL Fix: We updated our fetch requests to use absolute URLs pointing to our live production domain, rather than relative paths.
2. The Refactor: We converted Server Actions into standard client-side fetches (using TanStack Query) to communicate with the remote API.
3. Component Stubbing: We created a “swap” mechanism for our ApiKeyManager component, completely removing it from the mobile build since it was only needed on the web server.

But the real “hack” was handling the folder structure. Even with the config changes, Next.js tries to compile server code found in the api folder. We implemented a strategy to rename and hide the src/app/api folder during the mobile build process specifically to prevent Next.js from trying to touch it. I wanted to have a headache-free build process, and npm’s build scripts allowed me to create this easily.

3. Automation: The build:mobile Script

Because the process involved renaming folders and swapping components, doing it manually was a recipe for disaster. I wrote a custom script, scripts/build-mobile.js (using shelljs), to automate this fragile process.

The script performs the following gymnastics:

1. Renames/Hides the API folder.
2. Stubs out incompatible components.
3. Runs next build with the correct environment variables.
4. Restores the API folder and components (so I don’t break the web version while developing).
5. Runs npx cap sync.

I added this to my package.json so I can now run a single command:

npm run build:mobile

build-mobile.js

const shell = require('shelljs');

// Config paths
const API_DIR = 'src/app/api';
const API_HIDDEN = 'src/app/_api_ignored';
const COMPONENT_FILE = 'src/app/components/api-key-manager.tsx';
const COMPONENT_BACKUP = 'src/app/components/api-key-manager.tsx.bak';

console.log('Preparing for Mobile Build...');

// We use this to fix the files whether the build succeeds OR fails
function restoreFiles() {
  console.log('Restoring original files...');

  // 1. Restore API folder
  if (shell.test('-d', API_HIDDEN)) {
    shell.mv(API_HIDDEN, API_DIR);
  }

  // 2. Restore Component
  if (shell.test('-f', COMPONENT_BACKUP)) {
    // Delete the dummy stub we created
    if (shell.test('-f', COMPONENT_FILE)) {
      shell.rm(COMPONENT_FILE);
    }
    // Bring back the original code
    shell.mv(COMPONENT_BACKUP, COMPONENT_FILE);
  }
}

console.log('Hiding API routes...');
if (shell.test('-d', API_DIR)) {
  shell.mv(API_DIR, API_HIDDEN);
}

console.log('Swapping ApiKeyManager with a dummy stub...');
if (shell.test('-f', COMPONENT_FILE)) {
  // Backup the real file
  shell.mv(COMPONENT_FILE, COMPONENT_BACKUP);

  shell.ShellString(`
    export default function ApiKeyManager() { 
      return null; 
    }
  `).to(COMPONENT_FILE);
} else {
}

console.log('Building static export...');
// Run the build
if (shell.exec('CAPACITOR_BUILD=true npm run build').code !== 0) {
  console.error('Build failed! Restoring files immediately...');
  restoreFiles(); // <--- Critical: Fix files before exiting
  shell.exit(1);
}

restoreFiles();

console.log('Syncing with Android/iOS...');
shell.exec('npx cap sync');

console.log('Mobile build complete!');

4. Capacitor & Android Setup

Once the code was built, we had to get it running on Android. I installed the Capacitor core and Android platform (npx cap init) and ran into a few environment issues immediately.

I had to fix capacitor.config.ts to point webDir to the out folder (the result of our static export) instead of the default public.

Development on Linux also threw a curveball. I kept getting an “Unable to launch Android Studio” error, which I fixed by finally resetting the CAPACITOR_ANDROID_STUDIO_PATH environment variable in my Fish shell config. I also had to manually download the Gradle distribution zip to solve some nasty connection timeouts in Android Studio.

5. Native Polish for the UI

A wrapped website often feels like… just a website. To make CashCat feel like a native app, we had to apply some specific UI polish:

• The Notch Fix: I added viewport-fit=cover to the metadata and applied env(safe-area-inset-top) padding. This prevents our content from hiding behind the status bar or the camera notch.
• Scroll Bounce: There is nothing that screams “website” more than rubber-banding when you scroll to the top of a page. I added overscroll-behavior: none to the CSS (and the iOS config) to attempt to stop this. It sometimes works, sometimes doesn’t.
• Zoom Disable: I locked the viewport scale and set input font sizes to 16px. This stops the OS from zooming in automatically every time you tap a text box.
• The “Traffic Cop”: I added redirect logic in page.tsx that acts as a traffic cop. If a user is on mobile, it automatically skips the Landing Page (/) and sends them straight to the Dashboard (/budget).

6. Deployment

We configured .gitignore to track the android/ shell (for permissions and icons) but ignore the heavy build artifacts like android/app/build and out/.

For the Play Store, I signed up for the Google Play Console. It cost about £25 as a one-off fee. Totally worth it. I also learned that for every upload, you have to manually increment the versionCode integer in build.gradle, or Google rejects the build.

We are currently using the “Internal Testing” track. We generate a signed App Bundle (.aab), upload it, and use the generic “Join on Web” link to install it on our physical devices.

We even have a draft of a Google Play Store page:

I’ve just begun Closed Testing (if you’d like to join, please email me at cashcat@indigonolan.com and I’ll give you access!)

What about iOS?

While I handled the Android side, my co-maintainer Josh has been tackling the iOS version. The barrier to entry is higher there - the Apple Developer Program is around $99/year - but for the sake of covering the whole mobile market, it’s worth it. I have fewer updates from his side, and I’d direct you to his own blog anyway.

We are nearly there. The web-first approach allowed us to move fast, and Capacitor allowed us to go native without losing our minds.

If you’re interested in trying out CashCat, and you have an Android or iOS device, go sign up on the website, join our discord, or email me at cashcat@indigonolan.com to get added to our app tests!

I’m currently building a personal budgeting app. It’s going extremely well. The main dashboard works great, transactions are easy to manage and the budget is smooth (CashCat). Our next big step to join the big players was to add bank integration for automated transaction syncing. We had a master plan for this, a small subscription fee to cover the price we’d researched a year back, it was all loosely planned.

And then, I ran into the brick wall that is the current state of Open Banking.

The Golden Age (That I Unfortunately Missed)

A few years ago, the promise of PSD2 (the EU regulation that forced banks to open up their data) was that innovation would flourish. Startups like the Latvian Nordigen appeared, offering free API access to bank feeds for developers.

In 2022, Nordigen was acquired by the UK company GoCardless. I saw this when researching a year or so ago when I had the idea for CashCat, and was a bit concerned, but “Fine,” I thought. “GoCardless is a big respectable company, surely they’ll keep the affordable tier for developers.”

Unfortunately, they did not keep the affordable tier for developers.

Six months ago, they shut down the individual access for the Open Banking service. Now, to get access, you need a full business account with them, which is completely trapped behind enterprise sales calls, minimum monthly spends, or strict regulatory requirements that require me to be an AISP (Account Information Service Provider). Which I cannot do. I do not have bank-level cash just sitting around, unfortunately, nor do I have the time or experience to jump thousands of regulatory loopholes.

It’s not just them, though, I went looking for alternatives, trust me. The entire ecosystem has consolidated. Plaid, Yodlee, Truelayer, all exist, but they are all designed for business-to-business. They want to sell to apps with 100,000 users and a legal team - not me building a tool right now with no budget. The “Minimum Monthly Commit” is usually enough to pay for a lifetime subscription to YNAB. I guess the compliance costs are simply too high that they aren’t willing to risk serving hobbyists at a loss anymore.

I looked into Mellio and a few other smaller aggregators, but it’s the same story everywhere.

Some sites (Enable Banking) seem to have potential, but so far only support EU banks and nothing in the UK yet. I will keep an eye on them, and see if support is extended to the UK soon. Otherwise, it always goes like:

• To access the APIs legally, you often need your own regulatory license or to act as an “agent” of the provider (TrueLayer, Plaid, etc).

• The “Pay as you go” models for the right to be an agent to the provider are vanishing, replaced with large, and often unaffordable, minimum contracts. That I can’t afford.

So here I am, I have Cashcat designed, the budgeting system working, the transaction view perfected, but I have no automated pipeline for the transactions.

Don’t get me wrong though, CashCat works fine without Open Banking. I use it daily, with manual transaction entry (and to be honest, it feels even better as a tool that way - you actually have to think about each transaction you’re making, which makes it even more likely you’ll stop in your tracks.) But I do recognise that most people will not have the time or want to put in the effort.

So What Next? (The Return of the CSV)

So, the only option seems to be shamefully and manually exporting a CSV from the banking app every week and dragging it into Cashcat, so we’re working on a easy-to-use CSV import feature.

It does turn out parsing bank CSVs is a bit of a nightmare though. Every bank formats the date differently. Some use DD/MM/YYYY, some use YYYY-MM-DD. Some put the merchant in a column called “Description”, some split it into “Counterparty”, some have two columns for income and outflow, some merge them. It would be great if there was some form of standardisation, with templates provided by regulators. They could be published openly and given to all banks! That would make it much easier to make financial apps. We could call it something like… Open Banking.

So CashCat, I think, will have to lack the magic of ‘it just works’. It feels so weird, in this age of hyper-automation, that I can’t do this simply. It is frustrating and disappointing. I am angry, but I’m not sure where to direct that. For now, I have to adapt.

If you’re interested in trying out CashCat, which I’m building with Josh Wilcox, go pay us a visit to see more!

If you read Part 1, you’ll remember I was adamant about two things: I wanted to own my data, and I didn’t want a server. I wanted everything local, with a hacked-together Google Drive sync. Well, I have a confession to make. I broke my own rules.

It turns out that writing your own conflict-resolution logic for JSON files stored in Google Drive is a unique form of torture that I wouldn’t wish on my worst enemy. So, I did what any reasonable developer does when they hit a wall: I rewrote the entire stack.

Welcome to Head and Heart.

The Cloud (Sort of)

I decided to migrate the backend to Convex.

For those who haven’t used it, Convex is a backend-as-a-service that handles your database, authentication, and real-time updates. It allows me to keep the app feeling “local” (it’s insanely fast) while actually having the ability to save data cross-device (honestly, who would use the website if that wasn’t a builtin feature.)

This means yes, I had to add authentication. The app now uses Convex Auth to handle user sessions. I know, I know. I said “no accounts” previously. But the trade-off is that now you can actually log in from your phone and your laptop and not worry about overwriting your database with an old CSV file.

The Implementation: From 1-3 to 5x5

In Part 2, I theorised that a 1-3 scale was perfect. 1 for bad, 2 for okay, 3 for great.

As soon as I started coding the actual grid component, I realised I had made a mistake. 1-3 is too vague. If I rate Interstellar a 3 on Head, where do I put The Menu? I liked it a lot, I thought it was excellently made. Is it also a 3? Probably. But is it the same 3? Is it as good? I don’t think so. I don’t want to give it a 2, because then I’m equating it with worse films, and then I fell into the same pattern again.

So, I decided to expand the grid to 5x5. It gives juust enough precision so you can differentiate “Good” from “Masterpiece” without falling back into the trap of “Is this a 72 or a 73 out of 100?” (which I did a lot when I used favourites.me)

I built this using a custom SVG component. Each cell in the grid represents a coordinate pair: headRating and heartRating.

The code for the grid interaction is surprisingly simple, handled by updating local state before firing a mutation to Convex:

// The grid is essentially just a visualization of two numbers
interface RatingGridProps {
  head: number;
  heart: number;
  onChange: (head: number, heart: number) => void;
}

// Visual feedback is key - hovering a cell explains the rating
const RATING_DESCRIPTIONS = {
  1: "Flawed / A Slog",
  // ...
  5: "Masterpiece / Loved it"
};

Visualising the Data

This is the part I’m most excited about. The whole point of tracking this data isn’t just to have a list; it’s to see trends.

In the Stats.tsx view, I’ve built a scatter plot using SVGs. Since I’m collecting type (Movie, Book, Game), head, and heart, I can plot everything on a single chart.

I added a diagonal line of y = x to the graph. This is the “Line of Agreement.”

• Above the line: Media that captured my heart more than my head (The “Guilty Pleasures” zone).
• Below the line: Media that I respect intellectually but didn’t actually enjoy that much (The “Schindler’s List” zone).

This means I can create a heatmap (something I’d wanted to visualise for a while) very easily, something that simply wouldn’t look good at all on a 3x3 grid.

It looks something like this:

What about the CSVs?

I promised I wouldn’t lock data away, and I stick to that. Even though I’m using a database now, I built a robust Import/Export system.

The ImportModal component is actually one of the most complex parts of the new app. It parses the CSVs from the old version of favourites.me and maps the fields to the new Convex schema.

// convex/schema.ts
export default defineSchema({
  mediaEntries: defineTable({
    userId: v.string(),
    title: v.string(),
    type: v.string(), // "Movie", "Book", "Game", "TV", "Board"
    headRating: v.number(),
    heartRating: v.number(),
    dateWatched: v.string(),
    notes: v.optional(v.string()),
  }).index("by_user", ["userId"]),
});

Final Thoughts

The transition from a spreadsheet to a local React app to a full-stack Convex application has been a bit of a journey. I’ve had to learn a lot about backend mutations and authentication flows (and why useEffect is sometimes dangerous), but the result is something I actually use every day. I stopped using favourites.me because I had too much choice paralysis on a 100-point scale, but I didn’t want to go back to Letterboxd’s 10-point scale - so here is my new, all-improved, 25-point scale. Revolutionary, I know.

The Head and Heart system feels right to me. It frees me from the pressure of “objective” reviews and lets me admit that sometimes, I just really love a dumb action movie, and that’s okay.

The new version is live now. If you have data on the old version, just export your CSV and import it into the new one.

Go rate some stuff!

Check out the new Head & Heart system at headandheart.app!

Last year, I participated in the Global Game Jam for the first time, and made Tub Tussle, a 4-player arcade game! I loved the whole experience this much, that when it came around this year, I was already signed up. For Global Game Jam 2026, I teamed up with my good friends Indigo Wolf-Garraway, Josh Wilcox, and Dexter Smith.

The result? Damaskus. And we were incredibly honored to win the highly-coveted People’s Choice Award!

The Workflow: Web-Based Level Editing

One of the biggest bottlenecks in a game jam is content creation. We knew we wanted a puzzle game, but building 20+ levels manually in the Godot editor would have been a nightmare of drag-and-drop, which we quickly discovered.

So, Josh built a custom level editor on the web: damaskus.josh.software.

It allowed us to paint levels quickly in the browser and export them as simple JSON arrays. This decoupled level design from game implementation, meaning we could actually design levels while the core game wasn’t even finished yet.

The output looked something like this - a simple 2D array of integers representing tile IDs:

var campaign_level_layouts = [
    [ # LEVEL 1
        [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
        [1, 0, 1, 0, 8, 0, 1, 0, 0, 0, 0, 4, 0, 0, 1],
        [1, 0, 0, 0, 0, 0, 1, 0, 0, 2, 2, 2, 0, 0, 1],
        # ... more rows ...
    ]
]

We utilized a similar array for Masks, which are the core mechanic of the game.

The Importer: Turning Arrays into Acts

In Godot, we wrote a LevelGenerator.gd script to parse these arrays. It iterates through the grid coordinates, checks the ID, and instantiates the corresponding scene.

We defined the mapping in a dictionary to keep it clean:

# scripts/core/LevelGenerator.gd

var tile_definitions = {
    1: {"scene": wall_scene, "container": "Walls", "type": GridManager.TileType.WALL},
    2: {"scene": water_scene, "container": "Water", "type": GridManager.TileType.WATER},
    3: {"scene": crumbled_wall_scene, "container": "CrumbledWalls", "type": GridManager.TileType.CRUMBLED_WALL},
    # ...
    8: {"scene": laser_emitter_scene, "container": "LaserEmitters", "type": GridManager.TileType.LASER_EMITTER},
}

The generation logic is straightforward. It wipes the previous level and builds the new one tile by tile, registering everything into our GridManager:

func _generate_from_arrays(level_layout: Array, mask_layout: Array):
    # ... cleanup old level ...

    for y in range(level_layout.size()):
        for x in range(level_layout[y].size()):
            var cell_value = level_layout[y][x]
            var grid_pos = Vector2i(x, y)
            
            if cell_value == 1: # WALL
                var wall = wall_scene.instantiate()
                wall.position = grid_manager.grid_to_world(grid_pos)
                walls_container.add_child(wall)
                grid_manager.set_tile(grid_pos, GridManager.TileType.WALL)
            
            elif cell_value == 2: # WATER
                # ... instantiate water ...

The Grid System

Since Damaskus is a grid-based puzzle game, we didn’t use Godot’s built-in physics engine for movement. Instead, we wrote a deterministic GridManager.

The GridManager holds the “truth” of the world in a Dictionary mapping Vector2i coordinates to TileType enums.

# scripts/core/GridManager.gd

enum TileType {EMPTY, WALL, CRUMBLED_WALL, WATER, OBSTACLE, ...}

var grid_data: Dictionary = {}

func is_solid(grid_pos: Vector2i) -> bool:
    var type = get_tile_type(grid_pos)
    return type == TileType.WALL or type == TileType.CRUMBLED_WALL or ...

This made implementing mechanics like the Phase Shift (Red/Blue walls) extremely easy. The player interacts with the grid, not the colliders.

Movement & Mask Mechanics

The player’s movement logic in Player.gd queries the GridManager before every step. This is where the Mask System comes in. Masks aren’t just cosmetic; they grant specific “properties” that override collision rules.

For example, the Water Mask grants the FLOAT property, allowing you to walk on water tiles:

# scripts/entities/Player.gd

func can_move_to(target_pos: Vector2i) -> bool:
    var tile_type = grid_manager.get_tile_type(target_pos)

    match tile_type:
        GridManager.TileType.WATER:
            # Only pass if we have FLOAT property
            if has_property("FLOAT"):
                return true
            return false 

        GridManager.TileType.CRUMBLED_WALL:
            # Only pass if we have BREAK_WALL property
            if has_property("BREAK_WALL"):
                return true
            return false
            
        # ... logic for pillars phase walls ...

This architecture allowed us to add new masks and mechanics rapidly. Need a mask that breaks walls? Just add a BREAK_WALL property and check for it in can_move_to.

The Ghost

A key and very fun feature of Damaskus is the co-op ghost mechanic. The Ghost (managed by NPC.gd) mimics your movement. Because we used a strict grid system, keeping the Ghost in sync was simply a matter of connecting a signal.

# scripts/entities/NPC.gd

func _on_player_moved(direction: Vector2i):
	if not is_active: return
	
	# Buffer the move if we are busy, just like the Player does
	if is_moving:
		next_move = direction
	else:
		try_move(direction)

However, the Ghost also has an inventory slot and can wear masks! This leads to complex puzzles where you might need the Ghost to wear the Water Mask to cross a river, while you hold the Dimension Mask to open the path for both of you.

The pillars required a checks for both entities:

GridManager.TileType.RED_WALL:
    var anyone_dim = has_property("DIMENSION_SHIFT") or (target_player and target_player.has_property("DIMENSION_SHIFT"))
    return anyone_dim and grid_manager.is_red_mode

If either character holds the Dimension Mask, both can walk through the matching colored pillars. This created some really fun “aha!” moments in testing.

The Result

The combination of a custom web-based editor and a robust grid system allowed us to crank out over 20 levels in just 48 hours. It was a chaotic sprint, but Indo’s incredible pixel art, along with seeing people enjoy the puzzles - and winning the People’s Choice Award - made it all worth it.

It will be polished a little more and it’s ready to play at damaskus.indigo.spot!

TLDR: I built a tiny (very inaccurate, but fun) political simulation game. You can play it at polplay.indigo.spot.

If you’ve spent any time in the niche world of political strategy games, you’ve probably hit the same wall I did. Lawgivers is a great game for mobile, but it’s more focused on the governing, and The Political Process is probably the gold standard for depth on desktop, but is a little too detailed and laser-focused. I wanted a sandbox where I could define the exact demographic makeup of a country and see how different party platforms would actually clash mathematically.

So, I started building The Political Playground.

The Iteration Cycle: From Python to Vite

The project has gone through three distinct “lives” based on whatever I was learning at the time.

1. The CLI Era (Python): This was basically just a bunch of if/else statements and a bunch of random calls. It was a text-based script where you’d feed in a list of parties, and it would spit out a final percentage. It developed into a bigger simulation, where it would model individual voters, but this quickly got heavy for Python to process, so I cut down the sample size, and implemented heuristics. I also eventually added Matplotlib to generate some bar charts, but it was still more of a mathematical experiment than a game, which was simply a result of my technical skill level at the time, when I was still in school.
2. The Web Migration (Next.js): After a year-long hiatus during my transition from sixth form to uni, I revived it. I initially went with Next.js because I wanted to learn the framework, and converted the whole Python program into Javascript, stripping out all of the bloat I had left in when I wrote my voting simulation logic. I initially hosted it on Vercel, and worked on it in my spare time, then moved to Sherpa.sh to experiment with different deployment pipelines. In about January 2026, Sherpa.sh shut down, and I had to move the project again.
3. The Current State (React + Vite): I realized that because the simulation logic is entirely client-side, I didn’t need a server or SSR (Server-Side Rendering). I stripped out the Next.js boilerplate, migrated to Vite, and turned it into a static React app. It’s now hosted on GitHub Pages, which makes deployment as simple as a git push.

The Logic for Voter Demographics

The main focus of the project is the voter modeling engine. Instead of a simple “liberal vs. conservative” slider, I’ve implemented a seven-axis system, along with weighting, trends, voter blocs, salience, and loyalty factors. It is by no means accurate enough for a real-life polling model, but it is accurate enough to be fun.

Every voter “clump” in the simulation is defined by coordinates on these scales:

• Progressive > Conservative
• Socialist > Capitalist
• Authoritarian > Liberal
• Religious > Secular
• Environmentalist > Industrialist
• Nationalist > Globalist
• Militarist > Pacifist

The initial versions of the game just generated random noise for each voter based off a ‘national average’, but this was boring, not to mention unrealistic. I quickly ran into problems with this - a party could win easily by simply becoming more centrist, and becoming more extreme would never win more votes unless it was going directly towards the national average. So, I added the ability to define voter blocs, which are groups of voters who are more likely to vote for certain parties or vote specific ways. This way, I can avoid the classic bell curve, and include different spikes - for example, voters who are socially conservative but economically left-wing, as well as a large bloc of centre-right secular voters. I also added the ability to define trends, which are factors that can influence voter behavior over time. Finally, I added the ability to define loyalty factors, which are factors that can influence voter behavior over time.

For now, I’ve manually defined all of these blocs and voting demographics for each country and each party, which is why I have disclaimers everywhere stating the inaccuracy of the simulation - it is simply a game which I find quite fun.

The game now generates distinct groups for each country (like ‘Urban Professionals’ or ‘Rural Traditionalists’). I use the Box-Muller transform over each bloc to make them feel organic, along with ‘salience weights’ - a Rural Traditionalist might care significantly more about socially conservative views than the economic axis. Each of these blocs are displayed in the statistics view while you are campaigning, and you can see which parties they are supporting.

How the “Vote” is Calculated

The engine uses a distance-based formula to determine voter preference. Essentially, for every voter group V, it calculates the distance to every party P in the n-dimensional space (where n=7).

The simplified logic looks something like this:

    // Iterate through all 7 political axes (VALUES)
    for (let o = 0; o < VALUES.length; o++) {
      const voterVal = data[o][voterIndex];
      // Calculate squared difference (Euclidean distance component)
      eucSum += Math.pow(voterVal - cand.vals[o], 2);
    }
    
    let eucDist = eucSum;
    
    // Apply party popularity effect (Popularity acts as gravity, reducing distance)
    const popularityEffect = Math.pow(Math.max(0, cand.party_pop) * 3, 1.4);
    eucDist -= popularityEffect;

    // Apply specific election swing/momentum if present
    if (cand.swing) {
      eucDist -= (cand.swing * 5) * Math.abs(cand.swing * 5);
    }

I also added a ‘bandwagon’ momentum simulation, for when a party gains vote share because of a positive event, this effect is stretched over multiple weeks, to represent real-world poll bumps:

// Calculate momentum from recent performance
if (candidate.previous_popularity !== undefined) {
    const momentumChange = candidate.party_pop - candidate.previous_popularity;
    // Momentum factor - carry forward 30% of recent change
    candidate.momentum = (candidate.momentum || 0) * 0.7 + momentumChange * 0.3;
}

// Incumbency effects - popular parties face erosion, struggling ones get recovery
let incumbencyEffect = 0;
if (candidate.party_pop > 10) {
    incumbencyEffect = -0.1 * (candidate.party_pop / 20); // Voter fatigue
} else {
    incumbencyEffect = 0.05; // Small recovery boost for struggling parties
}

// Bandwagon effect - leading parties get small boost
let bandwagonEffect = 0;
if (candidate === leader && candidate.party_pop > 15) {
    bandwagonEffect = 0.2;
} else if (candidate.party_pop < -10) {
    bandwagonEffect = -0.1; // Additional losses for struggling parties
    }

The distance formula above was a good start, but it made voters switch too easily. To fix this, I added two feature - softmax, and apathy. I added a drifting trend feature - to add another level of dynamic voter relationships, where the voters’ opinions change slightly, forcing the player to decide to pander to the news cycle, or stick with their principles and hope the opinions of the electorate shifts back, before they lose their chance to grab extra voters. Instead of a hard binary choice, the voters use probabilistic voting using a Softmax function - this introduces realistic noise and allows for actual upset victories if traditional parties drift too far too quickly.

export function applyTrendStep(
  trend: ActiveTrend,
  countryValues: PoliticalValues,
  votingData: number[][]
): TrendStepResult {
  // ... shift calculations ...
  const clampedValue = Math.max(-100, Math.min(100, nextValueRaw));
  const actualShift = clampedValue - currentValue;

  // Apply the shift to individual voter data
  if (axisIndex !== -1 && votingData[axisIndex]) {
    const axisData = votingData[axisIndex];
    for (let i = 0; i < axisData.length; i++) {
      // Add noise so voters don't move as a perfect monolith
      const noise = actualShift === 0 ? 0 : (Math.random() - 0.5) * Math.abs(actualShift) * TREND_VOTER_NOISE;
      const newVal = axisData[i] + actualShift + noise;
      axisData[i] = Math.max(-100, Math.min(100, newVal));
    }
  }

An example of a temporary trend (pro-globalist).

I also had to solve the ‘centrists flip-flop very easily’ problem. To counter this, I added Turnout Gating and Loyalty Inertia. If the least-bad party is still mathematically distant (defined by a TOO_FAR_DISTANCE constant), then they simply stay home. Voters have memory - the engine tracks LAST_CHOICES and applies a LOYALTY_UTILITY bonus. You can’t just flip a voter by changing one policy - you have to break their existing habits and loyalty bit by bit.

News and Events

To model the event cycle, I decided to lean into the newspaper-style UI I’d already build, and treat the events as news articles.

To make each game feel more dynamic, I have some dynamic elements in the headline generation - again, there’s a massive JSON file with a bunch of headlines and what triggers them, such as the player professing support for a specific policy, or a national trend, with code that looks a bit like this:

switch (valueKey) {
    case "soc_cap":
    if (voterPosition > playerOldPosition) {
        const votPrefNews = [
        `${nameChoice}'s Pro-Business Stance Boosts Voter Confidence`,
        `Voters Applaud ${nameChoice}'s Economic Growth Agenda`,
        `${nameChoice} Declares: 'Let the Market Decide!'`,
        // ... strings ...
        ];
        voterPreferenceAnalysis.push(votPrefNews[Math.floor(Math.random() * votPrefNews.length)]);
    } else {
        const votPrefNews = [
        `${nameChoice}'s Social Spending Push Resonates with Voters`,
        `Public Backs ${nameChoice}'s Vision for a Fairer Society`,
        `${nameChoice} Promises 'Healthcare for All'—Crowds Erupt in Cheers`,
            // ... strings ...
        ];
        voterPreferenceAnalysis.push(votPrefNews[Math.floor(Math.random() * votPrefNews.length)]);
    }
    break;

When I moved from the original single election day simulation to instead simulating the vote polling for each week leading up to the election, I needed to write a game state:

case 'NEXT_POLL':
    if (state.currentPoll >= state.totalPolls) return state;
    
    const nextPollNum = state.currentPoll + 1;
    // ... trend logic ...

    const { results: newResults, newsEvents } = conductPoll(votingDataRef, state.candidates, nextPollNum);
    
    // ... polling analysis logic ...

    // Combine all news sources into a single array first
    const allNewsItems = [
    ...trendNews,
    ...state.playerEventNews, 
    ...newsEvents, 
    ...partyPollingNews
    ];

    // Sort the combined array by word count in ascending order to create visual variety
    const sortedPoliticalNews = allNewsItems.sort((a, b) => {
    if (Math.random() < 0.6) {
        return (a.split(' ').length - b.split(' ').length);
    }
    else { return 1;}
    });

    return {
    ...state,
    currentPoll: nextPollNum,
    pollResults: resultsWithChange,
    politicalNews: sortedPoliticalNews, // ... etc
    // ...
    };

As you can see, it’s built as a sort of state machine, where NEXT_POLL takes the game to the next state, and START_COALITION_FORMATION begins the coalition formation, etc etc.

Coalition Algorithms

Speaking of coalitions, they actually function very similarly to the voting - I calculate the Euclidean distance between the largest party and its potential coalition partners, but importantly I add extra conditions for opposing viewpoints (for example, a party with a weak nationalist viewpoint would have better compatibility with a party with a strong nationalist viewpoint, than a party with a weak globalist viewpoint.)

I soon added more features on top of simple ‘compatibility’ though - you can form a ‘government’ made up of cabinet positions. Not all ministries are created equal - we assign importance weights for each position, based on the parties’ ideologies - Green parties will demand the Environment Ministry, while Militarists will fight for Defence and Foreign. The engine will dynamically generate these demands, as well as policy requests.

Features and Customisation

I’m pretty proud of the flexibility I’ve managed to keep:

• JSON-Driven Data: All the party data is stored in a massive JSON file. This makes it incredibly easy to add new scenarios without breaking the core engine.
• The Campaign Loop: Instead of an instant result, the game plays week-by-week. You get prompted with events (e.g., an economic scandal or a foreign policy crisis) that shift the coordinates of either the parties or the voters themselves.
• The Custom Party Builder: I realised this was a must-have to make anybody other than me interested in the game. You can merge parties into a coalition or build a new one from scratch, manually setting their -100 -> 100 values on each of the seven axes.

Go check it out at polplay.indigo.spot!

TLDR: I got way too into a Crusader Kings 3 game playing as Croatia, started writing in-character peace treaties with my friend, then wrote an entire religious text, and now I’m writing a full Wikipedia-style wiki (kresimiria.wiki) about the fictional country using Jekyll. It’s worldbuilding without the (sometimes) annoying parts of actual storytelling.

If you really want the longer story, a couple of years ago, I was playing Crusader Kings 3 with my close friend Theo. He was playing as Austria, and I picked Croatia, playing as King Kresimir IV. If you’ve ever played CK3, or any Paradox game, you might know how these games go - you start with modest ambitions, maybe unite a kingdom or two, and then suddenly you’ve conquered the entire Holy Roman Empire, or at least that’s what I did. I don’t usually play aggressively, and I much prefer roleplaying to the military aspect.

So, here’s where it gets more intricate. I got so attached to the characters and the world we were building that I started writing actual peace treaties with Theo. We are both just as pedantic as each other, and he kept raising problems with the way I was running my realm, and pointing out tiny tiny violations of our verbal agreements - so we agreed to start writing proper formal documents in Microsoft Word. We wrote full-blown treaties, with clauses and signatories and all that diplomatic nonsense. We were roleplaying hard. (Can you tell I wanted to be a lawyer when I was younger?)

Here is a sample of our first peace treaty, an alliance agreement:

Then I took it even further. See, I was making some… let’s say extremely questionable religious choices in the game, and Theo kept giving me grief about them. So naturally, the only reasonable response was to write an entire religious text to justify myself. I called it the Books of Kresimir, and don’t worry, I’m not just talking about a paragraph or two - I wrote many many chapters. I even added scripture formatting, which took way too long in Microsoft word (I guess it’s not a frequently requested template?)

Here’s a random page from the Books: (You’ll notice distinct similarities to Genesis and other chapters of the Bible - I did take inspiration from much of the structure.)

Eventually we stopped playing the actual Crusader Kings game, but I wasn’t done with Kresimiria. I wanted to keep writing in this world, so I started creating laws. Government structures. I wrote an entire 1921 constitution, along with a historical precedent for it, a group of constitution signatories (‘founding fathers’ if you will) and a map.

The map of Kresimiria (remember, you can see all of this at kresimiria.wiki).

Eventually I migrated everything to Google Docs where I could actually organize things properly - I set up specific councils, laid out in the Constitution, for different types of laws, sorted everything by topic, the works. But then, often while I was meant to be studying, I started writing electoral history. As in, for each election in Kresimirian history, I wrote who ran, who won, what the percentages were, all of that. I made an Excel spreadsheet tracking senators across ten different districts over time, and I had text documents that looked like this:

    District V
------------------
Nika Radman (RPP) 49.5% (elected)
Dora Martinovic (RPP) 34.2% (elected)
Karla Vukovic (Indp.) 10.1%
Teo Subotic (Indp.) 6.2%

You get the idea. Lists and lists of election results, all sitting in plain text files and spreadsheets.

At some point I looked at this mess of documents and thought “there’s got to be a better way to display this.” I started searching for Wikipedia-style Google Docs templates. Couldn’t find anything that actually worked well. The formatting was always wrong, or the linking was broken, impossible to use, or it just looked terrible. So I kept researching. I tried hosting my own MediaWiki instance. I looked into services like Miraheze that would host it for me. I got to the final step of the Miraheze servers, but they’re free, and so you have to apply for one - I don’t really want all my content controlled by a largely unknown third party. I got bored and frustrated with the whole MediaWiki ecosystem pretty quickly. It may be powerful but it’s too annoying and cumbersome for me to be bothered, and I really didn’t want to host it somewhere.

Then it hit me. I’d just started using Jekyll for this blog you’re reading right now. Jekyll is literally designed for creating websites from Markdown files. And guess what? Wikipedia articles can just be Markdown files. I didn’t need some heavyweight wiki software. I just needed a static site generator and some Wikipedia-looking CSS.

Building kresimiria.wiki

So I spent a couple of days whipping up custom CSS and HTML to make a Wikipedia clone. ‘Borrowed’ some styling ideas (basically copied Wikipedia’s infoboxes almost exactly), tweaked the layout, made it look like a proper encyclopedia. I added some Markdown articles, made a homepage, and voila, proof of concept achieved. (Have a look at kresimiria.wiki).

And then I just - kept writing. Politicians, businessmen, soldiers, businesses and organizations and companies, legal cases, both landmark and mundane, historical events, cultural movements, sports teams, the whole ecosystem of a functioning country.

Here’s what I love about this project: it’s writing, but it’s only the fun part (in my opinion). There is absolutely something to be said about crafting a detailed plot, witty dialogue, and snappy pacing - but I’m not very good at that. Whenever I’ve tried to write a novel, I always get stuck somewhere, and slowly lose motivation as I drown myself in my world. But I am yet to get writers’ block with this. Sometimes you just want to describe how a tax system works or the results of a regional election without worrying about whether your protagonist cares about it. (Frank Herbert would get this - do you remember when pages and pages of Dune would just be explaining the economics of the spice trade?!)

With Kresimiria, I can just worldbuild forever. I can write an entire article about a minor political figure who was only relevant for six years and never won a seat in parliament. I can detail the career of a businessman who founded a chain of local shops, just for the purpose of making the region feel lived-in. I can write about a legal case establishing precedent for the modern day in the country without having to tie it into anyone’s character development.

The best (or worst?) part is I don’t know if this project will ever be ‘done’. There’s always another business to create, an even more minor politician to write about, another cultural figure to make. And I think I’m fine with that - it’s become my go-to creative outlet as a source of relaxation. I’d recommend it to anyone who is an embarrassingly massive nerd, is creative, but doesn’t have the discipline to finish a novel.

(Remember, go check it out! Kresimiria dot wiki.)

I knew this would mean partitioning my main NVMe drive - so I dutifully ignored all the massive red warning boxes in every tutorial telling me how dangerous this was when it was the only place I had a running linux system. While I could have easily wiped my drive and started fresh, my goal was to perform this surgery without losing my stable Fedora install. I’d heard all about how unstable Arch Linux was, and I ideally wanted to have some system alive and ready to run in case I needed to do, you know, things like Bluetooth, Wifi, use my microphone, external displays, that sort of thing.

The Partitioning Surgery

My first move was to try and partition from within Fedora. This was a non-starter; you can’t resize the foundation while you’re standing in the house. The solution was booting from a dedicated GParted Live USB to perform the operation from a neutral environment.

I shrank my main btrfs partition and created two new ones:

1. An ext4 partition for the Arch root (/).
2. An ntfs partition for my shared /data drive. (Pro-tip - using ntfs is a life-saver, as it avoids all the Linux uid/gid permission headaches between two different distros).

Let’s use archinstall, right?

With my partitions ready, I booted from my Arch Live USB. My secret weapon, I thought, would be the archinstall script I’d seen on YouTube. I’ve used Linux before but I was doing this in my spare time and I didn’t want to spend hours setting up arch. This script was supposed to automate the whole process.

I ran archinstall, selected ‘Manual partitioning’ (so it didn’t overwrite my entire Fedora install) and pointed it at the new partitions I’d just made earlier:

• /dev/nmve0n1p5 (my ext4 partition) - mount point /
• /dev/nvme0n1p1 (my existing EFI partition) - mount point /boot/efi

I hit install, and … ValueError: mount point is not specified

I went back and did it all again. From the beginning. Fresh Arch install, archinstall, iterate through. Same error. I dug deeper. I googled a lot. I made sure my EFI partition was marked with the Esp. I googled even more. The archinstall script, it turns out, is fantastic for clean installs, but gets very confused when I try to manually partition my drives. While great for clean installs, gets very confused by existing multi-boot setups. Fedora also often maps multiple subvolumes together nowadays, in a way that makes discovery tricky. It was time to do it the real Arch way.

The Real Arch Way™

I had to abandon the script and go manual. Time to pull up the Arch Wiki.

• mount /dev/nvme0n1p5 /mnt
• mkdir -p /mnt/boot/efi && mount /dev/nvme0n1p1 /mnt/boot/efi to mount my partitioned drives
• pacstrap /mnt base linux... to install the core system.
• genfstab -U /mnt >> /mnt/etc/fstab to set up the partitions.
• arch-chroot /mnt to go “inside” my new system.

Now I was inside the system. I created my user accounts, set my locale, my passwords, all of that. Now just the bootloader so the next time I logged in it doesn’t just explode my entire system…

GRUB

I first ran grub-install - efibootmgr not found. A quick pacman -S efibootmgr fixed that, but it was a sign of what was to come.

I had decided to keep GRUB for its os-prober feature, as I was led to believe this would automatically find my Fedora installation. No such luck, unfortunately.

• grub-mkconfig failed: os-prober ran but found… nothing. It turns out, I’m not smart enough to figure out how to get os-prober to scan Fedora’s btrfs subvolumes, even with btrfs-progs installed. I’m still not 100% sure if I had something misconfigured, but I pushed forward anyway.

The solution was to stop relying on automation and write a manual chainloader. My first attempt failed, but the final, working solution was adding this to /etc/grub.d/40_custom:

menuentry "Fedora" {
    search --no-floppy --fs-uuid --set=root YOU-DONT-NEED-MY-UUID
    chainloader /EFI/fedora/grubx64.efi
}

I rebooted my laptop, and the beautiful GRUB menu appeared. I could boot into Arch. Wonderful.

Shared partition

I rebooted again, this time into Fedora.

sudo mkdir /data, sudo nano /etc/fstab - I added the magic line for my ntfs drive, gave myself ownership of it. I tried to move some of my documents into /data. Permission denied.

My old nemesis. I ran findmnt /data and saw the problem - my root drive hadn’t mounted at all. I looked back at my fstab - a lovely little typo, ntfs instead of ntfs-3g. I fixed it, ran sudo mount -a and tried again. This time, it worked! I moved all of my documents, game saves, pictures, all that fun stuff, into my data drive, and then scribbled down a little list of software I would need to reinstall on Arch (raw image viewers, VS code, browsers, PDF viewers, Discord, Spotify, I could go on).

Caelestia

I cannot thank the team behind the caelestia dotfiles enough. The Hyprland config, along with the Quickshell config, makes this the prettiest operating system I’ve ever used, with almost no competition.

After less than an hour of installing fish and all the pre-requisite packages, running the installation scripts, erroring, debugging, rebooting, and tweaking Hyprland config, I was satisfied. Here are some of my custom configs:

#--# hypr-vars.conf
$browser = firefox
$editor = code
$touchpadDisableTyping = false
$workspaceGaps = 10
$windowGapsIn = 5
$windowGapsOut = 10
$singleWindowGapsOut = 5
$windowOpacity = 0.95
$windowRounding = 10

$kbMoveWinToWs = Super+Shift 
$kbSystemMonitor = Super, Escape

Look at this. Could you ever go back?

Final thoughts

One of the most surprising things I experienced was when I plugged my laptop into my HDMI cable, fully expecting absolutely nothing to happen, the display to tear, or some horrendously scaled image to appear - only for a beautifully intact, perfectly scaled monitor to materialise in front of my eyes. It actually worked better on Hyprland / Arch than it did on Fedora with GNOME. There’s no going back now.

Yes, it does get a bit tiring connecting to WiFi and Bluetooth devices with my terminal using nmcli dev wifi connect "eduroam" and bluetootctl devices, but it’s probably good practice for me to understand more about the operating system anyway - for when it inevitably breaks and I need to fix it on the fly.

Most importantly, I can now, finally, say:

“I use Arch, btw”.

Happy days.

One day in school, I remember one of my classmates going: ‘Indy, what happened to your website? I liked the trapezium thingy you had…’. Now, while he meant this as a compliment, for me it was a moment of sudden clarity. The ‘trapezium header’ was a complicated, animated header that I’d spent a weekend building. And that was the problem - the single most memorable part of my portfolio site wasn’t anything about me, my projects, or any of my content - it was some gimmicky, and frankly cheap, animation.

Over the most recent summer, I redesigned my site once again, making sure to prioritise accessibility, usability, and reducing the cognitive load of anybody who visits it. Not only was it tons of fun, I learnt quite a lot in the process.

Flashiness is definitely tempting

Look, let’s be honest - overengineering a personal site is a rite of passage for any developer. It’s your own space with no limits, no product managers, no clients, and no real-world constraints. It’s the perfect place to try out any obscure library or parallax scrolling effect you’ve just seen on social media.

This impulse comes from a very good place - genuine love for the craft and a desire to push your own skills. But it comes, in my opinion, at the cost of the very reason someone visits our site in the first place - to learn who we are, what we’ve built, or read what we’ve written. The flashy animations aren’t communicating anything about us, other than the fact that we had a spare couple of days to wrestle with uncooperative CSS transforms.

Evaluating ‘hidden taxes’

Whenever designing anything, it’s important to look for ‘hidden taxes’.

For example, the accessibility tax. Let’s take a typewrite effect as an example. Yes, it’s possible to create accessible companion elements for screenreaders - but natively, they will often try and read out each letter as it appears, resulting in an indecipherable mess. The scroll-snapping that feels so slick with a trackpad? It makes keyboard navigation a frustrating battle. Finding someone’s website and discovering they haven’t made it usable on a phone is a frustrating experience, but the main person who loses out is them, not me, as I’ll just immediately close the site.

If your design relies on a single, optimal way of being experienced, it is (for the most part) inherently exclusionary. That said, this doesn’t apply everywhere - for example, it makes sense for VR experiences to not support screen readers, et cetera. But you know what I’m trying to say - experiences that want to be accessible to everybody but aren’t. A website that isn’t navigable by keyboard or comprehensible to a screen reader will ultimately result in a high bounce rate.

There’s also the performance tax. I like websites which have background images, I must admit. I’ve had one periodically on my site - there might even be one there while you read this very article. But any vaguely high-resolution image, not to even speak of all the heavy JavaScript libraries, meant my site took an eternity to load on anything less than a high-speed connection. Forcing a visitor to download megabytes of assets just to see my email address is poor communication. A lightweight, fast-loading site is essential to get across who you really are without bothering with the fluff.

Last and possibly the most important is the cognitive tax. The entire point of a personal / portfolio site is communication. You are selling yourself. Every unnecessary animation, every unexpected layout shift, every element that vies for attention, actively works against that purpose. It creates cognitive noise, forcing the user’s brain to work harder to filter out the rubbish and find the information they came for. A user shouldn’t have to fight your design to get to the content they want! I’ve always liked websites that are upfront and clear about what exactly they offer.

The ‘cosy human’ approach

So, what is the alternative then, a boring old text document? No, calm down. The opposite of ‘flashy’ isn’t ‘dull and colourless’, it’s ‘thoughtful’.

My goal for my redesign was to create a space where I could store my things on the internet, at the same time as selling myself. I wanted a space that felt human, calm, and welcoming. I’m not just a developer, I’m also a writer, a photographer, and I don’t want to limit myself by creating a website that looks like it came straight out of a 2000s hacker movie.

I swapped out my geometric coding monospace font for a warmer, more handwritten one: Syne Mono. I think it strikes a very good balance between something that works for displaying codeblocks, and friendly.

I did the same with the colour palette. I moved away from high-contrast blacks and whites to a softer, pastel-adjacent scheme that I think feels calmer. Hopefully all the text is still readable, but I feel it provides a comfier atmosphere.

I mentioned being ‘upfront and clear about what your site offers’. This is what my landing page attempts to be - a form of main menu, with options prioritised by the order I want users’ eyes to follow. I’ve previously had an ‘About Me’ first, and then a button to access my projects, but as I grew my site, adding various different things, I found myself getting overwhelmed and cramped and not sure where to put everything. A way to solve this is an easy-to-navigate menu, meaning I can add more information to the site later and I simply have to expand the main menu, not refactor the entire site’s design.

Perhaps most importantly, I embraced whitespace. Whitespace is a wonderfully underutilised design tool. My old site was crammed with elements and I was terrified of leaving a single pixel empty. Negative space is not simply ‘empty’ - it’s an active design element that reduces clutter, allows the content to breathe, and guides the user’s eye to what’s important.

Of course, a personal website is one of the few corners of today’s internet that you can really own. It doesn’t need to conform to the engagement-driven design of social media, or the conversion-focused layout of a company’s landing page. It can be simply you. Don’t let me tell you how to build your websites. Let your creativity run wild, by all means. But keep your eye on the goal - a pleasant experience for everybody who stumbles across it.

My old site reflected a version of me that was eager to shout his technical skills (or what I’m learning of them) from the rooftops. I hope, at least, that this new one reflects a version of me that is more interested in thinking thoughtfully and creating a calming space where you can find out more about me and what I do. And while I do occasionally miss the novelty of the huge sliding trapezium I used to have, I’ll take an easy-to-scale, easy-to-maintain, and easy-to-access user experience every time. Look at your own little corner - what is the most memorable part of your site? Is it flashy animations, or is it your personality and your voice?