Dodo Pizza is an international company - we operate in 13 countries and are not planning to stop. Most of the pizzerias are located in the Eurasia region: Russia, Kazakhstan, Belarus, Kyrgyzstan, Uzbekistan. This is already a large operating business, we are leaders in the number of pizzerias. This business only needs to be supported and developed in depth, because here business and IT work together on understandable features.
- .
- .
- .
- .
- : , LTV .
And then (suddenly) a business comes in and says: “We want to start in Nigeria,” in the same 13th country in which 2 pizzerias are already operating. Until 2019, the launch was rare - 1 country per year. The development team that accompanied the launch was constantly changing. There was no focus on acceleration with this approach.
It is not clear whether the new country will "shoot" or not. Who will launch the country? What product will you have to take a team from? The “lucky” team will have to distract from their killer feature, remember how to deploy the system and face certain difficulties. Let's figure out which ones.
Startup difficulties for a business
The discovery of a new country is a surprise (maybe). Sometimes there are opportunities in entrepreneurship that simply cannot be missed, even if you are not ready. For instance:
- a strong partner has appeared who is ready to take risks;
- a strong local player leaves the region;
- the partner was looking for, looking for, looking for and suddenly found a dream premise;
- after an international business trip, we realized that we could no longer postpone and that we urgently needed to launch the country.
We try to plan openings in advance, but sometimes life makes its own adjustments.
Single launches. When launching one country a year, it makes no sense to keep a dedicated team. The development team that launched the last country left to cut another killer feature.
When the turn comes to open a new country, all checklists are out of date, and the team that launched the last country can only help in fits and starts. There was no focus on speeding up system startup with this approach. Launch and okay - we'll be back in a year :)
Razfokus.Due to single launches, the development team that will deal with the new country will have to break away from the killer features for Eurasia for dubious benefits in Europe or Africa. A new country, the first pizzeria, the investment will pay off in 1-2 years - a lot can go wrong.
Many components, a huge system and many connections - there is no built-in launch system and experts. Launching a new country, from the point of view of Dodo IS, is not just a copy and paste of the code or pressing one magic button. This is a separate project with its own local characteristics. It takes 3-4 months to launch (sometimes longer).
Each country needs its own expertise, for example, on the check fiscalization system. To integrate with local systems, you need to know the specifics in address systems. For example, in Slovenia, the client's surname is part of the address that needs to be taken into account in customer services.
There are many similar features, and our team certainly does not have all the knowledge on them. This means we will distract people from the other team who have expertise - addictions, for a long time.
Technical difficulties
Dodo Pizza was launched in April 2011. In June 2011, development began on the Dodo IS. At that time, no one even thought that soon we would be launching pizzerias in other countries, because it was necessary to quickly (very, very quickly) support the growing business in Russia. For example, the first checkout of a restaurant appeared in the system in 2 weeks of development, since without it it was impossible to open a restaurant in the first pizzeria.
There was no time to think over everything and put scalability and country-agnostic components into the system architecture. The last thing we thought was that the code we are writing now would be used somewhere in Slovenia or the United States. Therefore, over the years of rapid growth, a lot of technical debt has accumulated, which is now slowing down the launch.
It takes a long time to deploy the website and back office of Dodo IS... You can't just take and register a domain for a new country in the Nginx configs and deploy the system by clicking the button. It's a pity.
Besides, each country has its own specifics. It is necessary to give the partner a product that will be suitable for a specific country, and not just a "general Dodo IS". Starting with the adaptation of address formats, telephone numbers, types of streets and settlements, organizations, and ending with more global adaptations. Add to this a lot of manual operations and copy-paste by code: enums, configs, scripts.
Translations into the language of the country . We all love Excel: build tables, color lines, write complex formulas, refer to data from another document. This is what it was designed for.
In Excel, we uploaded lines with terms to the partner, he translated (without context and pictures), we loaded Excel with translations back and repeated the exercise. This is not what Excel was created for. Yes, and the resources, unfortunately, did not contain all projects and lines - the code had to be edited.
An example of a file with translations.
In addition, after the launch of the country, new features appear in the system - teams for Eurasia do not stop writing features while we are rolling out the country. For these features, translations are needed and again in Excel. Long, expensive, inconvenient. You can't do it without developers.
Cash desks and taxes... Restaurant checkout and delivery checkout are components of Dodo IS. Without them, nothing can be sold either in a restaurant or for delivery. Checkout needs to be adapted for the new country, and the code is in a monolith and it pulls a lot of dependencies. It turns out, in addition to business development (taxes, rates, requirements for a check), it is necessary to carefully write the logic for the new country, so that the printing of checks in Russia does not break.
Mobile application . We did not know how to launch it immediately with the opening of the country: there was not enough expertise, time, everything. The partner sometimes had to wait six months (sometimes longer) for us to launch the application after the country opened . It's unpleasant.
Note... There is one application for all countries - the situation is like with cash registers. When launching an application in Romania, it is important not to "hook" other countries.
Launching is also support . Landing pages, kitchen alert sounds, translation errors - all these little annoyances usually show up in the first couple of months. Therefore, after the launch of the country, support is also important.
How we solved business problems
We were in such a situation in May 2019. And 2020 promised to be hot - we wanted to launch 4 countries at once. I had to do something in order not to screw it up.
We have singled out a new independent product - “launching new countries” - and set an ambitious goal - launching a country “on the button”. With a button, we could:
- deploy the system as it is;
- , : , , ;
- , -, .
Command. The goal cannot be achieved without a team. Therefore, in May 2019, the MyLittleCoders team agreed to become the country discovery team 100% of the time. We have highlighted the opening into a new product: there is a “launch speed” metric, there is a team, the acceleration backlog is full of overflowing tasks. It all came together - it's time to act.
MyLittleCoders (MLC)
Story Map team logo . The long-term strategy is clear: to accelerate, look for people, adopt competencies. It was necessary to learn how to "launch the country on a turnkey basis" independently, without distracting other teams.
We started with the launch of Nigeria, 3 months before the opening. Nigeria became a test country from which they began to systematically build a clear launch process. And this is how we did it.
Aside from our main goal of launching a pizzeria in October, we recorded the most time-consuming things to come back to after launch. After the launch, we built a story map and, according to observations, noted the things that take the most time.
Fragment of the story map of the launch of a new country.
How we solved technical problems
Initial Country Setting Wizard. Analysis of the story map showed that some of the stages can be automated, which will significantly speed up the launch. Therefore, the first significant improvement was the Country Wizard.
After buying a new iPhone, the settings from the old phone are transferred in a couple of clicks - 3 screens and the new phone is ready to work. We wanted to do something similar for Dodo IS.
- Run the country initialization wizard.
- : « ».
- , , , .
- ( ).
- Next, next, next — - .
In the course of the work, the concept changed. Initially, we wanted to add all the system settings to the Country wizard (the product RO wanted and dreamed of, the team was restrained and optimistic). But we already had an internal admin panel, which was pointless to duplicate in the setup wizard. Then we left in it only that minimum of settings, without which the system simply could not start. Products, menus, supplier prices and packaging can be adjusted later.
Why can't the system start without so many parameters? Historically, such parameters were required for the development of the Dodo IS. It is a separate task for the team to decouple such dependencies and make them optional for launch.
In the end, everything worked out great. Instead of many places where you need to edit something, we:
- go through 1 initial setup wizard;
- get a fresh system dump;
- we give it to the guys from the infrastructure for rolling.
Two days (and not a month as before) - and the system is ready to work.
An example of configuring delivery parameters using the Initial Configuration Wizard.
Launch checklists. It is not always possible to achieve acceleration only through development and automation. Startup checklists are an example of this. Sometimes it is enough to describe in order what and for what needs to be done, where to click, whom to kick, which script to roll.
Therefore, the analyst-developer team meticulously described the entire process. As a result, we have a large document with numbers and points: what to do before launch, what during, and what after.
Fragment of the launch checklist.
Recycling old checklists is a fun process. The developers took turns walking through the checklists with their hands, opening and setting up test countries, collecting pains and improving the checklists. And so several times. The bonus of this approach is the deep immersion of the guys in the system itself.
Country settings from one point . Collecting all the settings from the Country wizard is not enough. It is important that the system and its components also read these settings from the same repository. Otherwise, funny situations turn out. For example, when the office manager shows the correct currency (for Nigeria, naira), and the showcase of the pieces treacherously shows rubles. Each service considered it its duty to create its own settings. We had to go through 7-8 places in the system so that everyone finally showed the correct currency.
I wanted to edit the settings in one place and then apply them throughout the system. In reality, we are faced with the need to make changes to almost every component in the system. The changes are small, but there are a lot of components.
Through the titanic efforts of the team, 100,500 lines of remote copy-paste and a pinch of programming magic, the system now takes settings from a single repository. The "tails" still remain, but most of the settings were centralized. Now you can set a phone mask or address format or other settings for an entire country in one place.
Note . The story of how we cut out copy-paste for a long time and translated the system to use the directory service deserves a separate technical article. If interested, write in the comments.
Translations. Instead of Excel, I wanted a simple and understandable system for localization, so that:
- there was no need to upload anything to third-party files;
- receive notifications that a new translation line has been added;
- it was clear which lines and in which language have not yet been translated.
We looked for localization services, talked to support and settled on the Crowdin service . Simple, with a differentiation of roles - came up like a glove. I especially liked the in-context feature: when we open a website or back office in a special environment and edit the lines right in the interface. So you can immediately see where and what exactly we are correcting - convenient.
Crowdin in-context editing.
Crowdin was connected first to the back office, gradually connecting the monolith, then the sawn-off services, and then the website. Not everything worked right away, but now it is enough to add new lines for translation so that the partners can see and translate them themselves.
No more Excel.
All localization has been simplified: the partner can now make translations in advance and without the help of developers. So when we're ready to roll out Dodo IS and the site, the translations are usually ready.
Previously, translations were in code - the translation business process was forcedly linked to development and releases. Thanks to the Crowdin service, it turned out to make these 2 processes independent. Now we are trying all new services, landing pages and wherever there is something for translations, connect directly to Crowdin. This greatly simplifies life and gives the partner the opportunity to make translations at our own pace, and we deploy the system at our own pace.
As a bonus, set the system language to English by default... Previously, the system used Russian by default, which is not suitable for international partners and their employees. Now, if some translations are missing in the system, the partner will see the English texts. This usually happens immediately after the system is deployed.
What is the result
Since July 2019, we have done a great job - we have built a launch system and added structure to the entire process . We set up the system through the wizard, the partner translates the interfaces independently and does not depend on the developers.
The whole path of rolling out a new country is described in detail . Now the journey takes 2-3 weeks, instead of 3 months earlier. A week after the start, the website and back office are open. They are not yet filled with data, but they can already take orders.
Plans
Add about the same amount - everything that is above is not even half the work. Now a new challenge awaits us - gradually, step by step, country by country, to improve this system. For instance:
- gradually expand the "launch package", adding new features there, for example, "Site for work in Dodo" or "Site for mystery shoppers";
- add multilingual support on the website and in the application;
- Simplify the Initial Country Setup Wizard even further;
- add a system of plug-ins for checkouts in order to attract local outsourcers to develop a check printing module for a specific country.
Application . Since January 2020, the Legionnaires mobile team (3 people) has joined us. We plan to "distribute debts" - to launch the application in all countries, and learn how to launch new countries immediately with the application.
Checkout integration . Now this is the longest stage of the country's launch - we plan to accelerate it. We plan to cut the cash registers (the logic for printing receipts) from the monolith, move it to a separate service and make a plug-in architecture there. This way we can involve third-party teams to develop a plugin for a specific country. For example, an outsourcing company in Poland will do a cashier integration for Poland by writing an appropriate plugin. This will allow you to speed up even more.
Finally
Launching the country is half the battle - now you also need to support the existing partners (which have just become one more):
- UK;
- ;
- «» «» ;
- .
In addition, there are many hypotheses, requests for development from existing international partners. These requests may not be interesting for Eurasia, where the market has already formed, but relevant for Europe, where we are just starting to grow.
That is why we are assembling a new team for the EMEA region. This team will adapt the system to local markets, creating the very uniqueness that distinguishes business in the UK from business in Nigeria. We are looking for experienced developers to join the team. If you are interested in discovering the world, launching new pizzerias on the map and solving non-routine tasks - we are waiting for you to join the team. Write to me at d.pavlov@dodopizza.com - I will be glad to talk :)
Note . In the post, Katya Landyreva described in more detail what awaits you a bit and why it's cool to work in our product.