Page three

What I'd actually do.

Here's how I'd spend the first thirty days, what the standing work looks like after that, and how I use AI, since your stack names three providers and I build tooling in that space.

First thirty days

Earn the keys before spending them

No roadmap proposals in month one. I'd rather arrive with questions and leave with three merged changes.

Follow one euro all the way
A reader lands on a Swedish comparison page, clicks through, opens an account, and money eventually reaches you. I want every step written down: the tracking, the partner's reporting, the reconciliation, and where the record finally lives. If I learn one system in month one, it's this one.
Read the repository and ship three real things
Not warm-up tasks. The smallest genuine items on the list, reviewed by your developer. Three merged changes tell us both more about whether this works than four weeks of onboarding calls.
Read the competition before I read the analytics
Lendo, Compricer, Zmarta and Kortio in Sweden, Finansportalen and Lendo in Norway, Mybanker in Denmark, Rahalaitos and Sortter in Finland, and Cryptowisser, CoinGecko, BrokerChooser and Finder on English crypto queries. I'd take the twenty searches that earn you most, note who sits above you in each market, and write down what their page does that yours doesn't. Worth flagging early: Lendo, Compricer and Mybanker are all Lendo Group, so four competing names can be one company.
Get the boring version of the numbers
Which pages earn, which markets under-earn relative to their traffic, which partners are quietly worth double their click volume. I'd rather propose a roadmap on the fourth week from data than on the first day from instinct.
Write down everything that surprised me
Every new person sees the seams for about three weeks and then stops noticing them. I'll keep that list and hand it over whether or not I get to act on it.

After that

The standing work

Your posting lists five responsibilities. This is how I'd hold each one.

Own the roadmap
One ordered list, visible to the team, every item carrying the bet it makes and the number it expects to move. Anything without a number attached is a preference, and preferences sort to the bottom.
Build and ship hands-on
I'd keep writing code, in your conventions rather than mine. Laravel, Blade, Alpine, Tailwind. No imported stack and no rewrite.
Set up the engineering workflow
A branch per change, a pull request nobody merges alone, checks running on GitHub Actions, and tests on the money path first: referral tracking, the fee data, the payment reconciliation. Deployment that rolls back in one command. I wrote docker-release for exactly that, and would happily throw it away for yours.
Treat data accuracy as a promise, not a task
Every published number gets a source and a date, and anything past its age shows up on a screen before a reader finds it. That's what page two is arguing for.
Grow the team
First hire is a second full-stack who can own one platform end to end, not a specialist. Before writing an advert I'd write the role, the paid trial task and the rubric I'd judge it by. I said on page one that this is my thinnest area, and it still is, so I'd want your read on the first two hires.
Decide with data
One headline number, revenue per 1,000 sessions split by market and platform, reviewed weekly, with the tests that moved it listed underneath. Traffic reports are an input. If a change can't be measured, I'd rather we say so before making it.

How I work

On the AI question

Your stack lists Anthropic, OpenAI and Google, and your product is a promise that published numbers are correct. I build tools in that gap, which is why I don't leave a model unsupervised.

Two of my own products, pluk and Oga, both aimed at the same problem: give a model enough access to be useful and not one inch more.

pluk · pluk.desgn.space

Production access without handing over the keys

A menu bar app that turns the services you already run (Postgres, MySQL, SQLite, Linear, Sentry, SSH hosts) into local endpoints an AI client can use. It runs entirely on the machine, there's no cloud relay and no account, credentials never leave, and writes are blocked by default before they ever go out.

The part that matters here: every request is logged. When a model touches live data there's a line saying which service, which statement, and whether it succeeded.

pluk showing grouped services for a project and a log of every statement run through them, each marked ok or error.
pluk. Services grouped per project, each labelled local or production, and a full log of every statement that went through them.

Oga · oga.desgn.space

More hands, inside a budget

Oga hands a bounded piece of work to a background agent in its own branch, with an explicit brief and explicit file access, and gives it back as a diff and a cost. Nothing is merged by the tool. Every task ends with me reading the changed files.

I built it because I wanted more work in flight than one account's limits allow, spread across whichever tools had capacity, at a price I control. Same thinking applies here: if a model drafts content across three sites and five markets, cost per thousand pages is a product decision, not a surprise on an invoice.

Oga showing a delegated task with its activity log, the checks it ran, and the ten changed files with line counts.
Oga. One delegated task, everything it ran, the reviewer's verdict, and the ten files it changed, which is where I start reading.

The working rule

A model writes the draft; a person owns what ships. Nothing reaches review that I can't explain line by line, nothing reaches production unread, and no generated sentence about a fee or a rate gets published without an editor approving it.