Forem: Tom Masson

The "Fruit Basket" problem: Rebuilding PayFit's platform trust & alignment

Tom Masson — Fri, 10 Apr 2026 08:44:03 +0000

If I have to touch infrastructure, I double my estimate.

In early 2025, that was the prevailing sentiment among developers at PayFit. It wasn't that we didn't have tools, we had plenty. We also had a platform team. Actually, we had five of them.

And that was exactly the problem.

The Organizational Pendulum

Between 2019 and 2022, PayFit swung between two extremes:

During our hyper growth phases, we’d have a centralized platform team building abstractions in a vacuum. By the time COVID hit, the pendulum swung the other way, we’d embed SREs directly into product teams to "bring DevOps culture", only to find they were being pulled into daily firefighting instead of building leverage.

We oscillated between monorepos and multi repos. Every swing left behind "ghost" migrations, half-finished initiatives from 2021 or 2022 that developers were still forced to maintain in 2024.

The "Scorecard" Era

Trust reached an all time low during what I call the "Scorecard Era" around 2023. We had SREs embedded in teams, but their objectives were often conflicting. While the product team was trying to ship a critical feature, the SRE was focused on checking boxes on a platform scorecard, metrics that mattered to the platform team but felt like a pain to the developers with no immediate business impact.

We had four or five different platform related teams, and if you asked them how to deploy a new service, you might get four or five different answers. Gregor Hohpe (who explores the "Platform as Product" mindset in his book Platform Strategy) has a great analogy for this: fruit basket vs. fruit salad. A "fruit basket" is a collection of whole fruits, powerful tools, but you have to peel, chop, and mix them yourself. A "fruit salad" is the integrated experience where the platform team has done the heavy lifting for you.

We weren't providing a fruit salad. We were throwing a heavy fruit basket at developers, and it was full of pips.

One Voice, One Team

The biggest change wasn't technical. It was organizational. By late 2024, we had finally stopped the fragmentation. We consolidated those 4-5 different teams into a single Internal Developer Platform (IDP) team.

This "one voice" speaking with a single roadmap and source of truth was the prerequisite for everything that followed. It gave us the opportunity to stop the "pendulum swings" and adopt a true "Platform as Product" mindset.

We also had a rare alignment in leadership: a shared conviction that a strong platform is a competitive advantage, and a collective willingness to prioritize long term stability over immediate feature velocity.

The Frontend Precedent

Trust isn't built with slides, it’s built with proof. Our frontend teams had already moved to an Nx monorepo and were seeing massive benefits in caching and developer ergonomics (a journey featured on the Nx blog and Nicolas Beaussart just gave a great talk over at the React 2026 conf in Paris).

They definitely opened the door and led the way for the rest of us. By the time we proposed the same model for backend and infrastructure, we weren't asking for a "leap of faith", we were simply following a path they had already cleared.

The Change Policy: Paved Road over Mandate

The "one voice" consolidation wasn't just about efficiency, it was about strategy. It allowed us to shift from a mandate driven culture to a "Paved Road" model.

We stopped trying to force teams to migrate. Instead, we focused on making the new Internal Developer Platform so much faster, more stable, and more intuitive that it became the path of least resistance. When the Paved Road is 10x better than the legacy "Dirt Road", you don't need a mandate, teams will naturally choose it. This reduced organizational friction and let us focus on building a product that developers actually wanted to use.

The Turning Point: The Interview Tour

With a unified team finally in place, we realized we couldn't just "tool" our way out of the remaining trust deficit with the teams. We stopped building and started listening.

Throughout H1 2025, we conducted an "Interview Tour". We identified key players across every domain & team and conducted 45 minutes deep dives. We didn't ask "what tools do you want?" We used a set of prepared, open ended questions to drive the discussion and collect essential qualitative feedback on "where it hurts."

The feedback was raw:

"If I have to touch infrastructure, I double my estimate."
"Migrations feel like a trap because they never end."
"I don't know who to talk to when my pipeline breaks."

The Result

