Yetric Blog

VM 2026 Tipset: Predict the World Cup with Friends

2026-05-20T00:00:00Z

TL;DR

We've launched VM 2026 Tipset on Fotbollsfeber.se — a free fantasy football game for the 2026 World Cup. Predict all 104 matches, create a private pool, and compete against friends on a shared leaderboard.

What It Is

The 2026 World Cup runs June 11 through July 19, across 48 teams and 16 host cities in the US, Canada, and Mexico. It's the biggest tournament in the history of the competition, and we wanted to give football fans a reason to be invested in every match — not just the ones their own country is playing.

VM 2026 Tipset is built around a simple idea: before the tournament starts, you predict the score of every group stage match. Once the knockout stage is drawn, you fill in the bracket. Points accumulate across all 104 matches, and you compete against everyone in your pool.

How It Works

Group stage: Predict the score of all 72 group stage matches before the opening match on June 11. You earn points for each correct component — right outcome (3p), right home goals (2p), right away goals (2p). Max 7 points for an exact result.

Knockout bracket: Once the groups are decided (around June 27), you fill in the full bracket. The further a team goes, the more your pick is worth — from 2 points in the round of 32 up to 32 points for calling the champion.

Special predictions: Eight tournament-level picks — top scorer, most clean sheets, which host nation goes furthest, whether the final goes to penalties, and more. Worth 10–15 points each.

Private pools: Create a pool, share the link or 6-digit code, and your friends join. You can be in multiple pools — one with workmates, one with your football club — each with their own leaderboard and their own set of predictions.

Try It

The group stage locks when the opening match kicks off on June 11. That gives you just under three weeks to get your predictions in.

Start your pool at fotbollsfeber.se/vm-2026 — it's free, and you don't need to already be a Fotbollsfeber user.

Sometimes You Need a Focused UX Push

2026-05-06T00:00:00Z

Over the last few days we made a focused UX push on Fotbollsfeber.

Not a redesign. Not a rebrand. Not a "let's rethink everything" exercise.

Just a short, deliberate pass over the parts of the product where the experience had started to lag behind the capability of the system.

That distinction matters.

Products Accumulate Friction

Most useful products get rough before they get polished.

You add a prediction model. Then a match center. Then filters. Then favorite teams. Then a watchlist. Then league pages, match pages, simulation views, standings, form indicators, and small bits of editorial context.

Each individual change can be reasonable. The problem is the sum.

After a while, the product has more power than clarity. The data is there, but the hierarchy is uneven. Important controls are technically present, but not always where people expect them. Mobile layouts work, but only if you are forgiving. Dense analytical screens contain the right information, but they require too much effort to scan.

None of this is catastrophic. That is why it is easy to ignore.

It is also exactly why it needs attention.

Why a Focused Push Works

UX debt is hard to fix opportunistically.

If you only improve usability while working on unrelated features, you tend to fix the visible irritation in front of you and leave the system-level pattern untouched. One page gets better. Another page keeps the old spacing. One component gets clearer labels. Another still uses a different visual language.

A focused push lets you stay inside one problem space long enough to see the repetition.

For Fotbollsfeber, that meant spending a few days on the same family of issues:

personalization should feel native, not bolted on
dense football data should remain scannable
analytical surfaces should share a consistent visual rhythm
mobile layouts should be designed for the actual viewport, not merely squeezed into it

The point was not any single pull request. The point was momentum around one concern: make the product easier to understand and use without making it less capable.

Focus Creates Better Taste

There is a practical benefit to doing this work in a cluster: your judgment improves as you go.

The first fix reveals the second. The second makes an inconsistency obvious somewhere else. A component that felt fine in isolation suddenly looks awkward next to the newer pattern. A mobile layout that technically passed becomes clearly too compressed once nearby screens improve.

This is not scope creep if the frame is clear.

It is the work becoming legible.

Focused pushes are useful because they give a team permission to follow those connections for a bounded period of time. You are not opening the door to infinite polish. You are saying: for the next few days, this specific quality dimension matters more than the backlog's usual ordering.

That can be necessary.

The Risk of Always Shipping Features

Feature work is easier to justify than product quality work because it is easier to name.

"Add a watchlist" sounds concrete.

"Make the match center feel calmer, denser, and more predictable" sounds softer, even when it has more impact on daily use.

But products are not judged only by the features they contain. They are judged by how confidently people can move through them. A feature that exists but hides behind unclear hierarchy, cramped layouts, or inconsistent interaction patterns is not really finished.

This is especially true for data-heavy products.

The value is often in comparison: teams, matches, form, probabilities, standings, trends. If the interface makes comparison tiring, the product is wasting its own data.

A Push Is Not a Permanent Mode

The key is that this kind of work needs boundaries.

A focused UX push should have a theme, a short time window, and a clear exit. It should improve the product's foundations, then hand attention back to the broader roadmap.

Without boundaries, polish becomes avoidance.

With boundaries, it becomes maintenance of product trust.

For Fotbollsfeber, this push was about tightening the experience around the work already done: making personalization more visible, making dense views more usable, improving hierarchy, and reducing small bits of friction that get in the way of understanding the football.

The product did not become something else.

It became more itself.

The Broader Lesson

Most teams should occasionally ask: what class of problem have we been stepping around?

Not which ticket is next. Not which feature is most exciting. Which kind of problem keeps showing up in different forms?

Maybe it is onboarding. Maybe it is performance. Maybe it is copy. Maybe it is accessibility. Maybe it is the fact that every settings screen behaves slightly differently.

When the same issue appears across the product, fixing one instance at a time is usually too slow. You need a short push that treats the pattern as the work.

That is what we did here.

Sometimes progress is not adding a new capability. Sometimes progress is taking the capabilities you already built and making them easier to trust.

Cartridge Engine: Three Demos Later

2026-04-28T00:00:00Z

A few weeks ago I wrote about Cartridge Engine — a 2D game engine designed like a retro console, with fixed hardware specs and no escape hatches. The pitch was: constraints are features, determinism matters more than flexibility, the game declares its hardware and the engine enforces it.

That post was written at a fairly early stage. The engine ran. A demo cartridge existed. The architecture was sound. But the three games I listed as the real test — a Zelda-like, a platformer, a match-3 — weren't playable yet.

They are now. Here's what I learned building them.

What shipped

Three cartridges are running in-engine, each a different genre:

Adventure — a top-down game with rooms, a combat loop, enemies with distinct AI behaviors, dialogue, interactive objects, an inventory, and a win condition. It uses the most engine features of the three.

Platformer — a side-scroller with gravity, tile-based collision, a level-end goal, parallax backgrounds, per-level music, and a death/respawn flow. The engine's tile collision system was designed for top-down; making it work for a platformer revealed some interesting edge cases.

Puzzle — a match-3 with a board rendered from the dungeon tileset, gem swap animations, match flash feedback, a score target win condition, a timer, and a no-moves-left shuffle. This one was the most useful for stress-testing the animation and tween systems.

All three have a title screen, a game-over screen, and return to the in-engine cartridge selector when they end. Consistent HUD style across all three.

What the engine needed to make this work

Phase 1 laid the foundations — animation state machine, deterministic RNG, timers and tweens, save/load, cartridge self-registration. But building actual games exposed what was missing beyond that.

The biggest additions, in rough order of difficulty:

Dialogue and interaction zones. A first-person trigger zone system with action and enter semantics. A typewriter text box renderer that pauses the cartridge tick while open. Branching choice prompts with d-pad navigation. A .dlg script format compiled to typed constants via codegen, so cartridge code references IDs rather than raw strings.

