Through years of work with different types of clients, we genuinely appreciate the experience when we implement the product from scratch, having just a client’s idea and till production, seeing how this client raised investments and reached paid clients.
However, all ideas are like gasoline, which still needs oxygen and spark. That’s why it is so important to try not to give up. This motivation article is about one of our projects, its failures, our learnings, and final success.
Successful start and significant failure
Each particular client who joins Jappware is our friend. This time was no different, the kickoff stage went well, requirements were clarified, and solutions and roadmap were offered. All was ideal except a very typical point – pretty old technology for the front end. Yes, the client already had a PoC version, and, of course, he preferred to continue work from that point. Today we would stop it, do our best to show different edge cases and pitfalls, etc., and prevent the usage of old or deprecated things, but at that time, we agreed to use what was offered. Do you think that’s all? Nope…
4 months – this is the exact time that was spent to discover many other issues in the existing solution that was used as a common and fundamental approach. The not flexible and not extendable architecture of the back end brought more and more pain for changes each time we were requested to add new functionalities. Old technologies were not compatible with requirements, and we added more and more workarounds instead of producing valuable changes and significantly improving and growing the system. 4 months! before our CEO found the correct arguments and explained to the client why it was a waste of money to continue doing such things. It was a disaster, and everyone understood it, but for the client, it was much more painful.
In a couple of days, we did the research without any additional cost to understand how we could help our client, which learnings we did working with the old system, and what actually our client was looking for. The proposed solution was so cool. Honestly, it was cool enough to grow a seed in our client’s head and make a decision – start from scratch.
Architecture redesign
All failures bring us to experience. Their value is even equal to success. One of our clients told us once, “In case you failed again, just increase the version and go ahead” – this is so true.
4 months of work brought us an excellent understanding of the product business value and client expectations, and setup great development and communication processes. We left forming and storming phases and proceeded with norming and performing soon.
The new architecture was designed from scratch, using the latest technology stack and including best practices to make it extendable and flexible for modification, new requirement implementation, and even own DSL to specify complex business logic through the property files to be able to change behavior without development and redeployment.
3 months this is the time that was spent to bring the application to the same level it was before we started redesigning everything. But this time, we had strong architecture and team, including cloud infrastructure and documentation (which, actually, was not present previously). The client was happy, but not enough because the task backlog was almost the same it was when the client joined Jappware, it was a challenge for all of us.
Hard but systematic work and process
Having a huge backlog and a limited amount of time, we started thinking about how to implement our own development process using only best practices to make deliverables more predictable and provide proper quality.
Andrews Team (left to right): Andri Osta, Andriy Rymar, Andriy Petryk, Andriy Sloochyk
Thankfully to our team, “Andrews team” an approach was defined very quickly. The main goal was to satisfy the client’s expectations and release the product in time, but keeping in mind that we had already spent a lot of time reworking the solution. Here are the main points that help to make the release date happen on time and without pitfalls:
- Daily standups, including client participation (treating the client as a team player)
- Two weeks sprints with a clear roadmap (including planning sessions)
- Intelligent CI/CD (to integrate between the whole team faster and deliver snapshots for testing)
- Automated API documentation generation through the test execution to simplify integration between Front-End and Back-End
As a result, we got a highly predictable delivery process and a transparent approach for the client. The main goal was reached, and the client received production-ready products, including documentation and continuous delivery infrastructure. “Andrews team” was already in a “Performing” stage and brought synergy into their software development process, everyone worked like a single and completed mechanism, without any additional management.
Release and fail again.
It was done. We released our product into the external world and received the first users. The flight was OK, and no one expected any issues. But they, of course, happened.
After a month of being alive, we collected a lot of metrics and logs, we continuously did detailed health monitoring and noticed that one part of our system consumed too many resources, which quickly released after some period of time. This was pretty unpredictable, and we started adding more and more logs and metrics to understand the nature of this issue.
It was a sunny day. The team just came to the office. And realized a lot of errors in the logs. This was another disaster since that time when we realized that our architecture couldn’t handle all requirements. The issue was fixed immediately, and using our continuous deployment approach, we deployed improvements without any downtime and during the seconds. However, we already received a couple of complaints and support requests from our users. Learnings:
- Add more metrics in those places where you implement resource-consuming functionality (work with the database, file system, 3rd parties, etc.)
- Add more alerts triggers even if you think that such an error can’t happen or bring issues.
- And the most important: Please, keep your eyes on performance, especially if you know that this platform will be used by multiple users at the same time and they might trigger some “hard” task execution
Our issue was with export functionality. Each time when users trigger data exporting, we run an asynchronous task to build the report from the pre-computed and aggregated data. But we were not ready that this might happen for more than 500 users at approximately the same time. And this is our fault which brought us a new experience in issue-solving and resource management. To be absolutely clear, we failed about 43 reports creation, which is less than 10% of the whole load. Our further decision was based not only on efficient resource management but also, on auto-scaling groups for each part of our system.
Paid clients and investments
After 6 months of robust work on our application, more than 2000 users of the platform, and continuous attempts of our client to promote the system, we were invited to a competition for a European grant. This was a great opportunity to receive investments and increase our development team to build more useful features. We and our client started work on an offer for a commission for consideration. The main points were:
- Introduction of AI-based functionality to help users work inside the system
- Forecast based on a 3rd party aggregated data
- Profiles, Multitenancy including Branding
The biggest focus we did was on the AI part and how we can use ML algorithms to help our users make more value and take more from the system.
We don't know how exactly the European grant commission made its decision, but we were not able to get their approval due to a lack of 3 points. We got 88 points, but the grant might be given to those who get MORE than 90. Sad but true. Our client had a discussion to get more explanation, but all that we know is a lack of paid clients.
It was, actually, the second huge challenge, and again for all of us, including our client. We spent months improving the system and promoting it, participated in different conferences, and presented our solution by organizing other pieces of training and recorded lessons. After some period of time, doing the hard job, we were able to bring our first paid clients, and you know what? Yes, our client reached his first investments, and now we all together continue to build great and smart features for our users.
Summary
Long story short.
- Never, never give up, even if you realize that you spent a lot of time in the wrong direction
- Take care of your team, build it properly, and continuously support
- Learn from each step, learn and build conclusions
- It never can fail, it just might not be enough for success
- Failed once call it version 0.1 and proceed with a new version
For Jappware, it was an amazing experience. We built the project from scratch and saw its first investments. Right now, it is a partnership between us and our client. We trust each other and are always ready for new challenges.
Never give up, and follow your dreams!
