Solving the development related problems of “buildozer” startup

In the previous post we told you how we got the problems and from now on we’ll write how we are trying to solve them. The development process problems and architecture related issues will be the first to tell about.

Disclaimer:
All the events depicted in this post are real and our team has actually gone through them. Any similarity to the event in other teams are purely coincidental:).
Well, joking aside, the idea of this disclaimer is just to let you know on a long text below narrating about our efforts to tackle the problems and become more professional developers. Next para will contain a brief insight into the post and you will decide if this story about our adventures is worth your 20 precious minutes to read it.

In short, in order to address our problems we decided that the simplest and quickest way out is to hire an experienced specialist for a technical director’s role. Failure. Then we decided to outsource the core development and again found ourselves being losers in this deal. But at the same time we discovered that we could improve our product much. Yet our actions brought not only painful experience, but new knowledge as well. And if we could improve, ‘why not’ — so, we started to work out a new architecture. In fact, I think no need to read further.

So, the story itself. (I’m taking the smile off and trying to be serious).
The essence of the problem is loss of credibility from the stakeholders, primarily SACSA reps. Drawn-out development and delays caused this mistrust.
To sum up, what problems revealed in the course of analysis:

• mistakes in the app architecture design;
• inefficient development process;
• work with a new technology, which team hasn’t experience with;
• increased complexity of the code initially aimed at ensuring easy scaling into other apps.

When our system core was ready we faced another problem — difficult interface for end user. In such cases it’s said “Interface is not intuitive”.
As you can see, there are a lot of painful issues. Each of them contributed into failure to meet the deadlines and all these problems could be covered by one statement: “team doesn’t have proper practical experience in delivering such a large and complicated system”. On the other hand, those mistakes and faults could help in gaining the practical experience, right?
When developing MVP (Minimum Viable Product) we didn’t set a target to have an ideal system — it’s a standard practice for MVP. We developed the core, which worked and was fit for extending its functionality (within MVP targets). We could continue to work with the current system. That time two intents started to fight inside me.
On the one hand, I wanted to proceed with the available code. It would enable faster targets achievement and new functionality implementation. But we had an understanding that it would be hard to work maintaining a high level of pace.
On the other hand, I wanted to step back and address some issues. It meant to put the product targets achievement process on hold. I couldn’t stop asking myself what if to start the product development from scratch.
As a team we decided what to change in the current state of the product so as to continue the growth. The discussion brought an idea to hire an experienced developer on a man-hour payment basis. He/she could be a go-to person when it comes to difficult-to-answer questions. Later this idea was expanded to have a technical director with part-time involvement. Yeah, it was a quite good idea to work out.

Decision was made to scout this specialist at Habr — platform, where IT and other geeks are hanging out. After some study of the topic I posted a job vacancy at Habr-career setting the requirements. 4 candidates expressed their interest. 3 of them contacted us — we conducted an interview via skype. Our choice fell on the most expensive candidate. As a result of the interview he was fit for purpose and inspired trust with his qualification. This candidate occupied the technical director position. The whole power in development passed to him.
The candidate was rarely available for a contact: sometimes it took several days to get in touch with him through the messenger that caused stand by. Our expectations were not met. Then we decided to look for another candidate. Found, but again there was a problem with connection — we failed to complete the preliminary agreement stage, to say nothing of cooperation. Below are the results of our desperate attempts to hire an experienced specialist:

• Many people express their interest for a job vacancy;
• You could find specialists inspiring trust in the course of interview;
• Candidates didn’t feel responsibility and had no intention to get the results for a startup;
• If this candidate occupies a technical director position, then 100% of the work depends on him. 4 developers sit the whole day doing nothing valuable and the same day after day;
• There were the candidates expressing true interest in our project and willingness to work, but they failed the pre-screen because of insufficient to our mind experience;
• Lost more than a month and achieved a bit more than nothing;
• Most probably we could find such a candidate meeting our requirements in terms of experience and who will be engaged into the product targets realization. But time for headhunting and probability of that option were scaring;
• During the interview we discovered much new and useful for the project. So, the interview could be considered as a source of knowledge.