Getting the "pause tick while dialogue is open" behavior right was trickier than expected. The engine owns the loop — it decides whether to call tick() this frame. The cartridge has no say. That's correct design, but it means the engine needs to know when dialogue is active, which creates a small coupling. The solution was a simple isBlocking() flag on the dialogue system that the runtime loop checks before calling tick().

Combat primitives. Separate hitbox and hurtbox per entity. Invincibility frames (i-frames) counted in ticks, not milliseconds — this matters for determinism. A onHit(attacker, victim, damage) hook the cartridge wires up. Floating damage numbers via a pooled HUD layer.

Enemy AI. A small finite state machine library: patrol, chase, flee, attack. Declarative wiring — the cartridge specifies what the AI should do, not how. Pathfinding on the collision grid via A*, with a bounded step count per tick so the CPU budget stays fixed.

Inventory. Fixed-size slots declared in the manifest. add, remove, has, count, equip. Stackable vs unique items declared on the item definition. No runtime surprises — overflow policy is explicit (reject, not silent drop).

Cutscenes and camera. A tick-based sequencer that chains entity moves, dialogue, SFX, and waits. It pauses player input automatically and restores on finish. Camera now supports lerp-to-target, directional lookahead, and bounds clamping to map edges.

Screen effects and particles. Flash, fade-to-color, screen shake with fixed amplitude presets. A particle emitter with pooled instances and built-in presets (dust, spark, smoke). These live in the engine's rendering pipeline, not in cartridge code.

Things the constraints got right

I said in the original post that constraints force decisions earlier. That turned out to be more important than I expected.

The inventory: { slots: 16 } line in the manifest is a good example. It forces you to decide, before writing any inventory code, how many item slots the game has. And it forces the engine to enforce it — full is full. That sounds minor but it means the question "what happens when the inventory is full?" always has a crisp answer. The cartridge either handles it or the engine rejects the add. There's no third option where you quietly have 17 items.

Item definitions follow the same pattern. Items are typed constants generated from the manifest. The cartridge cannot reference an item that isn't declared. This caught several mistakes during development where I would reference an item ID that I hadn't wired up yet. Compile-time error, not a runtime null.

Enemy AI being declarative also worked out. The chase and patrol states are implemented once in the engine. The cartridge says which state the enemy starts in and what triggers transitions. The adventure cartridge has two distinct enemy behaviors — they're distinct not because I wrote different code but because the transition tables are different. One chases on sight and attacks on contact. One patrols until attacked, then chases. That differentiation is just data.

Things the constraints got wrong

The tile-based collision worked perfectly for the top-down game. It worked less perfectly for the platformer.

The issue isn't the model — a flat tile array is still the right call. The issue is that platformer physics have some expectations about collision resolution that don't come for free. Specifically: when you're moving horizontally and hit a wall, you should stop moving horizontally without being pushed down. When you're falling and land on a tile, you should land cleanly on top of it, not clip into it slightly.

The separated X/Y movement system handles this, but it required a few non-obvious corner case fixes when the player is in the corner of two tiles simultaneously. The adventure cartridge never exposed these because top-down movement doesn't have gravity and the player is rarely moving in two axes at full speed simultaneously.

The lesson isn't that the collision model was wrong. It's that the constraint — tile-based collision only — is right for both genres, but the engine code needed to be a bit smarter about resolution order to be actually correct in both.

The other tension is in audio. Eight channels, four music and four SFX. That's fine for one game. It's fine for three games. But writing a match-3 that has distinct sounds for each gem type under a four-SFX budget forced some creative decisions — you can have distinct sounds per gem type or distinct sounds per combo size, but not both. That's probably the right tradeoff for a constraint-first engine, but it's worth calling out: the constraint is real and it shapes what games are possible.

The tooling turned out to matter

I underestimated how much time I'd spend in the tools, not the engine.

A sprite sheet editor. A palette editor (256 entries, palette-indexed). A tilemap editor with multi-layer editing, per-layer parallax scroll factors, and a collision-layer painter. An animation editor for wiring up the state machine visually. A dialogue editor with a graph view for branching. A chiptune/SFX tool over the synth parameters. A font browser for the four shipped fonts.

None of these are sophisticated tools. They're all just good enough to make actual content. But "just good enough" is a real bar. The alternative is hand-editing JSON and pixel arrays, which is slow and error-prone.

The CLI also shipped: cart init, cart validate, cart codegen, cart inspect, cart build, cart watch, cart package. The inspect output in particular is useful:

ROM:   18 MB / 64 MB
VRAM:   3 MB / 8 MB
RAM:   10 MB / 32 MB
Sprites: 96 / 128

Seeing the hardware budget at a glance keeps the constraints visible. It's easy to forget you're on "fixed hardware" when you're just writing TypeScript. The inspect output makes it concrete.

What's next

A few things remain unbuilt that I want to finish:

Composite sprites. Multi-part characters where each part is an independent sprite slot but they move together as a unit. This is needed for larger characters and character customization. The engine currently has no concept of a sprite group — each sprite is independently positioned.

Capability validation. Static analysis of cartridge code against the manifest-declared capabilities. If you call inventory.add(...) but your manifest doesn't declare an inventory, the build should fail. Right now this is an honor system — the API just returns undefined for undeclared capabilities. I want the build to catch it.

Playtest recorder. Record { tick, inputs } during play, replay deterministically. This is the real test of the determinism contract. Same seed plus same input sequence should always produce the same game state. If it doesn't, something is wrong.

The three demos proved the architecture holds. The constraint-first model produced three very different games that all run in the same engine without any of them needing engine modifications or workarounds. The expansion system isn't built yet — that's how the engine is supposed to handle capabilities beyond the base console — but I haven't needed it for any of the three demos.

That's probably the most honest validation: I built three games that required dialogue, combat, pathfinding, inventory, cutscenes, and particle effects, and none of them needed a plugin, a config option, or an escape hatch. They just used the API.

Cartridge Engine: What I'm Learning by Building a Game Engine Like a Console

2026-04-01T00:00:00Z

Why build a game engine?

Not to use it. Not to compete with Unity or Godot. The honest answer is that I wanted to understand what happens when you design a system around constraints rather than flexibility — and building a game engine seemed like the most direct way to explore that.

I've used modern engines and frameworks enough to know that they're optimized for capability. You can do almost anything. That's useful, but it also means you spend a lot of time just making decisions. And the more configurable a system is, the harder it is to reason about what it's actually doing at any moment.

The question I kept coming back to: what if that wasn't the goal?

The console metaphor

SNES and Mega Drive developers didn't have a flexible engine. They had hardware. Fixed resolution. Fixed tile size. A specific number of sprites. Defined audio channels. Those weren't limitations they worked around — they were the shape of the problem. And games from that era are often easier to understand at a systems level than modern ones precisely because the constraints were visible and shared.

So I started building something I'm calling Cartridge Engine. The framing is:

The engine is the console — it defines what's possible
The game is a cartridge — it runs inside the console and can't escape it
New capabilities come from hardware expansions — not plugins, not configuration

The hardware spec is fixed: 320×180, 16×16 tiles, 128 sprites, 4 tile layers, 8 audio channels, 60Hz. These numbers are arbitrary enough to be honest — I picked them to be plausible, not to be optimal.

The principles I wrote down at the start, and have mostly stuck to:

Constraints are features
Determinism over flexibility
One way to do things
No hidden behavior
Capabilities must be declared
No runtime magic

What I've learned so far

Building this has been more educational than I expected, and in unexpected ways.

Constraints force decisions earlier. When you decide up front that collision is tile-based — 0 or 1 per 16px cell, no partial tiles — you stop having a whole category of design debates. You also discover which parts of your map don't actually align to the grid, and you fix them. The system is dumber but the result is cleaner.

