Our startup. How we started and what problems we faced?

In the previous posts we stated our willingness to tell you about everything that’s going on with startup, team and people. But if we start straightaway to write about current events, then posts will be detached from startup history. This post will narrate about the time when we actually commenced the buildozer project. And those posts capturing the period till February 2020 will be hashtag “History moments”.

In February 2020 we made a presentation for representatives of WKO Digitalization Department and State Architectural and Construction Supervision Authority (hereinafter SACSA — state agency having control functions in the construction industry). Our presentation conveyed the main idea of our buildozer startup. We dealt with the Digitalization Department earlier and received their support in the past. It should be well noted that the SACSA head got the gist and value of our system declared during the presentation. We agreed to meet again and discuss the cooperation details. SACSA lended its full support and handled the following issues:

• selected one facility at its early contractruction stage;
• arranged a meeting with the involved parties (contractor, engineering company and technical supervision);
• asked the involved parties to render assistance with the development of our system.

Prior to this meeting we highlighted that we need to develop the system’s core before its functionality implementation. SACSA head asked if one month would be enough and being tempted without wishing to refuse I agreed. I doubted much about one month and would like to have two instead. However, fear to look incompetent to SACSA head turned the scale to my agreement (don’t ever do that).

Following the system’s core development we along with SACSA reps and other involved parties should start to supplement the core with various functions. Direction for the service development would define our vision of the product as well as of the concerned parties — construction field employees. Among the latter SACSA staff, construction customer, construction and technical supervision contractors.

But we overestimated our abilities — two months of core development had passed when we realized that the application implementation path was chosen wrongly. It was based on the business process. This decision was made considering my experience in the first business establishment and turned out to be an incorrect decision. Having removed 60% of code written in 2 months we continued to work with another software architecture (architecture is an app skeleton).

During this period one time in two weeks SACSA reps contacted me to ask about our progress and possible time to demonstrate the results. In early May after a regular call I went to SACSA office and had a talk to its head. I explained the reason for the delay and promised that in 2–4 weeks the system core would be ready and we could go further. 4 weeks didn’t satisfy him and I assured him that it was the worst case scenario.

And I had some grounds for giving this promise. Once we got rid of the business process our work was progressing well. However, my expectations appeared to be much optimistic. App architecture was developed in such a way that any new feature we tried to add impacted onto the already available ones. So, basically, by adding something new into the app we could destroy something existent. The further we went more this was obvious. A half-a-day task could consume 2 days. We didn’t meet the promised 2-weeks deadline and hardly completed it in 4 weeks.

In early June I went to SACSA to notify about readiness to show the system core and work further. But in the course of conversation I had a strong feeling that our credibility as trustful partners was undermined.

One more problem appeared during that talk was another information system — e-Qurylys being currently under development. And this system was implementing the tools SACSA required.
This ended up in weakening of our startup position — the attitude towards us evidenced this. While earlier we saw interest and got active questions in the course of development, now we felt coldness and mistrust. At least, it was my interpretation I got during further meetings. For SACSA we no longer were an innovative startup offering top-class solution in the construction industry, but a lag-behinder with cloudy prospects.

All the subsequent days were very hard for me. The growing anxiety drained energy and prevented me from focusing on the problems solving. The problems must be tackled, they wouldn’t disappear.

Our team should address 2 main, we might say, global challenges of our startup:

• Unstable process of the development and architecture issues settlement that caused a delay;
• To determine the position of our product at the market considering the implemented e-Qurylys app.

We fully understood that having left the system problem in the development process we most likely wouldn’t meet the deadlines and the development itself would slow down. There were 2 options to choose:

• To work out what we have already done.
• Benefits: At last we will start some features realization along with the construction industry participants;
• Drawbacks: The main pain points in our work are left unsolved — failure to meet the deadlines and unpredictable outcomes. If we keep the app architecture then we could end up deadlocked. If we change the architecture along with features, it will affect implementation time.
• To handle the problems with the development.
• Benefits: We’ll create a more sound architecture, consider what and where we could improve in the development process. All this should lead to a more stable development period and product quality.
• Drawbacks: We have to start from the scratch. Nobody could guarantee that the changes will solve our problems. We have to put functionality development off.

What we have chosen and how wanna address our global challenges? I’ll tell you in the next posts.