From Hello World to a Dispute Management back office

How does a new team tackle a project with a tight deadline and no clear specs on what’s required? By going back to basics.

Selling a refactor to business stakeholders is hard. We all know that. They’re more concerned with business metrics than technical ones. But what about convincing them to allow a team of 12 people to put three months of work into building what might be the world’s fanciest “Hello, World” application? One that does nothing? With no business metrics whatsoever?

Sounds crazy, right? And yet…

Context is for kings

Let’s start with a bit of context: Adevinta is a global online classifieds specialist, operating digital marketplaces in 11 countries and our mission is to provide technology-based services to connect buyers with sellers and to facilitate transactions, from job offers to real estate, cars, consumer goods and more. Although our digital marketplaces serve the same purpose, they are quite different in terms of underlying platform and software.

Many of Adevinta’s marketplaces allow transactions on the platform, where users can buy, pay, and receive shipments directly on the site. But what happens when one of the parties doesn’t keep their side of the deal? What if the item is not the one advertised? Or it’s broken? Wasn’t shipped? Didn’t arrive? A lot of things can go wrong. And it usually ends with a dispute, in which someone needs to arbitrate and decide which of the two parties is right.

Everything we never wanted…

This brings us to the current story. Several months ago, my frontend enablement team was merged with a team composed of mostly backend specialists. We were tasked with creating a back-office interface that would allow operators to visualise the entire chain of events that led to the dispute and take the appropriate action. The catch — our solution couldn’t be marketplace specific, but rather a reusable component that can be plugged into any marketplace — Subito, Milanuncios, Kleinanzeigen, and so on — regardless of its underlying technology, data model, third-party integrations, or transaction flow.

But it wasn’t all chaos. Some things were very clear from the start. Mostly around the deadline.

“Think big” we were told. And this was pretty much the brief we got, without any additional details. This left us in a bit of a pickle. While there was a high-level understanding of what the end goal would be, there was no clear product definition or path to get there. Recap: we had a newly established team whose members have never worked together in this format, a tight deadline with no clear specs, no project manager to guide us through, no designer to help with the UI, and no real understanding of what was expected of us. Everything we never wanted.

But it wasn’t all chaos. Some things were very clear from the start. Mostly around the deadline: by the end of the year, this needed to be in production.

Let’s abstract everything!

We like to see ourselves as innovative and resourceful, so we started looking for ways to jumpstart the project with what we had. We do encounter unknowns in software development and we use abstractions to deal with them. In essence, abstraction is the process of removing some details that are not yet clear or are prone to change from the initial definition to allow engineers to focus on topics of greater importance and add them back later when there is a better understanding of the requirements.

But what happens when the part that needs to be abstracted is the very thing we’re trying to build? Can we abstract the product itself? As it turns out, to some extent…yes we can. It’s just a game of finding out what the ”knowns” are and implementing them in a way that allows for details to be plugged in later when the final requirements crystalise.

Can we abstract the product itself?

We started by compiling a list of pure technical requirements while steering clear of any product or business details. The list below served as our starting point.

For the backend:

• We will need to ingest data coming from different marketplaces, that might not have the same data model, might not be available in the same format, or might be exposed via a different technology (think Kafka, SQS, REST, and pretty much everything in between)
• All this data will need to be normalised into our own data model and stored
• An API will be needed to expose it

For the frontend:

• We will need a design system
• The application will need to allow marketplaces to augment it with their own specific functionality (microfrontends)
• We will need to support multiple languages and cultures (i18n and l10n)

And of course, we will need user management, authentication and authorisation integrated with our SSO, passing the tokens from the frontend to the backend, as well as the usual devops yak shaving: repositories, pipelines, CI, linters, tests, static code analysis and so on. So, as it turns out, we did know a lot about what we needed to build without actually knowing what we needed to build.

Getting beyond the whiteboard

The initial idea was to create a set of separated components, in isolation, each encapsulating a piece of functionality, and then plug them together later. But it didn’t go beyond the whiteboard. Too much overhead was required and there were too many components. With that in mind, it was clear: we needed a full-fledged application! Somehow…

So, what’s the simplest application one can build that might just serve our purpose? Just thinking out loud, we remembered one of the very first lessons we were taught when starting with coding and Computer Science — the Hello, World application. A straightforward piece of code, usually 5–6 lines long, which prints out the string: “Hello World”. Could we use something similar for our purpose?

How can we improve a Hello, World application? Simple! Make it bigger: add more worlds. And aliens.

We began by asking a basic question: how can we improve a Hello, World application? Simple! Make it bigger: add more worlds. And aliens. So the decision was taken — our Hello, World application would be a “Hello Worlds” one and it will print out messages from aliens residing on other planets.