Though having no result, but some new knowledge and experience, we decided to change our strategy. We agreed to focus on the most painful points of our job: on user interface and in parallel to work on frontend core (frontend is a programme on your PC or in other words, what you could see). For that purpose we needed to hire an experienced frontend-developer and outsource, i.e. subcontract this part of work. Tasks for a candidate:

• to develop a frontend core;
• to improve user interface;
• to develop the core along with our developers sharing experience and knowledge;
• at the end of the work our developers should know how to proceed further.

The order was placed at Habr-freelance. We selected 5 candidates and conducted an interview with the team. It was a hard choice — we dropped on the contractor, which made a decent overview of our current status and pointed out the things to work on. The target was set — core development. Budget was defined — 40,000 rubles (≈570$). Timeframe — 10 days. Go on! From the very beginning the work progress was tangible: the contractor determined the targets to work on and how our developers would be involved. Following the work start we supplemented the requirements with new items:

• core must not be directly linked to the current design and user interface;
• core must support the product and mobile version of the app.

Having set the new requirements we wondered how it would be implemented. The contractor gave well-structured and clear responses. But it led to increase of the project cost to 60,000 rubles (≈860$). I liked much this format of the work and we decided to use the same approach for backend (backend is a programme working at the server where data are downloaded from). It shall be noted that our further work went in two parallel independent streamlines. To know how the second streamline progressed, please go to Section “Backend line” of this post.

Well, let’s continue with frontend

A week later I faced a problem — my bank accounts appeared to be blocked by Tax Authority.
I’m building a house and in spring I brought the construction materials for sound insulation from Russian Federation. The Tax Authority thought I bought these materials for further re-sale though the cost of the goods was ridiculous for commercial purposes and the aim of transportation was clearly stated when transferring through the borderline. Apparently my individual enterprise confused the Tax Authority so they decided to conduct an investigation and get evidence of personal use or otherwise collect relevant tax charges. I had to run about, collect documents, make photo of my house to justify that it was really under construction and those materials were used for this house. It took more or less 10 days.
Once my accounts were frozen I liaised with the contractor to explain the situation. It was decided to hold on the works until the problems were solved. At that time misunderstanding showed up. The contractor during our last conversation meant that the additional functionality would cost extra 60,000 rubles, while my understanding was that 60,000 rubles — overall amount. In total, it costed us 98,000 rubles (≈1400$). It was upsetting — agreement with discretionary interpretation was obvious. According to the contractor’s verbal report there were 2 days left till work completion. We decided to put the work on hold due to financial debt.
Upon tax issues settlement we contacted the contractor and paid off the debt. We agreed to continue the next day. And then everything changed: the contractor ‘went silent’, when eventually was conducted, made promises, but disappeared again. During regular call the contractor complaining about the difficulties asked for an advance payment. The advance payment sum almost closed the deal — 15% out of 20% remaining for payment. After some thought with full understanding of all the risks I transferred money. After that the contractor appeared a couple times, then vanished. Approximately 10 days had passed since I solved the tax issues.
Then the light came on — I got cheated. While awakening I asked the frontend specialists about the scope done. When it was found to be 20% in the repository it shocked me.
The contractor developed the code with reference to the core (peripheral code) — using it our guys started to develop interface elements. Further the contractor dealt with the core alone. It was turned out that the code hadn’t been saved in the repository. Most likely because the code was incomplete and still under development. That’s why we ended up with 80% of code for the periphery and 0% for the core, 20% in total. I was very disappointed, whereas the beginning was so good (well, in my imaginary world).
Oh, what a loser I am! Why am I so naive? When could I control the work? This was my first pained reaction followed by a thorough analysis.
So, let’s begin with the results:

• 94% of works are paid — 92,000 rubles (≈1315$) out of 98,000 rubles (≈1400$).
• 20% of code is received, while 0% of important part.

Not much, debit and credit are not in our favour.
Experience and knowledge we obtained:

• need to set technical specifications or at least divide the whole scope into phases and fix in writing. To link timelines and payments to these phases. This way of working will enable control over the development process;
• need to structure the work with the contractor in a transparent manner for the whole team including the financial side. We selected the staff jointly with the team, the main task requirements were also given jointly with the team, whereas the financial part moved to the personal correspondence between me and the contractor. Team chat with the contractor was maintained only for technical part. I didn’t know what code the contractor transferred. Team didn’t know how much we paid for the work. Consequently, we couldn’t know that the code we received in the repository and money paid were not equable;
• additional requirements should be set along with the team to keep everybody aware of the agreements. The conditions should be fixed in written form detailing the project financial part and terms;
• what was positive in this case — frontend developers gained much new knowledge in app architecture. Majority of the problems revealed and though we hadn’t got the full picture of the future core, but main outlines became clear for our frontend specialists.

All the normal people follow the aforesaid principles, but it’s not about us:). Having spent such an amount of money and time we got experience and new knowledge in architecture and thus decided to develop the frontend core further by ourselves.

Backend line.

Here you will find the narration on events in the backend streamline occurred in parallel with frontend. For backend we also decided to involve a developer from outside. We needed an architect assisting us with architecture development. We wanted to develop the main feature set by our own resources, while the architect should develop only the framework and give us the tasks and probably develop the most crucial parts.
We posted another job vacancy at Habr-freelance — many candidates expressed interest. I selected 2 of them with considerable experience of work in the big companies. I chatted with one of them and he appeared to be not suitable from the financial perspective. We conducted an interview with the second candidate. Failure again. However, it was an interesting interview — this candidate asked a lot of guiding questions. The thought provoking questions, giving right direction for our own ideas. At the end of the interview he suggested to read “Clean Architecture”, a book by Robert Martin.
Without reading this book, but as a result of this interview we already saw what we could work out and improve our app architecture. In fact, a new architecture would undermine all our work done since February. It simply meant that we have to throw 100% of available code away. Of course, some part could be used, but this part is negligible. The architecture restructuring was considerable.
It was decided to start the product development based on a new architecture. Why we made such a decision? Let’s do an analysis:
Benefits of new architecture development:

• We will gain practical experience realizing theoretical knowledge got out of the read books;
• The received practical experience of the new architecture implementation will open the doors for new knowledge and experience in the future;
• We will achieve stability in the product growth timelines. The main goal of the “proper” architecture is maintenance of the constant speed of the development process;
• Our team will considerably improve its professional knowledge and experience and this in its turn will be a good base for achievement of the long-term strategic targets.

Drawbacks of new architecture development:

• There is no guarantee that the new-built architecture will be successful. But it’s already obvious that this architecture is a way better that the current one;
• There is a possibility that in the future when we pass MVP development stage and proceed with main functionality, the architecture will change again and all our efforts will be invested in vain;
• Voluntary return to the scratch will cause a big delay with the product targets;
• Probably, there will not be enough resources to achieve MVP targets.

Benefits and drawbacks are equal, especially considering the last negative point. But my perfectionism makes the choice apparent — we will develop a new architecture. Just to add a bit objectivity let me share with one idea navigating me:
We are working on digitalization in the construction industry. It’s clear for everybody that this sphere is complex and grand-scale. When we started to work on this product we realized seriousness of the whole task as compared to site page or big internet shop development. It is the scale of the task that defines the seriousness in the approach to the architecture issues. I have an absolute certainty that all the resources and time for a new architecture are reasonable. I’m sure in other circumstances I could quite objectively make another decision, for instance to work on optimisation of the current solution.
It was easy to involve the team into the new core development — the team considered this decision reasonable and agreed without any questions. As a result, in the mid of September 2020 we have being worked on the new architecture for a month.
This story could be analyzed from different perspectives and most likely I’ll return to this stage of our startup development in the future posts. For example, this phase has been marked with personal growth spurt for me as a startup founder.
With this I’m closing the review of the actions we took to solve the development problems. While writing this post I was balancing between two extremes: not to make the story long with odd details and at the same time give you full information on what happened to startup and the team and what influenced our decisions. I hope I succeeded in this at least a bit.
Next reviews on this topic will be made in real time regime.