We actually had a pixel-rect collision system first. It worked, but it was floppy — arbitrary rectangles, a visual editor to tune them, lots of per-map exceptions. Replacing it with a flat tile array was a step backward in expressiveness and a step forward in everything else. Simpler to implement, simpler to reason about, simpler to debug. I think that trade is usually worth it and I don't always remember that.

The cartridge boundary is surprisingly useful. Writing the game as a function that receives a fixed API — input, video, audio, system — and nothing else forces you to be explicit about what the game actually needs from the engine. It can't reach into engine internals. It can't do anything that isn't in the API contract. That sounds restrictive but it mostly feels like clarity.

Audio is harder than it looks. Not the Web Audio API itself — that's fine — but figuring out where audio lives architecturally. It needs to be pre-decoded (no runtime parsing), channel-limited (8 channels, enforced), and ID-based (no file paths at runtime). Getting that right took longer than expected, partly because the temptation to just expose AudioContext directly to the cartridge is strong and wrong.

The "one small game" constraint is doing real work. The current demo is a cabin on a hill with an interior you can enter. It's not a game. But building it has already surfaced things I wouldn't have found just designing the engine in the abstract — collision edge cases, sprite z-ordering across layers, scene transition timing, how footstep sounds should relate to the walk cycle. The game is load-bearing.

What's running today

To make this concrete: here's what the engine does right now.

A fixed 60Hz game loop. A 4-layer tilemap renderer with 128 sprites and per-sprite z-ordering. A 12-button input system mapped from keyboard. Tile-based collision. An 8-channel audio system with separate music and SFX channels. Scene transitions with music swapping. A demo cartridge with a hero character who walks around a 16-bit style cabin exterior, enters through the door, and explores the interior.

The cartridge code for the game entry point looks like this:

export default createCartridge(({ input, video, audio }) => {
    return {
        boot() {
            /* set up scene */
        },
        tick() {
            /* read input, move player, check triggers */
        },
        draw() {
            /* push sprite positions to video */
        },
    };
});

That's it. No engine internals leaking through.

What's next

The next things on the list are codegen (generating typed asset bindings from a manifest so the cartridge has compile-time safety on asset IDs), a CLI, and inspect tooling that shows ROM/VRAM/RAM usage against the hardware budget.

The longer goal is three playable demos — each one using the full feature set of the engine:

A top-down Zelda-like: rooms, combat, NPCs, inventory
A side-scrolling Mario 3-like: gravity, platforms, enemies, power-ups
An old-school match-3: grid logic, cascades, score, progression

These three were chosen deliberately. They cover very different engine requirements — different collision models, different camera behaviour, different game loops — so together they'll prove whether the engine is actually general or just a cabin demo with ambitions. If all three are playable within the constraints, the constraints were right.

I don't have a finish line beyond that. I'll write more as it develops.

Building tools.yetric.net: 85+ Developer Tools With No Friction

2026-03-27T00:00:00Z

The Itch

Every developer has been there: you need to quickly decode a JWT, format some JSON, or generate a hash — and instead of just doing it, you end up navigating past cookie consent banners, signing up for an account, or waiting for ads to load before the tool even renders.

It's a solved problem made annoying.

tools.yetric.net is my answer to that. Free, no accounts, no ads, no friction. Paste input, get output, copy and go.

What It Is

The site is a collection of over 85 web-based utilities organized into categories:

JSON — formatting, diffing, converting to TypeScript/Go/Zod schemas, generating SQL inserts, Prisma models, and more
Auth & Security — JWT decoder, JWT builder, hash generator, bcrypt, API key generator, HMAC signer
Security — CSP builder, CORS policy builder, password strength analyzer, security headers checker
Dev Utilities — curl → code, cron parser, regex tester, .env validator, Dockerfile generator, Nginx config builder, OpenAPI → TypeScript, HTTP status reference, and many more
CSS & Frontend — px/rem/em converter, CSS specificity calculator, Tailwind → CSS, z-index manager, gradient builder
SaaS & Metrics — MRR/ARR calculator, churn impact simulator, CAC/LTV, pricing tier designer
Docs — changelog generator, README builder, conventional commit linter, semver bump calculator

The philosophy is simple: every tool should be immediately usable with no setup, and every tool should do one thing clearly.

The Architecture

The stack is straightforward and intentionally boring.

Frontend: Next.js + TypeScript + Mantine

Next.js 16 with the App Router handles routing and server-side metadata generation. Mantine provides the component layer — it handles forms, code highlighting, and dark mode without requiring me to rebuild UI primitives from scratch. The entire frontend is TypeScript with strict mode enabled.

Each tool follows a consistent pattern:

A page component that sets SEO metadata
A tool component that wraps a shared <ToolPage> template with tool-specific config (title, description, input/output labels, syntax highlighting language)
A typed API wrapper that posts to the backend and handles the { output, error } response

This means adding a new tool is low-overhead: write the backend logic, add a handler, add a typed API call, drop a <ToolPage> wrapper around it. The scaffolding is already there.

Backend: Go

The API is a Go service using the Chi router. Each tool gets its own handler and internal logic package. Go was the obvious choice here — it's fast, the standard library handles most of what's needed, and the tooling is straightforward.

The API enforces rate limiting (120 requests/minute per IP), a 1 MB body size cap, and returns a consistent { output: string, error?: string } shape from every endpoint. No surprises.

Deployment: Podman + Nginx

Both services run as containers behind an Nginx reverse proxy. We use Podman rather than Docker — it's fully open source, daemonless, and runs rootless by default, which aligns well with how we prefer to run things. GitHub Actions builds and pushes images to GHCR on every push to main, then pulls and restarts on the server via Podman Compose. Smoke tests run as part of the pipeline to catch obvious regressions.

flowchart TD
    subgraph CI["CI/CD (GitHub Actions)"]
        direction LR
        Push["git push"] --> Build["Build images"] --> GHCR["GHCR"]
    end

    subgraph Server["Production Server"]
        direction LR
        Nginx["Nginx\n(TLS + proxy)"] --> FE["Next.js\nFrontend"]
        FE -->|"POST /api/v1/..."| API["Go API"]
        API --> Tools["Tool Logic\n(Go packages)"]
    end

    Browser([Browser]) --> Nginx
    GHCR -->|"Podman Compose\npull & restart"| Server

A Few Decisions Worth Noting

URL-based input sharing. Any tool input can be encoded into the URL as a base64 query parameter. The page decodes it and auto-submits on load. This means you can share a link and the recipient lands directly on the result. It's a small feature that turns these tools from local scratch pads into something you can actually hand to a colleague.

CMD+K search. With 85+ tools, navigation needs to scale. There's a spotlight-style search overlay (CMD+K or /) that searches across all tool names and descriptions. It's faster than scrolling a sidebar.

Favorites and recents. Tools you've used recently appear at the top of the sidebar. Tools you've starred are always accessible. Both are stored in localStorage — no accounts needed.

Dark mode with Nord. The color scheme is Nord throughout — the Aurora palette for category accents, Frost for UI chrome. It's opinionated, but it holds together well and looks good at night when you're decoding a JWT at 11pm.

What I Learned

The boring architecture wins. Next.js + Go + Docker is not a novel combination. That's the point. Every piece of it has known tradeoffs, good documentation, and no surprises. When you're building a tool that needs to just work, boring infrastructure is a feature.

Consistency beats cleverness. The <ToolPage> pattern means every tool works the same way. Users don't need to re-learn the interface for each tool. It also means I can add new tools quickly without thinking too hard about UI structure.

The search overlay is more important than the navigation. Once you have 30+ tools, the sidebar becomes hard to scan. The spotlight search is what most people use after the first visit. Building it earlier would have been worth it.

What's Next

The tool count keeps growing. There are several more DevOps and database utilities in progress. I'm also looking at adding a way to chain tools together — pipe the output of one into the input of another — which would unlock some useful workflows.

