Bringing a project to the investment stage — how we worked with Profi
First interview
Our joint story with Profi (previously Awarenow) began before the new year 2018.
During the first interview, we were met by a pleasant woman from Los Angeles, Alina — the CEO of Profi. Her eyes were glowing with her idea, and we were infected by her positive energy. It turned out that this was their second attempt at starting this project. The previous team could not pull through the task, so a significant amount of money has been wasted. After such a negative experience, even the friendliest people might lose faith in all developers. We liked the project very much right away, but obviously, we were not the only team considered for this job. So we asked ourselves the question: how do we become a part of this awesome project?
Building trust in a relationship
With interesting projects, you can take some financial risks. So we offered Profi a ‘trial month’ approach. We work on the project for a month and then, according to the first month’s results, we either part ways or continue working for a fee including the first month. With this approach, the customer’s risk is kept to a minimum. In fairness, this approach does not work with every customer. Sometimes we come across such customers who, using this model, endlessly switched many teams and managed to build something for free. We do not take any prepayments, the client pays for the work done after the fact (usually every month). Yes, it carries some risk for us, but this approach leads to mutual trust.
So, what did we spend the first month on? As mentioned above, the life of the project began before the meeting of Profi.io (then still Awarenow) with Intspirit. We had a non-working monolith in our hands. The first thing a new team usually does in such cases is to offer to rewrite everything (it’s easier this way, you don’t need to understand someone else’s undocumented code). If we put the product in the first place, then we need to try to save the client’s resources as much as possible, because we don’t want everything to end halfway to the goal.
Before us, the previous team had been working on the app for half a year. It is impossible to immediately draw a clear conclusion on whether it’s worth continuing to work on that same app or not. And who knows if our results will turn out to be better. Therefore, we chose to revive this monolith within the first month, compare it with the client’s goals, analyze the code, architecture and add the remaining basic functionality. Drum roll — a month later, the product works quite well. But this app only had the basic functionality, and Alina had a sea of ideas for years to come.
Now, after a month of work, it was possible to say clearly that it was continuing with the existing application was not a great idea, for a number of reasons. Among the main ones: the complete absence of modularity, tons of spaghetti code, AngularJS at the core (by this time it was no longer being developed, and instead was replaced by a new productive and promising Angular). We decided to rewrite the product and establish a microservice architecture from the start. To save some of the client’s resources, we kept the API from the old monolith (it was our first microservice, and later we gradually rewrote it as well) and began development.
Approach to management
From the beginning, the client was a member of the team and not the boss. Thanks to Alina we didn’t have to work on it. It was a good sign of things to come.
Many clever articles have been written about proactive management as the key to success. It is really worth it to strive for this, but in practice, it’s not always possible. To be honest, we had a bit of both. The truth is somewhere in the middle between proactive and reactive approaches. It’s not always possible to be proactive when priorities change several times a week (this happened sometimes too). Sometimes the customer really wants to add something unattainable or unreasonable to the project. If it does not lead to the project’s collapse, then instead of arguing the best thing to do is to provide ways to go back (write the required module in such a way so that it can easily be excluded later without harming the architecture).
It is important to remember that the product comes first and to protect it from destructive decisions. It is possible and necessary to discuss&negotiate with the client when the situation requires it. There is an important thing to notice here: the client will listen to you only if your decisions lead to great results. Of course, if you feel that the stakes are high, you can also act “reactively”, swoop into action, work day and night for the result. But this should not become a habit for either you or the client, because it can lead to professional burnout, which is as detrimental to the product as it is for yourself. Strength is in balance, the main thing is to remain professional in any situation.
Technical debt
Any dynamically developing long-term product accumulates a technical debt.. It is important to inform the customer about it and convey to them how important refactoring is. But what if it is not always possible to convince to allocate time for this? Here is a little life hack.
During the process of estimating current tasks, put a certain percentage of time towards refactoring. If you see that you have implemented a new feature quicker than anticipated, spend some more time on refactoring (there is always something to improve). While this approach will not solve technical debt completely, it will smooth out its negative effects.
The first serious results
The first release had been planned in 5–8 months. The intermediate results and feedback from the first clients of the platform inspired the customer with new ideas. There were a lot of ideas, much more than we were able to implement in the required time. We tried to constantly highlight only the most important features. The project was built at the customer’s own expense, so we did not have the resources for the entire standard management chain. On Mondays, we had “warm evenings” — meetings that included everyone (CEO, designer, 2–3 developers). There were no bosses at these calls, and everyone was free to express both ideas and criticism. Alina deserves a huge ‘thank you’ because it was not easy for her with us at times.
Transition to the investment stage
3 years into our collaboration, the Intspirit team involved in the project had 7 people — CTO, team-lead, software architect, 2 senior developers, and 2 middle developers. Despite that, the product was already a serious machine with huge functionality capable of helping people, providing various online services: schedule, calendar, booking with payment, calls via the platform and through Zoom, courses with modules and tests, subscriptions, integration with various services and much more.
The product became attractive for investors, but at this stage, our cooperation began to come to an end for natural reasons. The fact is that Alina had a dream to create her in-house team from the very beginning. And this moment was more convenient than ever to put this dream into reality.
This final part of the joint history of Profi and Intspirit lasted a little more than a year, and now the project is a completely independent ship with its own professional team on board, which we can leave with a clear conscience and move on to the new exciting adventures. We have no doubt that the Profi team has a huge future. And if our paths cross again someday, we will be very happy about it.
It was a wonderful experience with a lot of challenges. We take this opportunity to once again thank the Profi team and, in particular, Alina for the opportunity and trust.
If you want to create your awesome project — feel free to contact us. We’ll be glad to help!