Which takes us to the next question: how would one talk to aliens and how can we model that in our application? Looking around, there are two organisations that are already operating in this field: Search for Extraterrestrial Intelligence — SETI and Messaging Extraterrestrial Intelligence — METI. SETI uses large arrays of antennas to sweep the cosmos for any signs of intelligent life, while METI broadcasts such messages into space.

Of the two, METI receives the most criticism: advertising our planet’s location to more advanced and possibly hostile civilisations may not be the best idea we had as a species. So, we decided to model our application after SETI: listen for incoming messages, translate them and display them to the SETI researchers for analysis.

Time to make some assumptions:

• Aliens are broadcasting messages into space, each in their own language
• They will use different mediums to send and receive information, according to the technology of their respective planets
• SETI researchers will need a back office application to log in and see what messages have been received

So, our “Hello, Worlds” application would need to be able to receive incoming messages that might not have the same data model or might be exposed via a different technology, normalise and store them, and then expose the data via an API. Sound familiar?

Our application also needed to factor in strong authentication and authorisation, multiple languages and cultural aspects such as date and number formats.

Diagram of our first Hello, World scaffolding application

Piecing all these together, we ended up with a “product definition” that closely mimicked our real requirements, without actually going into any of the business details. Implementing it would provide us with a very strong foundation and allow us to tackle and solve a lot of underlying technical problems. All without knowing the details of the finite product. Pretty cool!

So, translating these into technical requirements, we ended up with:

• 3 dockerized apps running in our Kubernetes cluster, each representing a planet, broadcasting random messages, two using Kafka and one via REST. We called them Mercury, Venus, and Mars. Overall, not much effort went into these, as they would be discarded as soon as the product definition arrives
• A set of translator apps, one per planet, translating from the “alien language” into English, bundled together with a set of Kafka topics used to store the translated messages
• An app for each aforementioned Kafka topic, consuming the translated messages and storing them in a planet-specific PostgreSQL DB
• A Kotlin/KTor application called Libra, exposing the database content via a REST API
• A frontend application using React, MUI and Webpack 5 Federated modules, split across two repositories: one for the main app and one for the microfrontends
• SSO integration, with the token being passed by the frontend with each request and then validated by the backend
• Internationalisation and localisation using react-i18next and Intl while allowing the users to save their preferences between sessions

Together with the CI/CD pipelines and other ancillary tasks, this project would take about three months to fully implement. Pretty long for a Hello, World!

From “Hello, Worlds” to dispute management

Fast-forward three months and our “Hello, Worlds” scaffolding was up and running. By this time, our product owner had come up with the initial set of requirements for an MVP, so we just had to adapt what we had to fit the product definition. I will go through them one by one.

• User management: just rename the groups from “SETI researchers <planet>” to “Customer support agents <marketplace>”
• Backend and data model: update the mappings and database structure to the actual requirements. From there, the changes would be easily propagated in the API
• Frontend: update the designs to match the new data, but these were small changes, mostly adapting the HTML. Everything else pretty much stays the same in terms of routing, authentication, i18n & l10n

This allowed us to have an alpha version of our MVP quite fast. Of course, it took a few more iterations and polishing until we were production-ready, but we hit our deadline. We all celebrated our achievement together. It was an amazing ride, starting with an almost impossible task and ending with a successful release. Looking back, after the adrenaline rush has dissipated, there are some deeper lessons to be learned.

Now with live data from Subito.it and Milanuncios.es

First and foremost, working on our “Hello, Worlds” project helped us come together as a team. It forced us to understand our differences and find ways to collaborate. We had to agree on procedures and ceremonies, and define our process — something we did in an iterative and agile way. I can say that while we were working to prepare the ground for our upcoming Minimal Viable Product, we also defined our other MVP — the Minimal Viable Process.

Another important lesson was the value of true decoupling. This was refined by answering the same question thousands of times: “Why didn’t you just use transactions and disputes?” And invariably, the answer was that problems are easier to address once they’re boxed and isolated. Separating the product definition from the technical challenges allowed each side to work at their own pace, without causing deadlocks and entanglement. And it helped us avoid confusion: we weren’t taking any decisions that weren’t ours to take or stepping on the PM’s feet! We were building a Hello, World.

And the third lesson was what it means to build a truly modular architecture. We couldn’t hardcode anything, fix anything in place or make any assumptions. Everything had to be modular and adaptable; each part could change fundamentally without affecting the whole.

And I speak for all the team members when I say that while we worked on a variety of different projects throughout our careers, this one will be special. Hello, World!