There's also something that keeps coming up: a CLI. The backend is already a clean API — every tool is a single POST with a plain text response. Wrapping that in a terminal client would let you pipe directly from your shell: cat schema.json | yetric json:to-typescript. No browser required. That one is on the list.

If you use it and find something missing or broken, the site links to GitHub for issues.

tools.yetric.net — no signup required.

Fotbollsfeber: More Than a Football Stats Site

2026-03-08T00:00:00Z

TL;DR

Over the past few months, Fotbollsfeber.se has grown from a fairly standard Swedish football stats site into something more interesting: a data platform that tracks leagues, models match outcomes, and helps people think more clearly about football predictions. Here's what we've been building.

It Started as a Stats Site

Fotbollsfeber has been tracking Swedish football for years — Allsvenskan, Superettan, Damallsvenskan — logging matches, goals, and table standings. Useful, but not particularly exciting.

The interesting part is what happens when you start treating that historical data as raw material rather than an endpoint.

A Probability Engine for Stryktipset

The biggest thing we've shipped this spring is a prediction model for Stryktipset — the Swedish football coupon that's been around since 1934.

Every week, 13 matches. Three outcomes per match: home win, draw, away win. You pick. If you get all 13 right, you win. Simple on the surface. Genuinely difficult in practice.

We built a probability engine that models each fixture using a chain of approaches — ELO ratings, goal scoring rates, historical head-to-head form, opening odds from bookmakers, and crowd consensus. No single model works perfectly, so the system prioritizes by reliability and falls back gracefully when data is thin.

The output isn't just "pick 1, X, or 2." It's a full probability breakdown per fixture, expected value calculations, and — when we run backtests against historical rounds — a measurable improvement over naive guessing.

The system runs weekly, aligned to each new Stryktipset round.

What makes this interesting isn't just the predictions. It's that the whole thing is grounded in real historical data from the site itself, updated continuously as new matches are played.

One Site, Every League

The other major project was less glamorous but arguably more important: we rebuilt the routing and data layer so every league — Swedish, European, or otherwise — works the same way.

Before this, each league had its own page structure, its own quirks, its own workarounds. Adding a new league meant duplicating code and hunting down which assumptions had been baked in from three years ago.

Now there's a single architecture. You can browse Allsvenskan, Premier League, La Liga, or Damallsvenskan through the same consistent interface. Adding a new league is a configuration change, not a rewrite.

This matters less for users day-to-day and more for everything that comes next: you can now run the same analysis, the same prediction models, the same comparison tools across leagues without reinventing the wheel each time.

One example that's already live: season simulation. Pick any league, hit a button, and the site runs 10,000 simulated versions of the rest of the season — based on current standings, team form, and remaining fixtures — and returns a probability distribution of final positions. Who's realistically in the title race? Who's actually in a relegation battle versus just mathematically still in one? The simulation gives you a data-driven answer rather than a gut feeling.

Because every league now shares the same data model, this works for Allsvenskan and Bundesliga equally. That's exactly what the unified architecture was for.

A Matchcenter Worth Using

We also shipped a proper matchcenter — a live feed of upcoming and recent matches across all tracked leagues, with team logos, live scores, and quick links to match details.

It sounds basic. Most football sites have something like this. The difference is that ours pulls from a single unified data model that covers Swedish football with real depth (squad data, historical statistics, top scorers) and European leagues with solid coverage (Premier League, La Liga, Bundesliga, Serie A, Ligue 1, and more).

The home page now gives you a cross-league view of the football week, with league logos and context, rather than forcing you to navigate to each league separately.

Why This Is Interesting

The underlying idea is that football generates enormous amounts of structured data — scores, lineups, goalscorers, betting odds, newspaper predictions — that mostly sits unused or gets locked behind expensive data providers.

A site with enough historical depth can do something different: treat that data as the input to actual analysis. Not "Allsvenskan table" as a static fact, but "given everything we know about these two teams, what does the data actually suggest about this match?"

The Stryktipset model is the clearest example of this so far. But the same logic applies to team form analysis, squad depth comparisons, and season projections.

What's Next

We're continuing to build out the prediction side. The probability model will get better as more data accumulates, and we're exploring how to present the analysis in ways that are genuinely useful rather than just numerically impressive.

On the data coverage side, more leagues, more historical depth, and better real-time sync.

If you follow Swedish football — or just find the intersection of data and sport interesting — Fotbollsfeber.se is worth a look.

What's New in Maklarinfo: March 2026 Update

2026-03-06T00:00:00Z

TL;DR

We've shipped five meaningful updates to Maklarinfo over the past three months. You can now create an account, search with more powerful filters, get instant alerts when new listings match your saved searches, toggle alerts directly from your dashboard, and explore detailed broker performance data with historical trends.

Create Your Account

One of the most requested features is finally here: user accounts. You can now sign up for Maklarinfo and keep your searches, alerts, and preferences synchronized across devices and sessions.

With an account, your saved searches travel with you—whether you're on your phone, laptop, or tablet. No more losing your criteria when you close the browser.

Smarter Search Filters

Finding the right property means being able to describe exactly what you want. Maklarinfo's improved search now includes expanded filtering options:

Free-text search: Search by street name, neighborhood, or other details without preset categories
Max rent filter: For apartment renters, set your maximum rent ceiling directly
Improved sorting: Sort results by relevance, price, date, or size—with clearer options to match how you naturally think about properties

These might seem like small changes, but they let you be more precise about what you're looking for. No more sifting through listings that don't fit your budget or neighborhood preferences.

Saved Search Alerts

You can now get automatic alerts when new listings match your saved searches.

Create a saved search for your ideal criteria—maybe a 2-room apartment under 3.5M in Södermalm—and we'll send you an email the moment a new listing matches. No more checking Maklarinfo manually multiple times a day.

You're in control of when you get alerts. From your dashboard (Mina Sidor), you can toggle alerts on or off for each saved search individually. Want alerts for one search but not another? Just flip the switch.

Broker Performance Data

We've expanded the National Broker Page with deeper insights into how brokers are performing across Sweden.

New features include:

Trend charts: See how broker activity, price trends, and sales volumes have changed over time
Top cities data: Understand which markets each broker is most active in
Historical comparison: Look back over months to understand patterns and cycles

Whether you're curious about a specific broker or researching the broader market, you now have the data to make informed decisions.

The Experience So Far

These updates are built on feedback from our users. Account creation, better filters, and email alerts are features people have asked for since day one. Broker data makes Maklarinfo useful not just for finding your next home, but for understanding the Swedish property market itself.

Ready to get started? Head over to Maklarinfo and try it out for yourself.

We're committed to making Maklarinfo the tool you reach for when you're serious about property search—whether you're browsing casually or ready to make a move.

Focused Execution: An 8-Week Experiment in Disciplined Product Building

2026-03-03T00:00:00Z

The Problem with Constant Evaluation

Most product teams evaluate too often. You ship something. A week passes. No hockey stick growth. Someone says "maybe we should pivot." A new idea sounds exciting. Focus shifts. Nothing gets finished.

Eight weeks in, you have a dozen half-baked experiments and no clarity on whether anything actually works.

We decided to run an experiment in disciplined execution: 8 weeks of consistent building without evaluation, pivoting, or starting new projects.

The Rules

From March 1st through April 26th, 2026, the following are forbidden:

No new projects
No tech stack changes
No redesigns for aesthetic reasons
No pivoting based on early signals
No existential analysis of product viability

We're treating this as a controlled execution window. Not a lifetime decision. Not a reputation gamble. Just 56 days.

The Weekly Rhythm

Each week follows a structured pattern:

2 × Build Blocks — Infrastructure, backend systems, data pipelines
1 × Product Block — UI improvements, usability fixes, packaging refinements
1 × Visibility Block — Publish one insight or analysis derived from data

We publish something every single week. Not marketing fluff. Actual data insights from what we're building.

What We're Actually Measuring

One metric matters: actual customer adoption and payment.

No vanity metrics. No follower counts. No "this feels promising" vibes.

Either real customers are using the product and paying for it, or they're not. That's the signal we care about.

Why This Approach Works

Consistency compounds. Eight weeks of focused effort on the same problem creates momentum that scattered work never achieves.

You actually learn. When you stop pivoting, you finish things. Finished products reveal their real strengths and weaknesses. Half-baked experiments reveal nothing.

Urgency focuses thinking. A 56-day window forces prioritization. What's truly important? What's just interesting? What can wait?

Evaluation Day

On April 26th, and not before, we apply cold analysis:

Is there inbound interest?
Are there trial users?
Are there paying customers?
Is there a clear signal of usefulness?

Then we decide: Kill it, adjust the approach, or double down.

No emotional framing. Just data.

The Anti-Self-Sabotage Clause

When doubt creeps in—"This is inefficient," "This is boring," "There's something more exciting"—the answer is simple:

Evaluation is on April 26th.

Not today. Not next week. April 26th.

Why You Should Consider This

If your product team is scattered across multiple priorities, constantly re-evaluating based on weak signals, and nothing feels like it's moving forward, an 8-week execution contract might be exactly what you need.

The key insight: data beats vibes, but only if you give yourself time to gather it.

You can't evaluate whether something works after two weeks. You can't validate a business model in a month. But you can absolutely tell the difference between "this is broken" and "this actually has potential" after two months of focused execution.

Takeaways

Focused execution beats scattered effort. Always.
Evaluation is a specific moment, not a constant state. Defer judgment until you have enough data.
One metric is often enough. Vanity metrics beat a dashboard full of noise.
Urgency clarifies priorities. A deadline forces hard choices.
This is an experiment, not an identity. Eight weeks is long enough to learn something real, short enough to fail safely.

The Bottom Line

Execution mode doesn't mean ignoring feedback or being inflexible. It means: commit to a direction, build consistently, gather real data, and defer major decisions until you have enough information to make them well.

Try it. Eight weeks. One metric. No pivots. See what happens.

Behind the Scenes: DevOps Improvements at Maklarinfo

2026-03-01T00:00:00Z

TL;DR

We've made significant investments in our CI/CD pipeline, logging infrastructure, and deployment reliability over the past three months. Pull request checks now run 50% faster through parallelization. We've added structured logging across the entire stack. And we've hardened our build process to be more resilient to edge cases.

Faster Feedback Loops

One of the biggest wins for developer experience is speed. When you push code, you want to know if it passes quality gates in seconds, not minutes.

Parallel CI/CD Jobs

We restructured our pull request quality checks to run in parallel instead of sequentially. What used to take 4+ minutes now completes in about 2 minutes for most changes.

How? By running linting, type checking, tests, and formatting checks concurrently rather than one after another. They don't depend on each other, so there's no reason to serialize them.

We also implemented smart caching of dependencies and build artifacts, so repeat checks skip expensive install and build steps when nothing has changed.

Change Detection

Not all changes require the same level of scrutiny. If a PR only modifies documentation or markdown files, we skip the full build step entirely. This saves time on documentation-only PRs without sacrificing quality on code changes.

Observable Systems

You can't manage what you can't measure. We've invested in structured logging across the entire application stack—from API routes to background workers to third-party integrations.

Structured Logging

Instead of freeform log messages, we now log events with consistent structure: context, severity levels, timestamps, and relevant metadata. This makes it possible to:

Search and filter logs efficiently in production
Correlate events across services
Build alerts on specific patterns
Debug issues faster with more context

Structured logging is invisible to end users, but it's the foundation for reliability. When something goes wrong at 3 AM, better logs mean faster resolution.

Production Observability

We've instrumented critical paths in the application to emit detailed events—from user actions to third-party API calls. This lets us:

Detect anomalies before users notice them
Understand where time is being spent in the system
Validate that background jobs are running as expected
Track data quality in real-time

Resilient Builds

Production systems need to handle edge cases gracefully. We've hardened our build and deployment processes to be more resilient.

Defensive Configuration

The build now handles missing configuration gracefully. If an environment variable isn't set, the build doesn't fail—it either uses a sensible default or continues with a warning. This prevents cascading failures where missing one config value brings down the entire pipeline.

Safer Dependency Management

We've added versioning constraints and fallback logic to ensure that third-party dependencies don't introduce breaking changes silently. Dependency updates are tested more thoroughly before they reach production.

Test Stability

We've fixed flaky tests and improved test infrastructure to reduce false negatives. When a test fails, it means something is actually broken—not that the test framework had a hiccup.

Security-First Infrastructure

DevOps isn't just about speed—it's about doing things securely at scale.

OWASP Compliance

We conducted a comprehensive security audit and addressed all OWASP Top 10 findings. This includes improvements to how we handle authentication, rate limiting, input validation, and more.

Secret Management

We've hardened how secrets (API keys, database credentials) are stored and accessed. Secrets are never logged, never stored in version control, and are rotated regularly.

Rate Limiting & DDoS Protection

We've implemented rate limiting at multiple layers to protect against abuse while ensuring legitimate traffic always gets through.

Looking Forward

These improvements compound over time. Faster CI means developers get feedback sooner and ship features quicker. Better observability means we catch issues before users do. Harder infrastructure means we can scale confidently.

The next phase of work focuses on deployment automation, canary releases, and more sophisticated monitoring. The goal is to make deploying code as boring and reliable as possible—just push to main, everything works, no drama.

Takeaways

Speed matters: 50% faster PR checks keeps developers in flow and lets us iterate faster.
You manage what you measure: Structured logging is a force multiplier for reliability.
Resilience requires discipline: Defensive coding, solid testing, and gradual rollouts prevent most production issues.
Security is a feature: Compliance and hardening aren't obstacles—they're table stakes for trustworthy systems.
Infrastructure compounds: Each small improvement makes the next improvement easier to build.

New Site, New Chapter

2026-02-20T00:00:00Z

The new yetric.com is up.

It's been a while since the old site was actively maintained, and I decided it was time to start fresh — cleaner design, better structure, and a real commitment to writing more regularly.

Yetric is my software development and consulting practice based in Sweden. I work with teams on building products, modernizing systems, and making better decisions around architecture and data. If any of that sounds relevant to what you're working on, the about page has more.

What's coming

This blog is where I'll write about things I run into in real work:

Architecture decisions and how to make them without pretending they're permanent.
Moving away from legacy systems without burning everything down.
Building short feedback loops so mistakes stay small.
The intersection of data, product, and engineering — and how to align them.

More soon, and more regularly than before.

Worth reading from the archive

I've brought over a handful of older posts from the previous site that I think still hold up:

Unraveling Technical Debt: The Silent Software Killer — on the compounding cost of ignoring shortcuts in your codebase.
Navigating Analytics and GDPR Compliance — key considerations for running analytics without running afoul of data protection law.
Modern Alternatives to React — a look at Svelte, Preact, Solid, and Web Components.
What's in a Name? — the story behind Yetric, for anyone curious about where the name came from.

Modern Alternatives to React

2025-05-08T00:00:00Z

TL;DR

React has been a dominant force in web development, but several modern alternatives offer unique features and benefits. Svelte, Preact, Solid, and Web Components are noteworthy alternatives to consider. Whether you prioritize performance, bundle size, simplicity, or interoperability, these alternatives provide fresh perspectives on building user interfaces.

Introduction

React has been the default for a long time. But several alternatives have matured into real options worth understanding on their own terms.

