Experimenting daily with Claude Code, V0, Gemini CLI. 
From legacy to clarity: –20% checkout configuration time
Background
Checkoutly is a service for configuring checkout across 100+ countries for more than 10 games. Before the redesign it was a massive spreadsheet with all parameters: payment methods, countries and providers. This service was used on a daily basis to maintain working checkouts and optimise spending — important for a company processing billions a year.
Challenge
How can we make configuring checkouts flexible for optimising spending and decreasing daily time for maintenance tasks?
Impact
Problem
Legacy service becomes outdated and doesn't meet current business goals
Business: Couldn't launch new payment features without months of engineering.
Users: Managing 100+ countries with high error risk and no way to preview changes.
Engineers: Legacy code made maintenance difficult and new features impossible.
Process
Structured ideation: tracing solutions back to payment manager's pain points and business outcomes.
Insight 01
87% of sessions were single-task — so why was the UI built for multitasking?
User logs revealed that nearly all sessions involved one configuration task — yet the UI was a matrix built around the data model, not user behavior. This insight drove the shift from matrix layout to task-based navigation.
Grey — single task type per day, yellow — mixed-task.
Insight 02
Users didn't know what changes would appear in production
Payment managers pushed changes without previewing their effects — checking required a cumbersome VPN setup. We introduced a checkout preview to visualize and verify changes before they went live.
"Before, I'd push a change and pray. Now I actually see what the customer sees before anything goes live." — Payment manager
Insight 03
The business objectives were not aligned with the current setup
Operators managed 100+ country configurations that were mostly copies of regional defaults. We introduced the Default Country concept — set a regional default, override only when necessary — cutting configurations from 100+ to ~30.
Insight 04
Draft mode seemed simple — scoping V1 made it real
Saving changes as drafts revealed hidden complexity — split drafts meant versioning nightmares. We chose a single draft with a preview of unpushed changes, then scoped a V1 covering 80% of use cases.
We could've shipped something simple that would've broken under real usage. Solving it right meant harder conversations upfront, but a feature that held up.
User Testing
Validating core interactions
Task-based structure is intuitive and easy to navigate
Replaced matrix view with single-task flows got positive feedback from all users.
Iterating on details
User testing sessions helped identify areas for improvement across key scenarios.
Some of Solutions
What we shipped
Checkout preview
Operators see exactly what customers see before any change goes to production.
Default Country system
Regional defaults with per-country overrides — 100+ configs reduced to ~30.
Supporting architecture
3 layers of provider configuration: general configuration with failovers and overrides for countries in Integration and Checkout preview.
Results
New system evaluating with business
Business: 4 new features shipped in 1.5 years — on the new architecture, not bolted onto legacy.
Users: Daily maintenance task completed 20% faster, self-serve actions up 44%. The live preview became their most-used feature.
Learnings
Four lessons I learned the hard way
The decision I almost didn't make. Pulling log data felt like overkill for a "simple redesign" — but the 87% insight reframed every design choice. Without it, we would've redesigned the matrix, not replaced it.
Align with engineering early. Draft mode taught me the most elegant solution on screen can be the most expensive in code. Early technical conversations are a design tool, not a constraint.
Simplification requires courage. Telling stakeholders their 100+ checkouts metric was misleading wasn't comfortable. The product got better because someone said it.
What didn't ship matters too. Tight timelines meant some improvements stayed on the backlog. Knowing what to cut is part of the craft.
