What architecture will be, from a business point of view, is not so important. It will be fundamental in the case of a highly loaded portal, where there are a lot of connections and transactions with a huge number of visitors at a time. In the case of our oil service, there are no questions about a serious load and high speed of user interaction, which allows the implementation of additional functionality to an existing site that will be needed to work with a mobile application.
The car oil service has one more nuance: in addition to the functionality that they already have, an additional one is expected in the mobile application. Therefore, it is necessary not only to connect the application to the site, but also to make certain modules on the backend side, in Bitrix itself, for the operation of a full-fledged mobile application and new goodies.
Adding live
We have chosen a situation where a block of necessary modules is added from the side of the site, and this whole thing communicates with the application via the REST API. With 1C, we do not cling to the application, using what the client’s full-time developers have already done: we change the current system to a minimum so that they can continue to adequately support their own infrastructure. Something for the application to work will still need to be rewritten, but not more than 5% of the total infrastructure.
The server part will consist only in the fact that we are adding a separate REST API module to their current infrastructure and the necessary additions that are not on the software. Thus, we kill two birds with one stone:
The admin panel remains simple and understandable for each user,
We create a minimum of problems for the client’s programmers.
The second point is often missed during development: when a new team joins an existing team, friction may arise, technical directors instead of work begin to argue, swear, measure their knowledge, and this does not end very well for business.
I am a strong supporter of the idea that when two teams work together, there should be a strict protocol for working in modules that both teams have access to. For example, our new functions will lie separately, without overlapping the existing functionality: there will be joint work with git, and no one will swear at anyone, as happens in joint projects.
The private story above is a typical example of how a business grows from a classic corporate website first into a kind of automatic service, and then it hatches into a mobile application with a set of functions that the client needs. Very often a mistake is made when everything that has gone before collapses and is rebuilt anew. This does not protect against new mistakes, but it increases the time and costs.
The described case is a vivid example of how it is possible to develop a working scheme not “according to the textbook”, spend less money, time and nerves, and with a similar quality result. This approach is cost-effective, convenient from the point of view of the business process and easier for the developers themselves.
Zerocoding Tools
Today, there are more than a hundred different zero-coding tools*, and when I was faced with the task of choosing a toolkit, I did not seek to study all available ones, but decided to look at those that are heard (or language, keyboard keys) by those who have already plunged into it direction ahead of me.
- links to several reviews: one, two, three
Over the past six months, I have used the following zero-coding tools:
Glide – mobile app builder
Adalo – mobile app builder
Airtable – database, spreadsheets
QuintaDB – Database
Itegromat – data synchronization between different parts of a common IT solution
Zapier – data synchronization between different parts of a common IT solution
Sherpa RPA – software robots for automating routine processes
Quickly studied:
Bubble – app builder and database
Stacker – personal user accounts
Criteria for evaluation
What was critical for the final choice:
Ease of entry and use – the last six months, development has fallen on me. My experience in development was very small and managerial. From programming, I generally studied only Basic at school.
Cost of use – for a startup at the Pre-Seed stage, the available investments are always at a minimum, and most of the tools can only be fully used at paid rates.
Completeness of functionality – minimization of the overall stack of IT solutions.
Briefly about the project
Neighborhood Events is a search service for local leisure activities and events in the user’s location.
From the development side, this is a fairly loaded technological information service, which is based on a relational database and a number of user interfaces, both mobile and web.
How we went through the traditional MVP development path
At first, we followed the traditional path for a technology startup:
From idea to product concept development.
We checked what problems we can solve with our product through custom development: we took a series of interviews and surveys of a potential audience.
Researched the market for its potential, players, business models and competitors.
We defined our own product hypotheses and business models.
We developed the first conceptual prototypes in Miro and Figma.
Prepared terms of reference for development and UI/UX design in Sketch.
Developed MVP by a team of developers on React Native (programming environment).
Made the first publication on Google Play.
First version MVP
It took us 7 months to complete these stages and we were already ready to solve a pool of tasks directly related to the pilot launch of the project. But then the first lockdown happened in March 2020, and the whole topic of offline events became irrelevant for a long time, at least to launch a pilot and test the reality of all our key product hypotheses.
From that moment, our throwing began, which led to multiple errors and a waste of time for the development team. We decided to switch to the direction of online events – the topic is close, the products are similar, as it seemed to us at the start of this pivot. But the main thing was the feeling that it was necessary to do it quickly, while the interest around the “online” topic was only maturing, and no one had yet released an intelligent search solution in this niche.
And instead of going through all the points listed above sequentially, we began to do everything in parallel, and some points were skipped or passed superficially. Vanity is always the enemy of the valuable.
Eventually:
They exhausted the development team: they began to change the product on the fly, without a sensible technical specification, using the labor of programmers for experiments.
We immersed ourselves in the topic of online in parallel with the development, and when we finally somehow fully mastered online events, it became obvious that neither the end user nor the author of the events could simplify life with such a product.
Three months later, the race burned out all. We conducted new research on the online events market, which confirmed doubts – it became clear that we needed to return to the original idea of the product.
What has happened so far:
Lost the development team.
Lost time.
Opportunities for investing our own funds have become more modest – we only spent on development and got off lightly: we worked with a friendly development team, and our MVP evaluation was by market, without all subsequent adjustments related to the topic online.