1. Svelte

Svelte is a compile-time framework that compiles your components into highly efficient JavaScript code, resulting in smaller bundle sizes and faster performance. With its intuitive syntax and automatic reactivity, Svelte offers a refreshing and efficient way to build web applications.

Pros:

Automatic reactivity for efficient updates
Smaller bundle sizes and faster performance
Intuitive syntax and ease of use

Cons:

Relatively smaller ecosystem compared to React
Limited tooling and community support compared to React

2. Preact

Preact is a lightweight alternative to React, prioritizing performance and providing a similar API. Its small size makes it an excellent choice for applications where performance and bundle size are critical.

Pros:

Similar API to React, making it easy to switch
Lightweight with a small bundle size
Compatible with most React ecosystem tools

Cons:

May not provide as many advanced features as React
Smaller community and ecosystem compared to React

3. Solid

Solid is a declarative JavaScript library that efficiently updates the DOM using fine-grained reactivity. Its simplicity and performance make it a popular choice for building user interfaces.

Pros:

Fine-grained reactivity for efficient updates
Simplicity and ease of use
Excellent performance and small bundle size

Cons:

Smaller community and ecosystem compared to React
Limited availability of third-party libraries and components

4. Web Components

Web Components is a set of web platform APIs that allow you to create custom, reusable UI components. They offer native browser support and can be used alongside any JavaScript framework, including React.

Pros:

Native browser support
Interoperability with any JavaScript framework, including React
Reusability and encapsulation of UI components

Cons:

Steeper learning curve compared to other alternatives
Requires a good understanding of web standards and APIs

React is still the default for good reason, but Svelte, Preact, Solid, and Web Components are all capable choices depending on what matters most for your project. Performance, bundle size, simplicity, interoperability: each makes a different trade-off worth understanding before you reach for React out of habit.

Navigating Analytics and GDPR Compliance: Key Considerations

2025-01-21T00:00:00Z

TL;DR

Analytics and GDPR compliance require understanding lawful data processing, purpose limitation, anonymization, data minimization, user rights transparency, data security, and appropriate cross-border data transfer mechanisms.

Introduction

Analytics and GDPR aren't naturally in tension, but they require deliberate alignment. The GDPR sets clear rules for collecting and processing personal data, and those rules apply to analytics just as much as any other data activity.

Understanding the GDPR and Its Impact on Analytics

The GDPR is a comprehensive data protection regulation designed to safeguard personal data and enhance individuals' privacy rights within the European Union (EU) and the European Economic Area (EEA). While the GDPR primarily focuses on personal data handling, it also applies to analytics practices that involve processing personal data.

Key Considerations for Analytics and GDPR Compliance

Lawful Basis for Data Processing: Ensure you have a lawful basis, as defined by the GDPR, for processing personal data in your analytics activities. This can include obtaining user consent, fulfilling a contractual obligation, or legitimate interests pursued by your organization.
Purpose Limitation: Clearly define the purpose of your analytics activities and collect only the data necessary to achieve those objectives. Avoid collecting excessive or irrelevant personal data.
Anonymization and Pseudonymization: Anonymize or pseudonymize personal data before using it for analytics whenever possible. By doing so, you minimize the risk of directly or indirectly identifying individuals.
Data Minimization: Apply the principle of data minimization by collecting and retaining only the minimum amount of personal data required for your analytics purposes. Regularly review and delete any unnecessary data.
User Rights and Transparency: Inform users about your analytics practices, including the types of data collected, how it's used, and their rights under the GDPR. Provide a clear and easily accessible privacy policy that explains your data processing activities.
Data Security Measures: Implement appropriate technical and organizational measures to protect personal data used in analytics against unauthorized access, loss, or alteration. Regularly review and update your security practices to address emerging threats.
Data Processor Agreements: If you use third-party analytics providers, ensure you have appropriate data processing agreements (DPAs) in place that outline their responsibilities and compliance with GDPR requirements.
Cross-Border Data Transfers: If you transfer personal data outside the EU/EEA for analytics purposes, ensure you have lawful mechanisms in place to legitimize these transfers, such as standard contractual clauses or binding corporate rules.

Balancing Analytics and Data Privacy

Achieving GDPR compliance doesn't mean sacrificing the benefits of analytics. By implementing privacy-by-design principles and adopting privacy-enhancing technologies, you can strike a balance between data privacy and analytics-driven insights. Consider the following approaches:

Aggregated and Anonymous Data: Use aggregated and anonymized data for broader analytics purposes to mitigate privacy risks while still gaining valuable insights.
User-centric Analytics: Adopt user-centric analytics approaches that prioritize privacy and individual rights, such as pseudonymous tracking, where identifiers are replaced with pseudonyms.
Data Protection Impact Assessments (DPIAs): Conduct DPIAs to assess and mitigate the risks associated with your analytics practices, especially if you process sensitive personal data or engage in large-scale analytics initiatives.

Takeaways

Understand the GDPR's impact on analytics and ensure a lawful basis for data processing.
Clearly define the purpose of analytics activities and collect only necessary data.
Anonymize or pseudonymize personal data whenever possible to minimize privacy risks.
Follow the principles of data minimization and regularly review and delete unnecessary data.
Inform users about analytics practices, their rights, and provide a transparent privacy policy.
Implement appropriate data security measures to protect personal data used in analytics.
Establish data processing agreements (DPAs) with third-party analytics providers.
Legitimize cross-border data transfers by utilizing lawful mechanisms.

Tools Worth Knowing

Matomo (formerly Piwik): An open-source web analytics platform that gives you full control over your data with customizable privacy settings aligned to GDPR.
Plausible: A lightweight, privacy-friendly analytics tool that doesn't use cookies or collect personal data.
Osano Cookie Consent Manager: Helps obtain and manage user consents for cookies and other tracking technologies.
GitGuardian: Scans code repositories for accidental exposure of sensitive data, including personal data.

These are starting points. Assess each tool against your own data flows before committing. This is general guidance, not legal advice — consult a data protection professional for specifics.

Unraveling Technical Debt: The Silent Software Killer

2024-09-03T00:00:00Z

TL;DR

Technical debt is the future cost of revisiting and refining code due to initial trade-offs between speed and quality. Ignoring technical debt can lead to decreased developer productivity, increased costs, and unsatisfied customers. It is crucial to identify high-risk areas, visualize your technical debt, and address it proactively to avoid long-term consequences.

Introduction

In the rapid, iterative world of software development, the goal is often to get a product to market as quickly as possible. However, as software development teams rush to implement new features or meet deadlines, they often have to cut corners. The result of these shortcuts is a concept known in the software industry as 'Technical Debt'.

Technical debt refers to the future cost of revisiting and refining code due to initial trade-offs between speed and quality. Like financial debt, if not managed well, it accrues interest over time - the longer it goes unaddressed, the more costly and time-consuming it becomes to fix. Left unchecked, it leads to slower release cycles, buggy software, unhappy developers, and ultimately, unhappy customers.

Identifying High-Risk Areas

The first step in managing technical debt is to identify high-risk areas within the codebase. These areas are usually files or code blocks with high complexity, high coupling, or high rates of change. This requires comprehensive code analysis and an understanding of the code's architecture and dependencies.

Visualizing Your Technical Debt

Visualizing your technical debt helps prioritize refactoring. That might mean identifying the modules with the highest complexity, the highest coupling, or the parts of the code that change most often.

The Cost of Ignoring Technical Debt

A study by the software analysis and measurement company CAST found that on average, a single dollar of technical debt decreases developer output by $3.61. This means that a significant amount of technical debt can substantially slow down a development team, reducing their productivity and increasing the cost of software projects.