Product first mindset: We treated our developers as customers, not captive users. We rebuilt the platform foundations in public, starting with CI/CD, and made the work visible as it happened instead of revealing it only once it was finished.
Working with teams, not for teams: We kept talking to users continuously, shared wins publicly, gave kudos for every contribution, and backed the story with concrete data. The goal was not to build a platform for developers in isolation, but to build it with them.
A better developer experience: We focused relentlessly on the basics developers actually feel every day, faster workflows, more reliable pipelines, and less platform friction. That also meant cleaning up our own setup first and dogfooding the same repository patterns, tooling, and workflows we wanted other teams to adopt. In other words, we cleaned our house before inviting guests.
Starting with the right early adopters: We deliberately began with a handful of teams we already had strong relationships with. We gave them our full attention, treated their issues with the new system as our top priority, and fixed problems fast. That was the least we could do: they were trusting us with a brand new platform, and their feedback directly helped us improve it.
The turning point: At first, we were the ones asking teams whether they wanted to migrate. Then, gradually, the dynamic flipped. More and more teams wanted in, to the point where demand started to outpace our capacity to support migrations. That was a great problem to have, and the clearest signal that trust was coming back.

By shifting from "Platform doing things TO us" to "Platform working WITH us", the narrative started to change. We didn't create momentum with mandates. We created it by listening, improving the house, and proving that the paved road genuinely delivered better DX, faster workflows, and more reliable outcomes.

But to deliver on the promise of a "simpler & faster workflow", we had to tackle one of the monsters under the bed: CI/CD complexity.

In Part 2, I’ll dive into how we rebuilt our CI pipeline with Nx to drive standardization, performance, and stability across the entire organization.

How 3 friends created and published a video game in less than a year without writing a single line of code ?

Tom Masson — Fri, 03 Apr 2026 13:24:13 +0000

About a year ago, two friends and I casually discussed the idea of creating a video game. We did not know what we wanted to do nor how to do it.

Where do we start ?

So to begin with, we started to review all the video games genres we liked, to see if we had any in common. From that, we quickly studied the current business situation of the party games as that was what we opted for. It seemed to us that it was kind of an opportunity as there were not many party games out there although being a niche genre.

We created a company to be able to share hypothetical revenues fairly and had to find a bank to host our company account.

After discussing all of this, we were ready to start and deep dive in the actual project.

Actually starting

So we knew the genre of game we wanted to make but how do we actually create a video game ?

We started to study game engines, how to publish a game and on which platform (Steam, Epic, itch.io, …) as both are linked. We did want to publish it on PC and most likely on Steam because basically everyone has been using this platform for years.

For game engines, Godot was too young, Unity just released a statement to make the developers give them more money, so we were left with Unreal Engine.

We did a quick review of all the technologies and languages offered to us by Unreal Engine and ended up choosing to use the visual scripting tool called Blueprints, which let us create game logic without needing to code.

Blueprint no-code example

To be fair, using Blueprints is coding visually with an object oriented language but it made our lives easier and we did not have to learn C++ which would have been much more time consuming. And spoiler alert, we still think we made the right choice on this. Yes we saw limitations but the gain of time and productivity is worth it.

Building the game

The first steps were pretty intimidating. But after following several tutorials found on the web, we were getting a little bit used to UE 5. Then we started prototyping several ideas of mini games we had.

The workflow we found the most effective was:

Someone has an idea of a mini game
We all discuss it to find whether or not it's worth developing
We develop a quick & dirty prototype, without any 3D asset or map

Prototype of a mini game

We test it together to evaluate the potential of the gameplay, ask feedback to friends, re-assess the idea, think about potential functionalities
Finally if its a go, we break down everything in simple tasks

We tried around 25 different ideas and finally released around 15. Not all the ideas were good or easy to develop. We had to find a balance between fun, development time and skills.

We started by creating simple mini games like giving a bomb that is randomly exploding to other players by colliding with them.

Do not keep the bomb !

And then moved on more advanced ones with physics, enemies using AI and vehicles.

Build the highest tower !

Everything had to be synchronized across all 8 players. It took time and we had to do some technical trade offs but we managed to get a pretty smooth gameplay.

Move the maximum of boxes across the bridge!

It wasn’t easy to avoid the common pitfalls that many indie developers face:

It is really easy to drown in the possibilities offered by Unreal Engine. It is a really complex game engine to manage and the documentation is not the best, we often found ourselves fiddling around little details that did not matter or investing time in functionalities we did remove at the end.
Unsuspected technical difficulties like using Git with Unreal Engine which was a pain and cost us a bunch of time and we probably should have used Perforce. The installation of the game engine locally can also be a time consuming event when asking friends to help on the project.
Try to avoid tunnel vision. As it was a side project and all of us had day jobs, we tried to ensure we all have smooth communication using Discord. But it happened a couple of times when one of us was working real hard on a functionality and stopped giving regular feedback to others. It usually turned out we spent far too much time and effort on something we did not agree on and was not on the roadmap.
Keep your eye on the target of what you try to achieve: we bought all of our 3D assets from Synty's marketplace as none of us were able to use any 3D modeling tool. We also bought our animations. We actually gained so much time by not bothering to try and keeping focus on what we tried to achieve: creating a game.
Respecting the copyright license of each 3D asset, sound, music we have used took time. We had to read in detail what we legally could or couldn't do and keep track of which asset has which license.
Do not hesitate to leverage the Unreal Engines huge community to ask for help whether on their forums or on Discord. People are helping each other and it can save you a day or two of looking around for a solution to solve a weird bug.
Automate QA, especially when creating a multiplayer game. Writing code, developing functionalities is fun but spending some time investigating automated testing will be worth it in the end as usual in a tech project, even in the video game field. We actually did not use any of the automated testing features provided by Unreal Engine and we end up usually breaking some stuff when releasing updates.
Leverage technology to gain productivity. We have created ourselves several tools to make our lives easier. For instance we have used a lot of Procedural Content Generation to quickly set up new maps, automatically generating race tracks & decorations.

Actually shipping

After months of development, the game was starting to actually look like a real game that people could play. We started to get a bit tired of spending all of our free time on this project and we asked ourselves when we should stop the development and start polishing the game to actually release it. That should be an easy task right ?

Well not really... Up until this phase, we did not take the time to apply the juicy gaming theory to our mini games to make them satisfying to play.

We thought we were nearly ready to release but it finally took us several weeks of hard work to make sure that on each and every gameplay interaction there was as much feedback as possible using sound design, FX effects, camera shakes and so on.

Example of our juicy gaming design with FX effects, lights and so on

We also translated our game into multiple languages, made it compatible with controllers, and added menus and notifications to improve accessibility which is not to be underestimated.

Now, let’s address the elephant in the room, the marketing. As you probably realized, I did not talk about this up until now and that is clearly a mistake we made. We did not start marketing soon enough and failed our release because nobody knew about the game. Basically we have learned that marketing should start as early as possible because it takes time to build anticipation and a community from the ground up.

Failed launch

So... yeah, we failed our game release.

But the most important fact is that we learned a bunch of things and after working on it for countless hours, weekends and evenings, we actually released a real game on Steam.

As 3 friends who were wondering if they could actually create a game from scratch during a random conversation about a year ago, I would say we did it... And we are still friends!

At the time of writing we sold 240 units that means we have managed to pay back our investment of around 2000 euros in 3D assets, animations, music and sounds.

Key learnings along the way:

Marketing is the hardest part for us tech folks and it is really an important factor in the success of a game release. Fun fact, we leveraged some Reddit threads to improve our game trailer and texts for our Steam page.
Working with friends is not easy, especially when relying on free time. Not everyone has the same amount of free time to give, and managing schedules is a hard task. Sometimes you will have to disagree and commit. Teamwork, adaptability and project management are a must.
Gather and listen to feedback as much as you can and as early as possible: We actually asked a lot of our friends for their honest feedback from start to finish and it was really valuable. When working daily on the game, we often lacked perspective and it helped us get back on track.
Creating a game requires a dozen different skills. We did not realize that before trying to make our own. Game design, sound design, FX effects, animations, UI/UX, 3D modeling, mapping, developing, QA, marketing... All of those are different jobs.
The learning curve for Unreal Engine is steep, but with dedication and a focus on mastering the basics, it's absolutely manageable.
Steam is taking 30% on each sale, adding that to the bank fees and taxes, you need to sell a lot of units to gain real money.
Time is the most valuable resource you have as an indie developer, spend it wisely on subjects that matter the most.
Unreal Engines Blueprint system is handy but it will slow down a developer's pace.
Developing a multiplayer game (even more for 8 people) is significantly more challenging than creating a single-player game. In hindsight, we probably should have started with a single-player project.

What would you do if you had a year to create a video game? I’d love to see your ideas in the comments !

How we unified our Terraform module repositories

Tom Masson — Fri, 14 Nov 2025 10:54:34 +0000

Ever tried managing 15+ separate GitHub repositories for your Terraform modules? That's pretty much what we faced at Payfit. Our infrastructure codebase had fragmented into a nightmare of individual repos with time, each with its own CI/CD pipeline, versioning scheme, and tooling setup. Cross-module changes became coordination nightmares.

The problem: When repositories multiply like rabbits

Picture this: Your infrastructure team maintains multiple GitHub repos, with each Terraform module kept in its own repository. A simple VPC module change requires you to: update the module repo, bump versions in 5 downstream repos, trigger 6 separate CI pipelines, and spend the day merging PRs.

That was us six months ago.

Our initial approach, a scaling nightmare

