The Post MVP story of a startup
top of page
  • Writer's pictureStefan Minchev

The Post MVP story of a startup

Updated: Jun 16, 2022


I have my MVP, now what?


We constantly talk to people, potential clients, CTOs and tech entrepreneurs and we

hear the same story again and again. “I have my product already built by those guys

from X, they did what I’ve asked them to but the quality was poor and I am just not

sure how this will scale with bringing in more users. I even had hired that security

consultant and he found plenty of issues of great concern”.

Now that could have probably been just a small POC, sometimes a MVP, on other

occasions a full blown first release of their product idea. But it happens and



This is how it all began with Grasp.HR


It is not atypical for us as a company to take over systems built by someone else and

make them world class, addressing the scalability issues, the security flaws and

improving the general quality of the software.

What we did for Grasp at the very beginning is that we carefully analysed what was

already in place (requirements, product at hand and source code) and came up with

recommendations on how this could be improved, how much would it cost and of

course when would it be available.

It is always a balance of course between what business wants right now and

addressing that technical debt - but it is a dialog and a decision optimal for the

customer.

In our case Grasp.HR had this big client waiting for the product to be ready so they

can start using it.



The team we put together


To achieve all that we need a team of engineers, right? For less than 2 weeks after they have selected us as a product development partner we had our first team members to start: Senior PM/PO, Java Engineer and Automation QA. That was part of our plan since we had to start with product road map definition (hence the PO), fixing the urgent security issues (Java engineer) and covering the app with UI/Integration automation tests (the QA). Then we started gradually adding more people until the team reached its optimal (fitting the budget at the time) size:

1. Agile PM / Product Owner 2. Tech Lead 3. Java Engineer 4. Front end engineer

5. Devops 6. Automation QA


Quick wins with AWS


After we fixed the immediate issues, defined the road map, we started delivering towards the goals of the product. In the meantime our Devops made miracles and optimised the AWS infrastructure so that the TCO (monthly bill) was reduced 3 times! Scalability must go both ways right? If you need more resources since there is higher usage - only then the system will spin off new instances or increase its storage/throughput capacity. After some time when there is no longer such demand the infrastructure is going to simply shrunk down to the absolute operational minimum so that there will be almost no charge (for being in rest). All that had been achieved with AWS Kubernetes and improving the monitoring of the backend services. What’s next In our next material we will share with you how we further scaled the team by adding new team members and delivered one of the biggest improvements of the system, the so called: Guided Mentoring System (+Shared Space).


Stay tuned!








Get in touch with us to learn more: blooming@looming.tech


Learn more about Grasp.HR and what it can offer your employees: https://grasp.hr/



143 views0 comments
bottom of page