To put this into perspective: suppose you have a team of 20 engineers, each earning an average of $50 per hour. If each engineer loses just one hour per day dealing with issues related to technical debt - a conservative estimate - that's $1,000 per day in lost productivity, or $260,000 per year. And that doesn't account for the indirect costs: decreased morale, higher bug rates, slower delivery of new features.

Embracing a Proactive Mindset

Addressing technical debt requires a proactive mindset from the entire team. This means taking the time to write clean, maintainable code from the start, conducting regular code reviews, and scheduling time for refactoring when necessary.

By investing time and resources upfront in reducing technical debt, teams can realize significant cost savings in the long run. Not only can this improve the team's productivity and morale, but it can also lead to higher quality software, faster delivery times, and ultimately, more satisfied customers.

Takeaway

Addressing technical debt requires a proactive mindset from the entire team. By investing time and resources upfront in reducing technical debt, teams can realize significant cost savings in the long run. This improves productivity, code quality, and ultimately leads to more satisfied customers.

Mastering User Onboarding: Best Practices for Engaging New Users

2024-05-13T00:00:00Z

The onboarding process sets the stage for everything that follows. Get it wrong and users leave before they've seen what the product can do. Get it right and they reach the moment where the value clicks - and stick around.

The Importance of User Onboarding

User onboarding is the initial experience users have with your app. It's the process of guiding users through the necessary steps to get started and demonstrating the app's value proposition. A well-designed onboarding experience can:

Increase User Engagement: A smooth onboarding process helps users quickly understand and utilize your app's features, leading to higher engagement levels.
Reduce User Frustration: Clear instructions and intuitive design during onboarding minimize user confusion and frustration, ensuring a positive user experience.
Drive User Retention: When users successfully navigate onboarding and understand the value your app provides, they are more likely to become long-term, loyal users.

Best Practices for User Onboarding

Simplify the Onboarding Process: Keep the onboarding process simple, focusing on essential steps that introduce key features and demonstrate value. Avoid overwhelming new users with excessive information or too many steps upfront.
Provide Clear and Concise Instructions: Clearly communicate how users can get started and navigate your app. Use simple language, visual cues, and interactive tutorials to guide users through the onboarding process.
Showcase Core Features: Highlight the core features and benefits of your app during onboarding. Demonstrate how these features address users' pain points or provide solutions to their needs.
Offer Progressive Disclosure: Introduce features gradually as users progress through onboarding and become familiar with the app's interface. This approach prevents overwhelming users with too much information upfront.
Utilize Visual Elements: Incorporate visuals such as illustrations, videos, or interactive tours to enhance the onboarding experience. Visual elements can effectively communicate complex concepts and engage users.
Personalize the Onboarding Experience: Tailor the onboarding process to individual users whenever possible. Collect relevant user data during signup and utilize it to provide a more personalized onboarding journey.
Provide Contextual Help: Offer in-context help and tooltips within the app interface to assist users when they encounter unfamiliar features or actions. Contextual guidance reduces friction and improves user understanding.
Encourage Interaction: Encourage users to interact with your app during onboarding. Incorporate interactive elements that allow users to explore features, complete tasks, and experience the app's value firsthand.
Measure and Iterate: Continuously monitor user onboarding metrics and gather user feedback to identify areas for improvement. Iterate on your onboarding process to enhance its effectiveness over time.

Good onboarding is never finished. Measure where users drop off, talk to people who churned early, and keep iterating. The goal is simple: help users reach the moment where the product's value becomes obvious, as quickly as possible.

Mastering User Acquisition: Effective Strategies for Web and Native Apps

2024-02-20T00:00:00Z

TL;DR

User acquisition is essential for growing your web or native app's user base. Effective strategies include defining your target audience, optimizing for search engines, utilizing content marketing, leveraging paid advertising, collaborating with influencers, implementing referral programs, optimizing app store presence, and utilizing social media marketing. Continuously analyze and adapt your strategies to improve outcomes.

Introduction

Growing an app's user base means making deliberate choices about which channels to invest in and continuously measuring what works. Here are the strategies that tend to matter most.

Define Your Target Audience: Understand your target audience - their demographics, preferences, and pain points. This knowledge lets you focus acquisition efforts where they'll have the most impact.

Search Engine Optimization (SEO): Optimize your app's website and landing pages for search engines. Identify relevant keywords, create high-quality content, and ensure your site is user-friendly and mobile-responsive. This helps improve your app's visibility and attracts organic traffic.

Content Marketing: Create valuable content such as blog posts, videos, or tutorials related to your app's niche. Share your expertise, engage your audience, and establish your brand as a thought leader. Content marketing can attract and convert users who find value in your content.

Paid Advertising: Use paid channels such as social media ads or search engine marketing to reach specific audiences. Develop clear ad creatives, use precise targeting, and track campaign performance to optimize results.

Influencer Marketing: Collaborate with influencers or industry experts who have a relevant following. Their endorsement can introduce your app to new audiences and build trust. Select influencers who align with your brand values and have an engaged and active following.

Referral Programs: Incentivize existing users to refer new ones. Offer rewards, discounts, or exclusive features to both sides. Word-of-mouth is one of the most effective acquisition channels when the product is actually good.

App Store Optimization (ASO): Optimize your app's presence in the app stores by using relevant keywords, compelling app descriptions, engaging screenshots, and positive user reviews. ASO helps improve visibility, increase app store rankings, and attract organic downloads.

Social Media Marketing: Use social media to promote your app, engage with your audience, and reach new users. Create useful content, run targeted ads, and participate in relevant communities to build awareness.

Partnerships and Collaborations: Partner with complementary apps, businesses, or creators. Cross-promote or collaborate on joint initiatives to reach new user segments you wouldn't otherwise access.

Remember, user acquisition is an ongoing process that requires experimentation, monitoring, and adaptation. Continuously analyze your acquisition strategies, measure their effectiveness, and make data-driven optimizations to improve results.

Takeaways

Define your target audience and tailor your acquisition efforts to reach the right users.
Optimize your app's website and landing pages for search engines to improve visibility and attract organic traffic.
Create valuable content through content marketing to engage your audience and establish your brand as a thought leader.
Utilize paid advertising channels and influencer collaborations to target specific audiences and expand your reach.
Implement referral programs to leverage word-of-mouth marketing and incentivize existing users to refer new users.
Optimize your app's presence in the app stores through app store optimization (ASO) techniques.
Leverage social media platforms to promote your app, engage with your audience, and drive user acquisition.
Forge strategic partnerships and collaborations to tap into new user segments and expand your reach.

Navigating User Retention: Essential Strategies for Web and Native Apps

2023-11-07T00:00:00Z

TL;DR

User retention is crucial for the success of your web or native app. Key strategies include understanding user behavior, personalizing the user experience, leveraging push notifications, incorporating user feedback, providing regular updates, offering excellent customer support, implementing user onboarding, and creating a user community. Segmentation and context are essential for effective retention strategies.

Introduction

Retaining users is almost always more cost-effective than acquiring new ones. It's also a more direct signal that your product is delivering real value. Here are the strategies that tend to matter most.

How to Improve User Retention

Understand User Behavior: To retain users, first understand their behavior within your app. Use analytics tools to track key metrics such as active users, session length, and screen flow. Identifying patterns can inform effective engagement and retention strategies.

Personalize User Experience: Personalization can make users feel valued and increase their connection with your app. This could involve customizing content based on a user's preferences, behavior, or location, or even simple gestures like using their name.

Push Notifications: Used sparingly, push notifications can bring users back. The bar should be high: only send something when it adds real value - a new feature relevant to them, a meaningful update, or genuinely personalized content. Notifications that don't clear that bar train users to ignore or disable them.

Incorporate User Feedback: Paying attention to user feedback can reveal what users like and dislike about your app. Regularly collecting feedback via surveys, reviews, or direct communication can guide improvements that boost retention.