Each Terraform module lived in its own repository with dedicated CI pipelines, separate versioning, and isolated tooling. While this provided clear ownership boundaries, it created massive overhead:

Version management hell & poor velocity: Bumping versions across dependent modules required synchronized releases and multiple PRs
Tooling drift: Different tflint versions and terraform standards per repository
Context switching: Teams bounced between repositories constantly

The breakthrough: Nx monorepo consolidation

The turning point came when we consolidated all Terraform modules into a single monorepo. Nx provided the orchestration layer that made this transformation not just possible, but elegant.

Project structure transformed

Each Terraform module becomes an Nx library project under terraform-modules/:

terraform-modules/
├── aws-lambda/        # Nx project: terraform-aws-lambda
├── aws-ecr/          # Nx project: terraform-aws-ecr
└── aws-s3/           # Nx project: terraform-aws-s3

Unified module management

Every Terraform module becomes a first-class Nx project with inferred tasks. Our internal local Nx plugin automatically detects terraform modules and provides standardized targets using Nx's inference system:

tofu-format: Consistent formatting across all modules
lint: Parallel linting with TFlint and validation

It looks something like this:

targets['tofu-format'] = {
      executor: 'nx:run-commands',
      cache: false,
      inputs: ['production', '^production'],
      outputs: [],
      options: {
        cwd: '{projectRoot}',
        command: 'tofu fmt -recursive',
      },
      configurations: {
        check: {
          args: '-check',
        },
        write: {
          args: '-write',
        },
      },
      defaultConfiguration: 'check',
      metadata: {
        technologies: ['tofu'],
        description: 'Format OpenTofu code',
      },
    }
    targets['lint'] = {
      executor: 'nx:run-commands',
      cache: false,
      inputs: ['production', '^production'],
      outputs: [],
      options: {
        cwd: '{projectRoot}',
        commands: [
          'tofu init -backend=false',
          'tflint --init',
          'tflint',
          'tofu validate',
        ],
      },
      env: {
        TFLINT_CONFIG_FILE: options.tflintConfigFile,
      },
      metadata: {
        technologies: ['tofu'],
        description: 'Lint OpenTofu code',
      },
    }

The beauty? Zero configuration needed. Drop a terraform module in the repo, and Nx handles everything automatically. We will even be able to generate the skeleton of a classic module using Nx's generator system.

Nx Release: unified module publishing

The real transformation happened with Nx release. Our internal @payfit/nx-core plugin orchestrates coordinated releases across all publishable artifacts over @ Payfit, including terraform modules.

The release command analyzes git history and only releases modules that have actually changed:

npx nx release

The result? Cross-module changes deploy together, while individual module updates release independently, in a single PR.

The trade-offs: nothing's perfect

Now, this monorepo approach isn't without its (small) downsides:

Pro	Con
Smart Releases: Intelligent orchestration across modules	Larger Repository: Single repo grows over time
Parallel Execution: Quality checks run simultaneously	Nx Learning Curve: Team needs to understand Nx concepts
Automated Standards: Consistent tooling across all modules	Migration Effort: Consolidating 15 repos requires planning & time

For us, the benefits far outweigh these costs. We've dramatically improved our infrastructure velocity and consistency.

Outcomes: from chaos to streamlined Terraform modules management

The impact was immediate and measurable:

Unified Management: Single Nx workspace orchestrates all 15+ modules
Zero Configuration: Plugin automatically provides all terraform targets
Automated Standards: Consistent tooling and validation across all modules
Velocity: Single PR needed to update one or several modules simultaneously

The key insight? Treat infrastructure modules like any other software project, with proper versioning, testing, and release management. Nx makes this possible at scale.

Have you faced similar repository chaos? How did you tackle it?

Automated frontend previews: Payfit’s path to faster PR reviews

Tom Masson — Tue, 30 Sep 2025 07:55:43 +0000

The Bottleneck: Slow PR reviews

📷 Picture this: your team just finished implementing a crucial feature. The code looks good, tests are passing, but there's one problem, no one can actually see the feature working without pulling the branch locally or watching static screenshots. Sound familiar?

That was us moments ago. Our review process looked something like this:

Developer opens a PR
The team reads the code (🤔 "This looks right...")
They either approve based on code alone or ask for screenshots
If screenshots aren't enough, well... We had to make it work somehow.
Repeat until everyone's happy

The result? Review cycles that took days instead of hours, and not-so-great velocity.

Our first attempt: Front-on-Demand and why it didn't scale

Each team then had one staging environment of the same exact app. When they needed a review and when their staging environment was in use, they were able to manually push the app to it. We called it "Front-on-Demand" (creative, right?).

