EasyCep came to us twice. The first project, EasyHesap, started in August 2023. The second, Garaj, started in October, while the first was still being built. Through both, EasyCep's own operation carried on without pausing, which is the part worth explaining, because it is the question every company in the same position asks.
What follows is how the work was divided and what the second engagement changed. There are no performance figures here, because we do not publish numbers we cannot show the working for.
Key takeaways
- Two products, one client, no pause: The existing operation was never the input.
- The boundary was drawn around data, not features: Each system owned what it created.
- The second project was faster because the boundary already existed: Not because the work was smaller.
- Domain knowledge compounds; process knowledge compounds faster.
The situation
EasyCep sells mobile phones. Like most retail businesses of that kind, the operation ran on a mixture of software and spreadsheets, and the people who understood how it all fitted together were the people running it day to day. That is the constraint: the knowledge needed to build something new sat with the people who could least afford to stop.
The first request was a pre-accounting and stock system. Not an accounting package, which they could have bought, but something shaped around how phone retail actually works: stock that moves fast, suppliers and customers who are often the same people, and daily figures that have to be right before the shop closes.
How the first project was divided
The split was around data rather than features, which is the decision that made the rest possible.
EasyHesap owned everything it created: stock records, supplier and customer entries, the daily sales and earnings figures. It did not write into anything EasyCep's existing operation depended on. Where it needed to know something that already existed, it read it through a defined route rather than reaching into live records.
That meant EasyCep's people were needed for two things: telling us how the business actually worked, which no schema can tell you, and deciding what the first release had to cover. Both are decisions only they could make. Neither required them to stop selling phones.
The screens tell you what the product ended up being: a dashboard with the day's sales and earnings, stock tracking at product level, and one place for supplier and customer records. The last one matters more than it looks. In phone retail the same party is often both, and holding that in one record rather than two is the kind of thing you only learn by asking the people doing the work.
What changed on the second project
Garaj was a different product: a commerce build for guaranteed second-hand phones, storefront through to the operational tooling behind it. Catalogue, order flow, bundle pricing, and the back office that runs it.
It moved faster than the first, and the reason is worth being precise about. It was not that the work was smaller, and it was not only that we knew the domain by then, though that helped. It was that the questions that take longest on a first engagement had already been answered once:
- Where the boundary sits between what we build and what they run.
- Who decides an interface question, and how quickly.
- What "ready" means to this client, which differs from company to company more than anyone expects.
- How much of their time a fortnightly review actually needs.
None of that is technical, and all of it has to be settled before the first project can move at full speed. Settling it once meant the second project started at the pace the first one reached in its second month.
What we would tell someone in the same position
The thing that made this work was not a technology choice. It was that EasyCep's day-to-day operation was never an input to the build. Their people supplied the business knowledge and the decisions, which is irreplaceable, and did not supply capacity, which is the thing they did not have.
If you are looking at a new product while your own team is fully occupied, the question to answer first is whether that separation is available to you. It usually is, and the mechanics are in building a new product without pulling your team off.
Ali Boran Gazel