Frequent Updates and Improvements: Regular updates signal to users that your app is active and evolving. Updates should strive to improve the app experience, fix bugs, and introduce new features based on user feedback and needs.

Offer Excellent Customer Support: When users face issues or have questions, swift and helpful customer support can make the difference between them staying or leaving. Prioritize efficient, friendly, and effective customer support.

Implement a User Onboarding Process: A user-friendly onboarding process can help new users understand how to navigate your app and its benefits. This can greatly improve initial user retention.

Create a User Community: Fostering a sense of community can make users feel part of something larger, encouraging them to stick around. This can be achieved through features like forums, user-generated content, or social media interactions.

Remember, all users are unique, and what works for one might not work for another. Segmenting your users and tailoring strategies to different groups can significantly improve retention outcomes.

User retention requires continuous effort, adaptation, and a user-centric mindset. By listening to your users, understanding their needs, and providing value, you can improve user retention and drive business growth.

Takeaways

Understand user behavior and preferences to tailor your app experience to their needs.
Personalize the user experience to make users feel valued and connected to your app.
Utilize push notifications strategically to engage users and bring them back to your app.
Incorporate user feedback to continuously improve your app based on user preferences.
Regularly provide updates and improvements to keep your app fresh and exciting.
Offer excellent customer support to address user concerns promptly and effectively.
Implement a user onboarding process to help new users understand and navigate your app.
Foster a sense of community to create a loyal user base and encourage long-term engagement.

Decoding User Engagement: Measuring Engagement in Web and Native Apps

2023-08-14T00:00:00Z

TL;DR

User engagement is crucial for the success of your web or native app. Key metrics include active users, session length, frequency of use, screen flow, and retention rate. Qualitative metrics such as user feedback, Net Promoter Score (NPS), and user interviews provide deeper insights. Segment your audience for nuanced understanding. Context is essential in interpreting metrics. User engagement requires a comprehensive approach combining quantitative and qualitative measures.

Introduction

User engagement directly affects customer loyalty, revenue growth, and product direction. Measuring it well means combining quantitative metrics - the numbers - with qualitative signals that explain the why behind them.

How to Measure User Engagement

Quantitative metrics provide numerical data that can measure user engagement in web and native apps. Some primary quantitative metrics include:

Active Users: Both Daily Active Users (DAU) and Monthly Active Users (MAU) are fundamental metrics for engagement. They measure the number of users who interact with your application on a daily and monthly basis.
Session Length: This tracks the duration of user interaction during a single visit. The longer the session, the higher the level of engagement.
Frequency of Use: This metric reveals how often users open and use your app. More frequent usage suggests stronger user engagement.
Screen Flow: Tracking the paths users take through your app can illuminate which features are engaging and where users drop off.
Retention Rate: Retention rate is the proportion of users who return to your app after the first visit. A high retention rate indicates strong user engagement.

While quantitative metrics provide a broad overview of user activity, qualitative metrics add depth by highlighting the 'why' behind user actions. These include:

User Feedback: User reviews, ratings, and feedback can give direct insights into what users think about your app and what improvements they desire.
Net Promoter Score (NPS): NPS measures the willingness of customers to recommend your app to others. It's a strong indicator of customer satisfaction and, indirectly, of engagement.
User Interviews and Surveys: These can provide a deeper understanding of user preferences and behaviours, further illuminating user engagement.

Not all users are the same. Segmenting by user profile, behavior, or lifecycle stage gives you more accurate readings than aggregate averages.

Context matters when reading these numbers. A short session length might signal poor engagement - or it might mean users are getting what they need quickly. You need to know which before acting on it.

No single metric captures engagement. Use a combination of quantitative and qualitative measures, revisit them regularly, and let the patterns guide product decisions.

Takeaways

Monitor quantitative metrics such as active users, session length, frequency of use, screen flow, and retention rate to assess overall user engagement.
Incorporate qualitative metrics such as user feedback, NPS, and user interviews to gain deeper insights into user preferences and behaviors.
Segment your audience based on user profiles and behaviors to understand varying levels of engagement within your user base.
Consider the context when interpreting engagement metrics, as different app designs and objectives can impact the perceived level of engagement.
Use a combination of quantitative and qualitative measures to obtain a comprehensive understanding of user engagement.
Regularly analyze engagement metrics to identify areas for improvement and optimize your app accordingly.
Continuously monitor user engagement to stay attuned to your users' needs and enhance user experience.
Prioritize user engagement as a key metric for driving growth, customer loyalty, and overall success of your web or native app.

Big Update to the Podcast App

2022-08-01T00:00:00Z

We just released a big update to HittaPodd.se, the podcast app for Swedish listeners we launched back in 2019.

New Features

Daily updated toplists (based on iTunes)
Personalized playlists
Seasons for podcasts that have multiple seasons
Trend tracking based on toplist positions
Keeping track of podcast name changes (known as)
More sources for finding new podcasts
A growing list of curated collections of podcasts
Groundwork laid for user accounts and personalized collections of podcasts, playlists, and episode collections — shareable or kept private

Roadmap

User accounts (login with Google, Apple, etc.)
Create your own collections of podcasts
Increase the number of sources for finding new podcasts
Import toplists for more countries
Native app for iOS and Android

Feel free to check it out at HittaPodd.se.

We Launched a Swedish Browser-Based Podcast App

2021-06-19T00:00:00Z

We at Yetric love listening to podcasts and love APIs. So we built a simple app for browsing Swedish top podcasts — a React-based application with an API that grabs data from iTunes, RSS feeds, and more to automatically update itself with the newest, most popular podcasts in Sweden.

We have some ideas on how to make it stand out from other applications, and we'll be doing continued work until we feel it's an app we prefer over others for discovering and listening to podcasts.

Feel free to check it out at HittaPodd.se.

What's in a Name?

2019-10-20T00:00:00Z

This week a friend of mine asked me: "Why is it called Yetric? Any idea behind it or is it just something you grabbed from thin air?". There is an idea. Actually. If you have 2–3 minutes to spare, here's how the name came about.

Why is the company called Yetric?

I've had a company for over 10 years. Mainly focusing on building smaller projects and hoping that one of them would sooner or later generate some income. During that period I learned a lot about finding niches, crafting the offer, and measuring how well a product delivers to the user and to the product's owner (which was often me).

One of the things I am really proud of in my life is that me and my dad built a house in 2010. I lived there for over 7 years with my three kids and my wife. Around 2011 I changed my individual company — named Strategio — to a limited company. I tried to keep the name, but I wasn't allowed, since naming limited companies is harder than individual ones (at least here in Sweden). So I had to pick a new name.

I used the address to the house me and my dad built: 80 Ridge Street Media. I added "Media" since it's vague and kind of lets you offer a lot of different services and products. I was quite happy with the name.

In 2017 me and my wife went through a divorce and we sold the house. I was really close to quitting everything that had to do with having a business. But after some reasoning with myself, I decided to continue — the name just felt strange. It was named after something I didn't own anymore, and it didn't feel right.

So I had to come up with a new name.

"What do I actually want to do for a living?" That was the big question.

I want to live off my products. In order to do that, I need to either scale them up, build new ones, or build and sell products. I don't want to sell stuff I built — it felt bad when I sold the house my dad and I had built together. I really wanted to create things I owned and cared about.

What am I good at? I'm quite good at coding, building user experiences, measuring the impact, and tweaking products according to data. So I decided on two things:

I must do some consulting in order to make a living the first few years.
I want to build a product that helps small business owners with the stuff I had been working on for a long time.

What name should that product have? Yet another metric solution.

That's where I found it. I checked domain names, social media accounts — and Yetric was born. I registered the new name, and that's what's in a name.