For a couple of weeks I ran squad-based agent delivery on PocketRPG, my tick-based idle RPG. This is what I learned, when I’d still reach for a squad, and why I ultimately tore mine out.
The idea is seductive because it maps directly onto how real software teams work. Instead of one agent doing everything, you define a roster of roles as markdown charters that live in your repo: a technical BA that turns a feature request into a breakdown with acceptance criteria, a read-only architect that produces the implementation plan, domain builders (in my case a gameplay engineer, a frontend designer and a backend developer) that write the code, and an adversarial QA agent that tears the finished diff apart at the end.
A lead session triages each task, spawns the roles it needs, hands each one a prompt with a goal, a set of owned files and acceptance criteria, then integrates the results. Builders get disjoint file ownership so they never fight over the same file. QA judges the integrated diff against the written criteria rather than trusting the builders’ own reports.
And I want to be honest here: it works. An agent told “you are adversarial, your job is to find where this change is wrong” catches bugs that a generalist agent, fresh off writing the code, sails straight past. The BA step catches ambiguity before anyone writes a line. The quality was real.
Anthropic’s engineering write-up on their multi-agent research system puts a number on the cost: multi-agent setups burn roughly fifteen times the tokens of a normal session. My experience matched that almost exactly. Squad-tier tasks on PocketRPG came in at around 15x what the same work would have cost in a single session.
The multiplier stops being mysterious once you trace where the tokens go. Every spawned agent starts cold. Each of my five or six roles independently re-loaded the always-on project context, re-read the same engine files the lead had already read, got re-briefed on constraints the lead already knew, and then wrote a prose report the lead had to hold in its own context to integrate. Same files, same rules, paid for five times per task.
There’s a subtler cost too, and Cognition’s Don’t Build Multi-Agents is the best writing on it: the telephone game. When you split dependent work across agents, decision-making disperses and context degrades at every handoff. Their example is a Flappy Bird clone where one subagent builds a Super Mario background and another builds a bird that moves nothing like the real thing. It’s funny right up until your backend agent and your frontend agent make subtly incompatible assumptions about a save-format field, and QA is the first to notice.
I don’t think the architecture is wrong. I think it’s specific. Reading across Anthropic’s post and the wider research, a squad pays for itself when three things are all true.
The work has to decompose into genuinely independent directions. Breadth-first research is the canonical case: due diligence, competitive analysis, literature review. Ten subagents reading different sources in parallel, each compressing findings into a summary, is a real win because the parallelism is real.
The subtasks have to benefit from walled-off context. Specialised code review is a good example. Security, performance and API-contract reviewers don’t need to coordinate, so fanning them out costs little and each specialist genuinely beats a generalist.
And the task’s value has to cover the multiplier. Anthropic is blunt about this: the economics only work when the answer is worth a lot of tokens.
Sequential feature work on a single codebase fails all three. My architect’s plan fed the builders, and the builders’ diff fed QA. Nothing actually ran in parallel; everyone waited on everyone else, so I paid the coordination tax and never collected the parallelism dividend. Everyone needed the same context, which is precisely the situation the research flags as a bad fit. And “add a slayer task chain to an idle RPG” is not legal due diligence. The answer was never worth 15x.
The insight that made the migration easy is that the squad’s quality never came from process isolation. It came from role discipline: the BA’s evidence-first breakdown, the architect’s file-level plan, QA’s adversarial framing. Discipline transfers to a single agent for free. You don’t need a separate process to make an agent wear a different hat; you need the hat written down.
PocketRPG now runs what I call a delivery loop. One agent, one session, moving through dedicated steps. The role charters became step charters. Plan always runs and does the old BA work, resolving unknowns from repo evidence and emitting executable success criteria. Architect runs only when the work crosses a real boundary, like a save-format change or a migration. Engineer is one step for all the code, whichever domain it touches. World Designer runs for content and map work, which in a game codebase is a genuine discipline of its own. QA always runs, still adversarial, judging the raw diff against the criteria written down in the Plan step rather than against what the engineer step concluded.
The inter-agent plumbing got replaced by three small habits. The agent announces each step as it enters it, so the discipline is auditable in the transcript. Each step ends with a five-line handoff note covering decisions, files touched and open findings, so later steps rely on notes instead of re-reading. And a triage fast-path skips the loop entirely for trivial work, because ceremony on a typo fix burns tokens the same way a squad does, just more slowly.
I kept exactly one kind of subagent: read-only search agents for broad fan-out questions.
Those read-only agents are the inverted case. They move file dumps out of the main context and return only conclusions, so they reduce net tokens rather than multiplying them. Writes stay single-threaded, which is Cognition’s middle ground too.
The honest trade-off is reviewer independence. Squad QA started cold and couldn’t inherit the builder’s blind spots; step QA shares a context with the code it’s reviewing. Pre-written criteria recover most of that, because the QA step is graded against a contract that existed before the code did. And if quality ever slips, the cheap escalation is a single cold review on demand, not a standing squad.
A study out of UIUC, summarised well in Augment Code’s comparison guide, measured multi-agent overhead at anywhere from 4x to 220x the tokens of a single-agent equivalent, and found that with the budget held equal, a single agent matches or beats the multi-agent setup on dependent, multi-hop work. Read that range the other way round: moving to a single agent saves you anywhere from 4x to over 200x on the same work, depending on how badly your task fits the pattern. I was living at the 15x mark. Some teams are paying far worse without knowing it.
Ultimately, this comes down to the same instinct I apply everywhere else in engineering: measure what a practice costs, not just how it feels. The squad felt rigorous. Watching five specialists coordinate reads as maturity. But rigour that costs 15x and produces the same diff isn’t rigour, it’s theatre with a metered API key. Write the hats down, make one agent wear them in order, and spend the savings on shipping more.
]]>So I built a helper. A little 💬 button in the corner of the game that answers questions about PocketRPG — and only PocketRPG. This post is about why I did it, and how I did it without adding a single penny to my hosting bill.
The honest answer is that the game got deeper than the documentation. Idle supplies, slayer tasks, combo food, auto-banking tied to your Agility level — mechanics stack up, and every player arrives at them in a different order. A chatbot flips the model: instead of me guessing what players need to know, they tell me. And because it can read the player’s own character, the answer isn’t generic. “What should I do next?” gets answered with your stats, your slayer task, your bank.
The second reason is less noble: I wanted to see if I could do it for free. Properly free. Not “free until it isn’t.”
The whole game runs on Cloudflare Pages, so the chatbot lives there too, as a Pages Function. Workers AI gives you access to hosted open-source models with a free allocation of 10,000 “neurons” a day — neurons being Cloudflare’s billing unit for inference. The model I settled on is GLM-4.7-Flash, which is remarkably cheap ($0.06 per million input tokens), handles multi-turn tool calling well, and — I learned this the hard way — is actually still available. My first choice had been deprecated a month before I wired it up, and I spent an evening staring at error 5028 wondering what I’d broken.
A model on its own will happily invent drop rates. I didn’t want that, so the helper is grounded two ways.
First, a knowledge index. My player guide is a markdown file; a build script chops it into chunks and bakes it into the worker. Every question runs a lexical search over it, and the best matches get handed to the model as context with strict instructions: answer from this, or say you don’t know.
Second, tools. PocketRPG already has an MCP server so AI assistants can play the game, and the chatbot borrows a slice of it — a read-only allowlist. It can inspect items, look up monsters, check your slayer task. It cannot spend, equip, or sell anything, and the character ID is pinned server-side so it can only ever see the person asking.
This is the part I’m most pleased with. I’m on the Workers Paid plan, which means going over the free allocation quietly becomes a bill. I didn’t want a soft limit; I wanted a mathematical one.
Every message reserves its worst-case cost up front in a little D1 ledger — before any AI call happens. If the reservation doesn’t fit inside the day’s budget, no call is made. When the answer comes back, the actual token usage is metered and the unused reserve is refunded. The budget itself sits below the free allocation, with the gap sized so that even a message in flight can’t push actual spend over the line. Failures make it more conservative, never less: if anything goes wrong mid-request, the full reserve stays charged. There is no code path where I pay.
The helper doesn’t just go dark when the day’s allocation is spent. It degrades to retrieval-only answers: the same knowledge search runs, and you get the relevant guide sections verbatim instead of a generated reply. Less polished, still useful, costs nothing. The player’s daily question isn’t counted against them for a degraded answer either — that felt only fair.
Ultimately, this was a project about constraints. Free-tier limits, a deprecated model, a hard rule that I’d never pay for a single message — every one of those constraints made the design better. The result is a helper that knows the game, knows your character, admits what it doesn’t know, and runs on a budget of exactly zero. That’s a standard I can live with.
]]>This is a write-up of how it’s built, for a technical reader. I’ll cover the stack, the server-authority model, the way I’ve used Cloudflare’s free tiers, the save system, PvP, the economy and the responsive UI. I’ve left out anything that’s an actual secret or key; where a detail is sensitive I’ve described the mechanism instead.
The client is Preact rather than React. For a UI that’s mostly lists, grids and one combat screen, the full React runtime would have been weight I didn’t need, and Preact is a few KB. State lives in a Preact context with hooks. The game logic sits in separate modules that don’t import anything from the UI.
That last point is a hard rule in the repo: src/engine/ is pure game logic with no UI imports. The combat formulas, the XP curve and the loot rolls are all deterministic and can be tested on their own. The tick is 600ms, gameplay rounding always uses Math.floor, and the same inputs produce the same outputs every time. That determinism is what makes the regression tests worth having, and it’s also what later made server-side PvP feasible.
Dev and the normal build run on Vite. There’s an extra TypeScript transpile step feeding a custom concatenator, because the production artifact is a single index.html: every module transpiled and stitched into one file with Tailwind pulled in from a CDN, served as a static asset. For an offline-first app that means one file to cache and no module waterfall to resolve over a poor mobile connection.
Concatenating everything into one scope has a downside. Every top-level declaration has to be globally unique, or you get a duplicate-identifier error that breaks the whole app. A check:single step parses the output and fails the build if, say, two modules both define a top-level formatGold. It’s caught me a few times, which is the point.
The backend is Cloudflare Pages, Pages Functions and D1, with nothing else behind it.
/api/* is a function. The free plan has a daily request limit (100k/day at the time of writing). An idle game doesn’t need to talk to the server constantly, so that ceiling is comfortable.That billing model shaped the data design more than anything else, and I’ll come back to it. The result is that auth, cloud saves, a leaderboard, the economy and PvP all run for nothing a month, and the architecture doesn’t need to change when usage grows past the free tier. It’s the same Pages, Functions and D1; the only thing that changes is the bill. The design already respects the limits that scale would impose.
Deploys are driven from git. A push to a branch triggers a build and ship. Preview has its own D1 database and production has another, so I can test against realistic data on preview without touching live accounts. wrangler.toml wires the bindings, and secrets (the JWT signing key, OAuth client secrets, Stripe keys) live in the Pages dashboard rather than the repo.
Most of the more interesting decisions come from one assumption: the browser is untrusted. Not because players are malicious, but because anything in client memory can be edited, and an editable client means there’s no real economy to speak of.
So the client computes and displays progression, but it doesn’t get to commit anything that matters. XP ticking up as you grind, coins from a common drop, the HP bar: the client handles those locally and they feel instant. When something with economic weight happens (a boss unique, a raid drop, a clue reward, a credit purchase, a PvP loot transfer) the server is the only thing that writes it, and it validates the change itself.
That’s easy to say and a steady discipline to keep, because the convenient option is always to trust the save blob the client uploads. I did a hardening pass to close that gap, and it left a clear split:
PUT /api/save is a sync channel for non-economy state: UI settings, theme, the current task, HP. When a save arrives the server doesn’t store it wholesale. It diffs the incoming blob against its own copy and rejects any increase in protected items (boss, raid and clue uniques) that didn’t arrive through a proper grant. Items that legitimately drop client-side from monsters and clues are on an allowlist and pass; anything else trying to appear in the bank is discarded./api/actions/monster/complete, /api/actions/raid/complete, /api/actions/clue/complete and so on. Those are the only authoritative grant paths, and each one validates every reward item against the canonical drop table for its source. Request a raid unique from a monster that doesn’t drop it and the response is a 403.The save ends up in three zones: server-owned (XP, bank, inventory, equipment, slayer points, never accepted from the client), client-owned (UI state, current action, theme) and revalidated (levels, which have to match what the server recomputes from the XP it holds). The client can claim any combat level it likes; the server recomputes it and ignores the claim.
An idle game has to save often. The tab can close at any moment and the player expects to return exactly where they left off. The client saves on a short cadence and on every meaningful event (a kill, a clue completion, a minigame finish, a level-up), plus a heartbeat every 30 seconds while an active task runs.
Saving often against a database billed per row written needs some care. The approach is that a save is one row. Each character has a single row in saves, and a write is one UPDATE. There’s no row per inventory slot or per skill; the whole state is one JSON document, gzipped into a blob column. Compression takes a fair chunk off a typical save, and a hard size ceiling stops a corrupted or oversized blob being stored.
Integrity comes from optimistic concurrency on a save_revision counter. Each save carries the revision it believes it’s editing, and the write is a compare-and-swap:
UPDATE saves
SET save_blob = ?, save_data = ?, updated_at = ?, save_revision = save_revision + 1
WHERE character_id = ? AND save_revision = ?
If meta.changes is zero, something else advanced the state (another tab or device) and this write is stale. The server returns a 409 with the current revision, and the client pulls fresh and retries. There’s no auto-merge and no grace window. Last-write-wins on game state is how a stale background tab overwrites the raid drop you earned in the foreground a moment ago, so I’d rather the write fail and force a re-pull.
Some state is monotonic and must never move backwards: boss kill counts, the collection log, and the nonces that block replayed actions. Kept in the save blob, a last-write-wins moment or a backup restore could reset a kill count from 500 to 10. So those live in their own tables instead:
kill_counts, incremented server-side with kill_count = kill_count + 1, so it only goes up.collection_log, append-only, with a composite primary key of (character_id, item_id, source_type, source_id) so a replay is an idempotent no-op rather than a duplicate.action_nonces. Every protected action carries a single-use nonce, and the server does an INSERT … ON CONFLICT DO NOTHING on it before anything else. If the row already exists it’s a replay and the action is refused. Because the nonce sits in its own table it stays consumed even if the save blob is rolled back, which matters: replay defence that depends on the save being trustworthy doesn’t work.A separate character_idle_state table is the authoritative record of when a character was last active and what task it was running, and the server stamps it with its own clock. Trusting the client clock for offline progression would let someone wind their system time forward a week and collect a week of rewards.
Reads stay cheap too. The leaderboard and the PvP combat-level band need total_level and combat_level for a lot of characters at once. Rather than joining saves and parsing a JSON blob per row in a Worker, those two values are denormalised onto the characters table and kept current on each save, so the leaderboard is a plain indexed SELECT.
The schema is spread across nineteen migrations but stays fairly small:
oauth_identities: one row per Google or GitHub login, i.e. the account.characters: an identity owns many characters, with unique case-insensitive usernames. It carries the denormalised total_level and combat_level, the ironman and one-life flags, the credit balance, and active_match_id, which is the PvP lock.saves: one per character. Gzipped blob, revision counter, server timestamp.character_idle_state: authoritative last-active time and current task.collection_log, kill_counts, action_nonces: the monotonic and dedup tables above.audit_events: a durable log of high-value mutations such as credit grants and spends, protected reward claims, PvP settlements and trading-post movements. Cloudflare’s console.log output is ephemeral and hard to search, which is no help when a player asks where a drop went, so this is a real table I can query.stripe_events and purchase_grants: payment idempotency and a per-transaction ledger, so a retried Stripe webhook can’t grant twice and I can answer “did this person receive what they paid for” without reading logs.trading_post_offers: the whole player economy in one table.pvp_waiting_room, pvp_matches, pvp_invitations, pvp_intents: PvP.Indexes get the most deliberate attention, because they aren’t free. Every secondary index is more data the database has to write and keep in order on each insert and update, and on a platform that bills per row written, an over-indexed table quietly multiplies the cost of every save. So the default is no index, and each one has to justify itself against a query that actually runs and runs often.
The indexes that exist map onto hot read paths. The leaderboard sorts by total level, so characters has a composite index on (total_level DESC, id). The order book is searched by item and side at a given price, so trading_post_offers is indexed on (item_id, offer_type, status, price, created_at), in that column order, because that’s the order the query filters and then sorts in. The PvP match loop reads unapplied intents by match and tick on every poll, so pvp_intents has a composite index on (match_id, tick_number, character_id, character_seq). Pending invitations get their own index because the lobby polls for them. Composite indexes are ordered to match how a query reads, not alphabetically or by gut feel, since a leading column the query doesn’t filter on makes the index useless to it.
Several of these are partial, with a WHERE clause that trims the index down to the rows that are ever queried. The leaderboard index only covers WHERE deleted_at IS NULL AND total_level > 33, so deleted and brand-new characters never take up space in it. The “one active match per character” constraint is a UNIQUE index with WHERE status = 'active', which does two jobs at once: it enforces the rule (a second active match for either side fails on the constraint instead of on application code I’d have to remember to write) and it stays small, because completed and aborted matches drop straight out of it. A partial index is smaller, faster to scan and cheaper to maintain than a full one, so where a column has a clear “live” subset it’s the natural choice.
The other half of the decision is the tables left almost unindexed on purpose. saves is the hottest write path in the game, and it’s read and written almost entirely by primary key (character_id), so it carries nothing beyond that key; a secondary index there would tax every save for a query that doesn’t exist. Low-cardinality flags like the ironman boolean are the same story, since indexing a column with two possible values rarely helps the planner and still adds write cost. The line I hold is that an index is a standing tax on writes paid in exchange for one read being fast, so it’s only worth adding when that read is both real and frequent.
There’s no password handling in PocketRPG: no password storage, no reset emails, no hashes to leak. Sign-in is Google or GitHub only.
It’s a standard three-leg OAuth flow, written directly against the Workers runtime with no SDK. Hitting /api/auth/google (or /github) generates a random state nonce, stores it in a short-lived oauth_state cookie (HttpOnly; Secure; SameSite=Lax, ten minutes) and redirects to the provider. The redirect URI is built from the incoming request’s host rather than hardcoded, so the same code works on preview and production. The callback checks the state cookie against the query parameter, exchanges the code for an access token using the provider client secret, and uses the provider’s stable user ID (sub on Google, id on GitHub) as the identity key.
Sessions are stateless JWTs signed with HS256 through the Web Crypto API, with no JWT library involved. The token holds the identity row ID, the provider and a display name, and expires after 30 days. Going stateless was deliberate: a protected request is verified with a signature check and no database round-trip, which keeps the per-request row cost at zero and scales horizontally without effort. requireAuth reads the bearer token, verifies the signature and expiry, and hands the endpoint a known identity. Characters attach to that identity by owner_id.
The trade-off is worth stating. A stateless 30-day JWT held client-side scales well but is awkward to revoke. Moving it into an HttpOnly cookie and adding a token-version check for instant revocation is still on the list rather than done.
PvP is where the determinism work paid off, and also where I had to be realistic about what free infrastructure can do.
The engine is server-authoritative and shared. A single pure-logic module, pvpEngine.js, runs both in the client (for a responsive view) and inside the Pages Function (as the source of truth). Clients don’t send “I hit you for 14”. They send intents tagged with a tick number (“eat the food in slot 3”, “queue a special”, “switch to the second weapon”), the server applies them, and it produces the next authoritative state. The client renders state it doesn’t own.
Because the engine is deterministic, the server resolves a tick unambiguously. Within a tick, intents apply in a fixed order (tick_number, then character_id, then a per-character sequence number), timers decrement, then both attacks resolve off the snapshot taken at the start of resolution, so neither player sees the other’s hit before their own lands. If both players die on the same tick, the lower character ID wins. The outcome is identical on every run, which is what you need when two clients and a server all have to agree on what happened.
The 600ms tick is the unit of fairness here. Attack speed, freeze duration, stun length and special-attack energy regen are all counted in ticks rather than wall-clock milliseconds, so latency changes when you see an outcome, not the outcome itself.
Match concurrency is optimistic, like saves. Both clients poll and try to advance the tick, and the advancing UPDATE carries WHERE current_tick = ?. Whoever lands first takes the tick; the other gets changes === 0, re-reads and continues. The database does the arbitration, and it’s the one component both clients already share.
The lock that keeps PvP consistent with the rest of the game is characters.active_match_id. While it’s set, /api/save, /api/idle and /api/purchase all refuse writes for that character. Inventory during a match lives inside the match state and is written back atomically when the match ends. That’s what makes loot transfer trustworthy: the loser’s tradeable items move to the winner’s bank in the same atomic batch that ends the match, coins are special-cased so they transfer despite being flagged untradeable elsewhere, and a forfeit runs through the same path as a death.
Version one of the transport is HTTP polling, roughly every 600ms, so on mobile the state on screen is 600–1500ms stale. It’s near-real-time rather than real-time. I chose polling because it costs nothing and it’s correct, and the upgrade path is already designed: move the match loop into a Durable Object behind a WebSocket. The engine, schema and UI stay as they are and only the transport changes, so I’m not writing combat twice.
The most important economic decision in PocketRPG is that there’s barely any player-to-player economy at all.
MMO economies inflate because the world spawns endless common goods, players sell them to one another, and the gold supply climbs. PocketRPG doesn’t have that loop. The trading post is one table, trading_post_offers, and its order book only accepts three kinds of item: boss uniques, raid uniques and clue rewards, the genuinely rare drops. Everything else falls into one of two buckets. Common items with a shop value are instant-sold to the game at a fixed price, which is a sink with no player on the other side. Everything beyond that is untradeable.
A single gate function decides this: untradeable items are rejected, order-book items (the uniques) are allowed onto the book, and anything else with a shop value goes to the instant-sell path. The same check runs on both listing and search, server-side, so the client can’t push an item onto the market that doesn’t belong there.
The order book is an escrow system. Listing an offer debits your coins or items first and writes them into escrow on your save, and only then inserts the offer and runs matching against the opposing side (cheapest sells first for a buyer, best bids first for a seller, with any price improvement refunded inline). If matching fails after escrow there’s a compensating refund, so you’re never debited for an offer that didn’t take. Partial fills accumulate into coins_pending and items_pending for collection later. Concurrent fills against the same resting offer use a conditional relative update, quantity_remaining = quantity_remaining - ? WHERE quantity_remaining >= ?, so if two buyers race for the last unit the second write affects zero rows, raises an “offer changed” error, and matching moves on to the next offer.
There’s a deliberate gold sink on the way out, too. You can instant-sell an existing listing: it detaches from you, stays in the book at its original price for someone else to buy, and pays you 80%. The other 20% disappears. A small, unique-only economy leaves very few places for inflation to start, and sinks like this cover the rest.
Ironman accounts can’t use any of it, and the server enforces that rather than leaving it to the client to hide the button.
PocketRPG started mobile-first and looked bad on a desktop for a long time: full-width nav tabs stranded across a 1440px viewport, single columns everywhere, no hover behaviour. Fixing it followed one rule: additive only, with the mobile DOM left untouched.
Every desktop change is a Tailwind breakpoint prefix or a hidden md:block / md:hidden toggle. The mobile layout doesn’t change at all; desktop is layered on at md: (768px). That breakpoint is where the bottom tab bar becomes a side navigation rail, single columns become master/detail, and grids widen out. Inventory goes from 4 columns on a phone to 10 on a wide screen, the bank goes to 12, and active combat splits into three panes (monster on the left, log and actions in the middle, inventory, prayers and spells on the right) so you can see the whole fight rather than scrolling it.
The goal was a desktop layout that feels like a desktop game (side navigation, multiple columns, hover and keyboard support, Esc to close modals) rather than a phone frame centred on a big screen. Mobile keeps the compact, thumb-friendly layout with 44px tap targets. The components and logic are shared; only the available space differs. Since it’s all CSS and conditional layout rather than separate screens, none of it needed new logic tests.
Two things caught me out. When a scrolling combat log becomes a grid child it needs min-h-0 on the container or the auto-scroll quietly stops working. And hover styles need wrapping in @media (hover: hover), or they stick on touch devices after a tap. Both are easy fixes that stay invisible until a real device shows them.
The pipeline is deliberately simple. GitHub Actions runs on every push and pull request: install, then npm run ci, which is the full build, the single-file rebuild and the check:single duplicate-identifier guard. The logic regression tests (Vitest, logic-only and deterministic) gate the build through a prebuild hook, so a build can’t be produced with failing tests. Deployment is Cloudflare Pages watching the repo: the preview branch goes to the preview environment and its own database, and main goes to production. There’s no separate CI server or deploy script to maintain.
The commit gate I run locally is the same one CI runs, so passing locally and passing in CI mean the same thing. For a single-file artifact with global-scope constraints, the duplicate-identifier check is the one that catches the most real problems.
A few things I’d repeat on another project of this shape. Designing to the free tier’s actual constraint (for D1, that it bills per row) is what produced the one-row save, the denormalised leaderboard columns and the stateless JWT, and the result was better than if the limit hadn’t been there. Deciding what the server owns up front matters, because retrofitting authority onto a system that trusted the client is slow and error-prone; I know because I did some of it. And keeping the free version and the eventual paid version on the same code, as with PvP polling now and a Durable Object later, means scaling is a transport and a billing change rather than a rewrite.
PocketRPG is still in progress. The JWT-to-cookie move, the WebSocket PvP transport and more economy sinks are all still open. The structure holds up, it costs nothing to run today, and the point at which it starts costing something will be the point at which enough people are playing for that to be fine.
The game’s live if you want to try to break it.
]]>The spark for this was a Jimmy Carr stand-up routine. He talked about how we are fundamentally misaligned with how incredible our current lives are compared to the past. He made the point that we live in a world that would look like a utopia to our ancestors, yet we often feel more dissatisfied than ever. I started digging into the data to see if the objective facts back this up.
If you look at the actual metrics of human life, the progress is undeniable. We have reached a level of safety and comfort that was once impossible.
If the stats are so positive, why is the general mood so heavy? The issue is that while the floor of human existence has been raised, the foundations of a stable life are becoming harder to reach.
Housing is the clearest example of this. We live in a society where a mobile phone, which is a piece of technology more advanced than what put humans on the moon, is affordable. However, a basic house is not. For many people under thirty, property ownership feels like a dream. We can buy the toys of modern life, but the security of a home is slipping away.
Social media complicates this further. It is a powerful tool for free speech and instant connection, but it can also be a toxic influence on young people. It presents a fake reality where we compare our daily lives to a stranger’s curated highlight reel. This creates a persistent sense of lack and fuels depression because we want what others only appear to have.
Capitalism is responsible for the innovation that gives us medical breakthroughs and technology. Yet, it also thrives on our dissatisfaction. It is easy to fall into a cycle where money becomes the only metric of success. We chase the latest designer clothes or the newest mobile just to feel like we are keeping up.
Stepping away from that consumerist lifestyle is good for your health and your bank account. Breaking the mould that society has created involves realising that stuff is not a substitute for well-being. The pressure to constantly upgrade is a trap that keeps you on a treadmill of work and spending.
The solution to this modern malaise is not necessarily more progress. It is self-reflection.
Gratitude is not about ignoring the housing crisis or the negatives of digital life. It is about grounding yourself in the fact that, objectively, we are some of the luckiest people to ever live.
Taking a moment to appreciate the miracles like hot water, clean air, and the ability to speak our minds changes the internal narrative. It is about being mindful of what we actually have instead of focusing on what society tells us we are missing.
]]>In reality, motivation is a delicate ecosystem built on four specific distinctions: Hygiene, Mastery, Autonomy, and Purpose. Proper leadership is not about finding one secret lever; it is about maintaining a constant balance between these pillars. If any one of them is neglected, the connection between the engineer’s craft and the impact of their code begins to break down. You do not motivate an engineer by adding external pressure; you motivate them by focusing on this balance and removing the friction that prevents them from doing their best work.
Before you can inspire an engineer to reach for the “stretch zone”, which is the space just beyond their current comfort level but before the point of total frustration, you must ensure the baseline is covered. Hygiene factors, including salary, benefits, work-life balance, and basic tools, are the table stakes of management.
These factors are critical for retention, but they are ineffective at driving day-to-day engagement. If an engineer is working on a legacy monolith with no test coverage and a deployment process that takes six hours, a 5% bonus will not make them excited to wake up on Monday. Hygiene factors keep people from leaving, but they do not create the drive to innovate. Once the hygiene is settled, you must look toward intrinsic motivators to move the needle.
Engineers are professional problem solvers. When the problems disappear or become repetitive, boredom sets in.
The most engaged engineers are those working in the stretch zone. As a manager, your job is to catalog the specific technical interests of your team. If someone wants to learn Rust, find a low-risk internal tool they can build with it. If they are fascinated by distributed systems, let them lead the discovery phase for the next service.
Nothing kills motivation faster than being told exactly how to implement a solution. When we hand an engineer a 20-page technical specification and tell them to “just code it,” we are not hiring an engineer; we are hiring a compiler.
High-performing teams thrive when they are given problems, not solutions. Instead of saying, “Build a caching layer using Redis with a 10-minute TTL,” try saying, “Our API latency is spiking during peak hours, and it is hurting our conversion rate. How should we fix it?” Giving away the “how” is the only way to get true buy-in.
We often bury our engineers under layers of abstraction. They see the pull request, the build pipeline, and the cloud infrastructure, but they rarely see the human on the other side of the screen. To fix this, you must shorten the feedback loop between code and impact. Motivation thrives when an engineer is exposed to the closing of a cycle, where they can see their contribution reach its destination and solve a real world problem.
This is where the importance of regular sprint ends becomes clear. These milestones are not just for tracking progress; they provide a vital psychological finish line. Closing a sprint provides a sense of achievement and a regular opportunity to see the loop fully closed. Without these intentional moments of completion, the work can feel like an endless stream of tasks without a clear destination.
If you are looking to reset your team’s energy, start by looking at your 1:1s. Stop using that time for status updates; that is what Teams and standups are for. Instead, ask questions that uncover the friction:
Motivation is not a speech you give; it is the environment you build. If you protect their time, respect their craft, and keep these four distinctions in focus, the motivation takes care of itself.
]]>Exact string matching is often insufficient for production search systems because it fails to account for user typos or character variations. Implementing a fuzzy search mechanism allows the system to return relevant results based on string similarity rather than binary equality.
Levenshtein distance, or edit distance, is a metric used to measure the difference between two sequences. It represents the minimum number of single-character edits required to transform one string into another.
The allowed operations are:
In the field of genetics, this algorithm is fundamental to DNA sequence alignment. By treating the four nucleotide bases (A, C, G, T) as characters in a string, researchers use edit distance to identify mutations. Substitutions represent point mutations, whilst insertions and deletions (indels) account for bases added or lost during replication. Identifying the minimum number of edits allows scientists to determine the evolutionary distance between species or locate specific genetic disorders. Surprisingly, though, we aren’t using it to map the human genome, we just want to make sure the search bar works when someone forgets how to spell “plumber.”
In a search context, the Levenshtein distance is typically used alongside a predefined threshold. For example, a maximum edit distance of 2 is often sufficient to catch common typing errors without introducing excessive noise into the results.
Using this algorithm provides a more robust search interface that accounts for human error and improves result discoverability.
]]>TDD is a software development process that relies on the repetition of a very short development cycle. First, the developer writes an initially failing automated test case that defines a desired improvement or new function. Then, they produce the minimum amount of code to pass that test, and finally, they refactor the new code to acceptable standards.
This approach was largely pioneered by Kent Beck in the late 1990s as part of the Extreme Programming (XP) movement. Over the last two decades, it developed into a massive industry standard. It promised us a world of self-documenting code, fewer regressions, and modular design. Yet, if we are being honest, the industry has largely treated TDD as an academic ideal rather than a daily reality. The shift in mindsets toward velocity often means the feedback loop we crave is the first thing to be sacrificed.
In my own experience, TDD has been successful but limited in its application. I found myself only reaching for it when dealing with logic-heavy requirements. In those specific scenarios, the feedback loop was tight and the confidence it provided was unmatched.
But for everything else, such as simple CRUD operations or basic API integrations, TDD often felt like a tax. The mental overhead of writing the grunt work tests before the implementation led to a mindset where testing became an afterthought. We often did it at the end of a sprint to satisfy a coverage metric rather than to actually drive the design of the code.
The rise of AI in our IDEs has changed this equation. We have moved past simple autocomplete. We are now in a position where we can use AI as a partner in crime to facilitate a true TDD workflow.
The biggest barrier to TDD has always been the cognitive load of the blank page. Writing the initial test suite requires a level of energy that many find draining. Now, we can ask our AI partner to build the testing suite based directly on the requirement, analyze the scope, and prompt for the best approach.
This is not about letting the tool write the code for us. It is about letting it frame the problem so we can focus on the solution.
No. Before we get too ahead of ourselves, it is important to acknowledge that AI misses the mark, a lot.
While it can be incredibly helpful, it sometimes misses the core business logic. Conversely, it can over-test for perfection, generating a suite that is far too verbose or focused on irrelevant details like simple property mappings. It creates noise where we need clarity.
As experts in our field, we are ultimately responsible for the standardisation and readability of our solutions. This includes the test suites. We cannot simply outsource our judgment. I have found it still needs significant hand-holding to ensure the tests align with the specific standards we want to maintain as a team.
The grunt work, including the setup, the mocks, and the repetitive assertions, was previously what we left until the very last minute. By using AI to handle this heavy lifting at the start of the cycle, we can finally return to a true Test First mentality.
When the boilerplate is generated in seconds, the excuse for not doing TDD evaporates. We can spend our mental energy on the architecture and the logic while the AI handles the initial scaffolding.
We are seeing a fundamental shift. AI has given us the ability to close the feedback loop faster than ever before. It handles the friction so we can focus on the craft. If you have struggled to make TDD stick in the past, the barrier to entry has never been lower. However, the driver is very much still the human.
]]>A high-performing team is rarely defined by technical ability alone. Instead, it is often the rhythm of the team and how they interact with the wider business that determines success. While many organisations focus on the mechanics of a sprint, the most effective teams prioritising the feedback loop that exists at the end of every two-week cycle.
The fortnightly sprint demo should be more than a status update. It is a dedicated, positive forum where the team can demonstrate the tangible value they have delivered. This regular interaction ensures that stakeholders are closely aligned with the work as it evolves, providing a platform for constructive dialogue.
By sharing progress every two weeks, the team creates a consistent drumbeat of delivery. This frequent engagement builds a level of trust that is difficult to achieve through reports or emails alone. It allows stakeholders to see the craftsmanship behind the features and understand the complexities the team is navigating.
Demonstrating work to a live audience has a profound effect on a team’s internal culture. Software engineering can often feel abstract, but presenting a functional feature to the person who requested it provides immediate validation.
When a team sees their work being appreciated and understands how it solves a specific problem, it fosters a sense of ownership and pride. This direct connection to the business outcome is a significant driver of engagement. Statistics from Gallup suggest that teams receiving regular, meaningful feedback see a substantial increase in productivity and a reduction in turnover, as members feel their contributions are recognisable and valued.
The feedback loop is only successful if it is actually closed. Gathering input during a demo is the first step, but the second step is demonstrating how that input has been processed.
Closing the loop involves a clear follow-up. If a stakeholder provides a suggestion, the team needs to communicate how that fits into the roadmap. Even if a request cannot be prioritised immediately, acknowledging it and explaining the reasoning prevents the stakeholder from feeling ignored. This transparency ensures the relationship remains a partnership rather than a transactional request-and-delivery model.
The benefits of this approach are visible in the team’s output. According to data from the Project Management Institute, poor communication is a leading cause of project failure. By enforcing a strict fortnightly feedback cycle, teams significantly reduce the risk of misalignment.
Regular feedback loops are the foundation of a healthy, high-performing team. By utilising the fortnightly sprint to create a positive environment for demonstration and feedback, you ensure that the team is not just building software, but building the right solution for the business. When you close the loop effectively, you build the trust and morale necessary for long-term project success.
]]>It is no longer just a tool for the “tech-obsessed” or people trying to hide sketchy activity. In 2026, a VPN is a fundamental layer of digital hygiene.
At its core, a VPN creates a secure, encrypted “tunnel” between your device and the internet. When you connect to a VPN, your data is scrambled before it even leaves your hardware.
Instead of your traffic going straight to a website, it goes to a VPN server first. This server masks your real IP address and replaces it with its own. To the outside world, you aren’t browsing from your home in London; you’re browsing from a data center in Switzerland or New York.
VPNs didn’t start as privacy tools for the public. They were born at Microsoft in 1996 when Gurdeep Singh-Pall developed the Point-to-Point Tunneling Protocol (PPTP). For over a decade, VPNs were strictly corporate. They were the clunky, slow tools you used to access your office files while working from home.
The shift to the mainstream happened around 2013. The Edward Snowden leaks acted as a massive wake-up call, showing the public exactly how much government surveillance and ISP data harvesting was actually happening.
In recent years, we’ve seen another massive spike. As governments worldwide increase internet restrictions and censorship, and as ISPs began selling user browsing history to advertisers, the VPN moved from a “nice-to-have” to a “must-have.”
I cannot stress this enough: Never use a free VPN.
Running a global network of high-speed servers is incredibly expensive. If a company isn’t charging you a subscription fee, they have to make money elsewhere. In the world of free VPNs, you and your data are the profit. These “services” often log every site you visit, every app you use, and every bit of your metadata, only to sell it to the highest bidder. Using a free VPN is often less private than using no VPN at all.
If a VPN is a secure “tunnel” through the internet, how exactly is that tunnel dug? For the tech-curious, “tunnelling” is the most critical part of the process. It’s the mechanism that allows private data to travel across a public network without being intercepted or understood by anyone in between.
In standard networking, your data is sent in “packets.” Each packet has a header (like an address on an envelope) and a payload (the letter inside). Normally, your ISP reads that header and sends the packet to its destination.
Tunnelling changes this by using a process called Encapsulation.
Instead of sending your data packet out into the open, the VPN takes your entire packet—header and all—and stuffs it inside another packet. This new outer packet has a new header that only points to the VPN server.
To any observer (like your ISP or a hacker on public Wi-Fi), the original “inner” packet is invisible. All they see is a stream of data going from your device to a single IP address: the VPN server.
A tunnel isn’t just about hiding data; it has to be fast and unbreakable. To achieve this, it relies on three specific steps:
As mentioned, this is the “envelope inside an envelope” trick. It allows non-routable or private protocols to be carried over the public internet.
Encapsulation hides the destination, but Encryption hides the content. Even if someone “breaks” the outer envelope, they find the inner envelope is written in a code that would take a supercomputer billions of years to crack. Most modern tunnels use AES-256 or ChaCha20.
Before the tunnel is established, your device and the VPN server perform a “handshake.” This ensures that both sides are who they say they are. This prevents “Man-in-the-Middle” attacks where a hacker tries to pretend to be your VPN provider to steal your data.
Without a tunnel, your digital life is an open book. Every site you visit, every unencrypted form you fill out, and every “ping” your apps send is logged by your ISP and likely sold to data brokers.
By forcing all your traffic through an encrypted tunnel, you reclaim the “Right to be Forgotten.” You aren’t just hiding a single search; you are creating a permanent barrier between your identity and the companies that want to commodify it.
The “protocol” is the set of rules that determines how the tunnel is built. Not all tunnels are created equal.
OpenVPN has been around forever. It’s highly configurable and can “disguise” its traffic to look like standard web traffic (HTTPS), which is great for bypassing strict government firewalls that try to block VPNs specifically. However, it’s “heavy” and can be slower on mobile devices.
If you’ve ever noticed your VPN stays connected even when you switch from Wi-Fi to 4G/5G, you’re likely using IKEv2. It’s excellent at re-establishing a tunnel quickly if the connection drops, making it the go-to for smartphones.
For years, the tech world relied on OpenVPN. It was solid, but it was a beast - hundreds of thousands of lines of code, slow to connect, and a nightmare to audit for security holes.
Then came WireGuard.
WireGuard is roughly 4,000 lines of code. In the software world, less code means a smaller “attack surface.” There are fewer places for bugs to hide and fewer ways for hackers to break in.
By default, a VPN sends all your traffic through the encrypted tunnel. This is great for privacy but can be a headache for performance. This is where Split Tunnelling comes in.
Think of it as a digital fork in the road. You can choose which apps go through the secure VPN and which ones use your regular, high-speed home internet.
In 2026, most top-tier VPN providers (the ones worth that £50 a year) have integrated WireGuard and Split Tunnelling as standard features.
WireGuard handles the heavy-duty security with minimal overhead, while Split Tunnelling ensures you aren’t sacrificing your gigabit fiber speeds just to stay private. It’s no longer a choice between being “safe” or being “fast”—you can finally have both.
If the standard VPN is a tunnel for your personal privacy, the Remote Access VPN is a secure bridge back to the mothership. In 2026, where “the office” is often a kitchen table or a seat in a crowded airport, understanding how you’re connecting to your company’s internal servers is vital.
It’s the difference between having full, secure access to your work files and accidentally leaving the digital back door open for anyone on the same Wi-Fi network.
Unlike the personal VPNs we use for Netflix or privacy, a Remote Access VPN is designed specifically to connect an individual user to a private corporate network.
When you fire up your work VPN, your device (the Client) initiates a connection with a Network Access Server (NAS) or a gateway sitting at your company’s data center. Once you authenticate—usually with a password and a mandatory MFA (Multi-Factor Authentication) prompt—an encrypted tunnel is established.
At that point, your laptop behaves as if it’s physically plugged into the office wall. You get a local corporate IP address, and you can access internal tools, printers, and databases that aren’t available on the public internet.
You might wonder why we can’t just log into work sites like we log into Facebook. The reason is Network Exposure.
Most internal company tools aren’t built to be “public-facing.” They often have vulnerabilities that hackers can exploit if they’re visible to the open web. A Remote Access VPN hides these tools behind a wall. The only way to even see the login page for the company’s internal database is to be inside the VPN tunnel first.
It’s easy to get these confused, but the distinction is simple:
We are currently seeing a massive transition in how remote access works. Traditional VPNs have one major flaw: once you’re in the tunnel, you often have “lateral” access to the whole network. If a hacker steals your VPN keys, they can jump from your account to the HR files to the finance server.
This is why many companies are moving toward Zero Trust Network Access (ZTNA).
In a Zero Trust setup, there is no “broad tunnel.” Instead of connecting you to the network, it connects you to specific applications. Every time you try to open a file or a tool, the system re-verifies your identity and device health. It’s more restrictive, but it prevents one compromised laptop from taking down the whole company.
Beyond security, the Remote Access VPN has a massive psychological benefit for the modern hybrid worker.
Many people now use their VPN as a work-life boundary. When the VPN is on, you’re “at the office.” When you disconnect at 5:00 PM, you’ve effectively “left the building.” It’s a digital ritual that helps prevent the burnout of being “always on.”
A high-quality, audited “no-logs”, utilising WireGuard VPN is one of the best investments you can make for your digital life.
Whether you want to stay truly incognito, stop your information from being sold to advertising giants, or just want to ensure your ISP isn’t throttling your streaming speeds, a VPN should be your default way of browsing. It’s a small price to pay for reclaiming your privacy in an era where everything is up for sale.
]]>That’s where the Adapter pattern earns its keep.
The Adapter pattern provides a translator between two incompatible interfaces, allowing your application to speak in its preferred vocabulary while another system continues doing things its own way. Rather than forcing your core codebase to bend around an awkward dependency, the Adapter absorbs the mismatch.
Real systems are rarely consistent. Different platforms evolve separately, teams have different design philosophies, and vendors make decisions you cannot undo. Adapters let you:
At its core, an Adapter is a small piece of code that:
It doesn’t add business logic. It doesn’t orchestrate workflows. It simply converts intent from one shape to another.
Think of it as an interpreter and not a decision‑maker.
Although powerful, an Adapter isn’t always the right tool. Avoid it when:
Adapters should stay boring and predictable.
Adapters help you defend the shape of your system. They ensure that:
It’s a small pattern with a big architectural impact.
Clean design isn’t about eliminating every legacy system in sight, it’s about preventing yesterday’s decisions from dictating tomorrow’s architecture. The Adapter pattern helps you draw that line. Build the interfaces you want, then write adapters that translate them to whatever the outside world requires. Your domain stays consistent, your integrations stay manageable and your code becomes more manageable.
]]>