Independent technical expertise · Stockholm

Twenty one years of building software. Nine of leading the people who build it.

I am Luis Rizo, CTO at 360Player, previously CTO at Wimt. Before that I led Klarna's shopping group, around 60 people, and built the frontend department at PriceRunner. I take on a small number of focused engagements a year: getting engineering teams genuinely productive with AI, telling investors and boards the truth about a codebase, and turning consultant dependent tech functions into teams that own their own product.

Tell me what is stuck See how I work

We replaced the asphalt on the motorway while the cars were still driving.

Luis Rizo, on rebuilding a live platform

Three engagements

AI enablement for engineering teams

Your team has licences for four AI tools and no shared idea of what good use looks like.

Most AI rollouts stall at the demo. The tools get bought, a couple of people go deep, everyone else pastes code into a chat window and quietly concludes it is overrated. The gap is not the model. It is that nobody has defined what a reviewed, trustworthy, AI assisted change actually looks like in your codebase.

I work this from the inside, because it is how I work myself: a loop where one model sharpens the specification and interrogates the requirements, an agent implements against it, a second model reviews the diff, and a human owns the last mile. That loop is teachable. I have taught it.

What you get

An honest read on where your team actually is, not where the licences suggest they are
A working loop of specification, implementation and review, adapted to your stack and review culture
Guardrails: what AI may touch, what it may not, how a diff gets trusted
Your strongest people turned into the ones who spread the practice, so it survives me leaving

Right for you if you have 5 to 50 engineers, the tools are already bought, and adoption is uneven.

Technical due diligence and architecture review

Someone needs to tell you what you are actually buying, or actually running.

I have been the person on the inside of the platform that looked fine in the deck. A backend as a service that carries a product to its first thousand users and then quietly caps its ceiling. A frontend that three teams are afraid to touch. Diligence that only reads the architecture diagram misses all of it. The real risk sits in the delivery process, the key person dependencies, and what the team is unwilling to say out loud in front of management.

You get a written assessment a board can act on: what is genuinely load bearing, what is one incident away from being a problem, what it would cost to fix, and what I would deliberately leave alone.

What you get

Architecture and infrastructure assessment against where the business is actually going
Delivery and team review, covering velocity, key person risk and the on call reality
A ranked risk register with a cost and a timeline against each item
Build versus buy recommendations, written for executives rather than engineers
A proof of concept where a document alone will not settle the question

Right for you if you are an investor before the term sheet, a board weighing a replatform, or a CEO who suspects the answers they are getting are too comfortable.

Building and scaling a tech organisation

You are paying a consultancy to hold knowledge that should belong to you.

At Wimt I took over a tech function that was seven consultants and a backend as a service. Ten months later it was ten employed engineers running Go microservices on AWS, the last consultant contract was closed, and the platform dependency was switched off, with features shipping the whole way through. At PriceRunner I built the frontend department from the ground up and owned all frontend development, technically and organisationally.

I am aware of the irony of a consultant selling this. Which is the point: my incentive on this engagement is to make you not need one. There is no phase two.

What you get

A staged plan from consultant dependency to an in house team, with the sequencing that keeps delivery alive
Hiring: what the roles actually are, how to assess for them, how to be the offer that gets accepted
Migration off the platform decision that is now holding you back, motorway open throughout
Structure that survives growth: ownership, on call, how technical decisions get made
A named successor, coached, before I leave

Right for you if you are a scaleup whose tech is delivered by people who do not work for you.

The terms

How I work

01
Scoped, not open ended.
Every engagement has a defined end and a written deliverable.
02
Part time by design.
I am a working CTO. That is the reason the advice is current, and the reason I take few engagements.
03
The deliverable is your team's capability.
If you need me a second time for the same problem, I did the first one badly.
04
I will tell you if I am the wrong person.
Cheaper for both of us than finding out in month two.

Twenty one years, nine of them leading teams

Background

2026 to presentChief Technology Officer360Player
2025 to 2026Chief Technology OfficerWimt
2022 to 2025Senior Engineering Manager, ShoppingAccountable Group Lead and Competence Lead for the whole shopping group: about 60 people, 45 of them developers, with responsibility for both product and tech.Klarna
2017 to 2022Engineering Manager & Tech LeadPriceRunner
2016 to 2017Tech LeadSemantix
2008 to 2016Web DeveloperValtech
2007 to 2008Web DeveloperCreuna
2005 to 2007System DeveloperTeliaSonera

Domains shipped inpayments and fintech ·price comparison at scale ·sportstech ·localisation ·telecom

Educated at Luleå tekniska universitet. Based in Knivsta, working Stockholm. Available in English or Swedish.

The name

Why Raku

The name Raku carries several meanings that mirror the way I work. In Japanese the word means joy, a feeling I want to carry both into what gets built and into the meeting with the people I build it for. Like the ancient ceramics tradition it is named after, this practice values what is unique, what is human, and what takes shape in the present moment.

Raku pottery is also fired fast, handled while hot, and never comes out twice the same. That is a fair description of a short, scoped engagement inside a team that is already moving.

Contact

Describe the problem in three sentences.

That is usually enough for me to tell you whether I am useful, and whether it is worth a call. If I am not the right person I will say so, and I will usually know someone who is.

Email info@raku.se

Also on LinkedIn, where the full record lives · Knivsta / Stockholm · English or Swedish