When Software Becomes a Business
MyEasyTransfer started during the first months of COVID-19.
Around May 2020, the pandemic was exposing problems in systems people had previously accepted as normal. One of those problems was money transfer.
My cousin, an engineer with experience in the banking industry, noticed that when families sent money from abroad to relatives in Tunisia, recipients could still have to wait in long queues to collect it. During COVID, those crowded physical processes became even more difficult.
He saw an opportunity.
The idea was to allow someone living in France to send money to Tunisia online, while the recipient could collect it through a network of partner shops in their city.
He contacted me and asked whether I could build the web application. I said yes, with one clear separation of responsibility: I would design and build the product. He would handle the legal, regulatory, banking, and partnership side.
At that moment, I thought I was agreeing to build a web application.
It eventually became much more than that.
Turning an idea into a product
The first challenge was not writing code.
It was understanding exactly what we wanted to build.
“Send money from France to Tunisia” sounds simple when expressed in one sentence. The real journey contained many questions: who is sending, who is receiving, how the recipient is identified, where the money can be collected, and what happens when something fails.
Most importantly:
How do we make all of this feel simple to someone who does not care about the complexity behind the system?
I started by creating mockups. Before going deeply into architecture, I wanted to see the product and understand the complete journey. I iterated from the user's point of view, simplifying steps and trying to make the flow as natural as possible.
These early mockups were how we started turning a conversation into a product.
Designing the journey before solving every constraint
Very quickly, we encountered one of the fundamental tensions of financial products. The user experience needed to be simple. The system behind it could not be.
We were dealing with money. That meant identity verification, KYC requirements, regulation, payment flows, external providers, and other constraints. If we tried to solve every problem at the same time, it became difficult to see the product clearly.
So, during the first iterations, we deliberately designed the global user journey without allowing the KYC process to dominate the entire experience. This did not mean ignoring compliance. My cousin was exploring partnerships with specialized companies capable of handling parts of the KYC process.
Temporarily isolating that complexity allowed us to answer a more fundamental question first: what should the experience of sending money actually feel like? Once the main journey was clear, the required compliance and integration constraints could be introduced around it.
When several kinds of complexity are mixed together, sometimes the first step is not solving them. It is separating them.
Building the first version end to end
There was no existing product team, no designer handing me completed screens, no architect defining the system, and no DevOps team preparing the infrastructure. The starting point was an idea.
I created the mockups, designed the logo and the first visual identity, built the backend in Node.js and the frontend in React, and handled architecture, deployment, and monitoring.
Decisions across the product were directly connected. A UX choice could create a backend requirement. A business constraint could change the architecture. An integration problem could force us to reconsider part of the user journey.
Around December 2020, the first version of the application existed. For the first time at this scale, I was experiencing the product as one connected system rather than a collection of engineering tasks.
The difficult part was outside our codebase
Getting the application working was only part of the problem.
For the service to actually transfer money, we had to integrate with companies that already occupied different parts of the financial ecosystem. We spent significant time on the KYC provider, and on other partners involved in the money-transfer process.
Inside our own codebase, we controlled the architecture. Outside it, we depended on APIs, requirements, processes, contracts, organizations we did not control, and a large amount of regulation.
That gap was not abstract. The first version of the software existed around December 2020. Money could actually be transferred around December 2021. A year sat between a working application and a working service.
UserMyEasyTransferKYC providerTransfer partnersLocal collection networkRecipient
The product existed only when the technical system, the partners, and the operational process worked together.
Building something that could continue without me
In June 2021, I prepared the codebase and documentation and transferred ownership to my cousin. He recruited a developer to continue the product. For a period, I coached that developer through the codebase, the architecture, and the reasoning behind some of the decisions we had made.
Building something yourself is one challenge. Building something that someone else can understand, maintain, and continue is another.
After that, I was mostly outside the product. I stayed in the conversation through occasional advice. My cousin developed the marketing side of the business. The team continued the product, and a mobile application was created.
The product did not end when my contribution ended. It became independent of the person who had built its first version.
From one corridor to a growing product
The first idea was narrow:
France → Tunisia
Then real people started using it. I became one of those users myself. I sent money to family in Tunisia and saw the collection process from the other side of the journey, not as the person who had built the first version, but as someone trying to get money to relatives.
Over time, the service expanded beyond the original corridor. Additional European countries became sender markets. African countries such as Morocco and Senegal became additional receiver markets. The company recruited more employees. The mobile product continued evolving.
What began as a conversation during COVID became a company capable of continuing the product independently.
IdeaProductUsersTeamExpansion
The lesson I did not expect
Technically, MyEasyTransfer forced me to connect design, architecture, infrastructure, external integrations, operations, and user experience into one product.
The most important lesson, however, was not technical. Once the application existed, I started to understand something engineers can easily underestimate:
Building the software can be the easiest and cheapest part of building the business.
I saw that most clearly in conversations with my cousin as he took on the marketing. The competition was aggressive. Getting customers to trust a money-transfer product, especially at the beginning, was difficult. Keeping them, so they would not leave for a competitor, was even harder.
A technically strong application does not automatically create demand. People still need to discover the product, trust it with their money, and keep using it.
Engineering question
Can we build it?
Business question
Can we make people discover it, trust it, use it, and keep using it?
Software can create the product, but it does not create the business by itself.