This worked... sort of. The problems quickly became apparent:

Sequential bottleneck: Only one branch could be deployed at a time per team
Manual overhead: Devs had to remember how to deploy from their laptops
Resource waste: Staging environments sitting idle or forgotten

We needed something better.

The Breakthrough: PR Previews on Autopilot

The turning point came when we decided to treat PR previews as a first-class citizen in our CI/CD pipeline. Our goal was simple, every PR should automatically get its own preview URL quickly and be cleaned up automatically, of course.

Here's the workflow:

Nx magic: our publish-preview executor

Instead of writing custom deployment scripts for each app, we created a single, configurable Nx executor that works across our entire mono-repo & easy to enroll for new apps. It handles the entire preview deployment pipeline based on simple steps:

Determine current branch (default or not)
Get the current PR
Get the built app and upload it to S3 using the AWS CLI
Comment the PR to let the user know we've deployed/updated the preview environment of the PR.

What Nx brings to the table

Before we dive into the AWS infrastructure, let's pause and appreciate what Nx brought to the table:

🏗️ Monorepo Architecture: Nx understands dependencies between apps and libraries, making it perfect for complex monorepos where changes ripple across multiple applications.
🎯 Affected Project Detection: Nx automatically identifies which apps are impacted by your changes. No more manual configuration or complicated guessing, Nx figures it out for you.
🔧 Executor System: Our publish-preview can be configured per project and is automatically inferred by a local plugin. To enroll a new app, you simply add a metadata flag like "previewDeploy": "true" in the project.json file and you’re basically done !

To power all of this, we run a single command in CI: yarn nx affected -t publish-preview

Infra magic with AWS: S3 + CloudFront + Lambda@Edge

The infrastructure magic happens through a combination of S3, CloudFront, and Lambda at edge. Of course there is also a WAF and some other things that we won’t be talking about for simplicity’s sake.

Our Nx executor uploads each PR's build to a specific S3 path:

// For each PR, each affected app gets its own S3 path: {pr-number}-{app-name}
const s3Path = `s3://${options.bucketName}/${pr.number}-${context.projectName}`

// Upload with no-cache headers for immediate updates
await exec(`aws s3 sync ${distPath} ${s3Path} --cache-control "max-age=0"`)

Then, thanks to both our lambdas at edge we secure the CloudFront endpoint (which is public by default) & rewrite the path to be able to use clean URLs like https://{pr-number}-{app-name}.preview.my-domain.com. The path rewrite is looking something like this:

const host = request.headers.host?.[0]?.value
const subdomain = host.split('.')[0]
if (subdomain) {
  request.uri = `/${subdomain}${request.uri}`
  return callback(null, request)
}

return callback('Missing subdomain')

This means that we have:

PR #123 for app foo → https://123-foo.preview.my-domain.com
PR #456 for app bar → https://456-bar.preview.my-domain.com

Our Lambda@Edge function routes these custom domains to the correct S3 paths.

This gives us clean, predictable URLs for every PR without any manual intervention. Using this setup we are able to support nearly an unlimited amount of apps using a couple of lambdas, a single CloudFront, a single S3 bucket and a single Nx cli command.

We learned to really value short feedback loops and giving users clear solid feedback about what’s going on. We are pushing a message in the deployed PR each time we deploy or update the affected apps:

Outcomes: Faster Reviews, Happier Developers 📈

The impact was immediate:

🕐 Review time: while we weren’t able to measure it precisely, it dropped significantly
💪 Confidence: Reviewers could actually see and test changes in a couple of minutes tops !

But the best metric? Developer satisfaction. No more "Can you deploy this so I can see it? Is the environment free?" messages in Slack.

Building an automated PR preview system transformed how our team reviews code for frontend apps. What started as a manual, error-prone process became a smooth, automated experience that developers actually love using.

The key was treating previews and developer experience not as an afterthought, but as a core part of our development workflow. With the right tooling (Nx executors, Nx cloud cache), infrastructure (AWS Lambda + CloudFront), and automation (Nx agents), we created a system that scales with our team and keeps everyone moving fast, taking less than 2 minutes to deploy an up-to-date app. And there is nearly 0 maintenance time.

What's Next: Towards a Developer Platform

Over at Payfit we're building our developer platform based on Nx and custom plugins, allowing us to manage the whole CI pipeline easily and publishing artefact simply using nx release, which will be the subject of another blog post pretty soon!

👂 I'd love to hear your thoughts! Drop a comment below and let me know if you've implemented similar systems. What tools and strategies have you found effective?