Throughout the past year I have been lucky to be involved in the development of two mobile apps for two distinct clients at our company.
Although similar in nature, the challenges and approach for each varied drastically from each other and I wanted to share my learning experiences with you and what I found where some of the quirks and differentiations between building an MVP for a Startup and a large FinTech company.
StartUp — The Challenge
Our first challenge given to me and my colleagues was the task to build a fairly intricate MVP for one of the largest airports in LATAM that had many moving pieces, from pulling real time flight data, map visualizations of department stores, and a personalized recommendation engine amongst many others.
The purpose was to encapsulate a true fully digital experience and engage passengers through a single mobile app and eliminate the need for the user to download multiple apps and diminish a scattered brand engagement.
ISV — The Challenge
The second challenge that was thrown at us –and I mean that in the best way possible– was for a large FinTech company. It’s a financial app, it involves working with a lot of functionality around people’s money. It was also something several banks were going to use, so as you can imagine, everything was very serious and complex all the time.
Today, I want to take a moment to share with you our experience but mainly, the difference between building an MVP for a startup and building Enterprise Software™.
We’ll split it into the different categories:
The Technologies Behind it
No doubt the startup was more flexible on this, they were open to suggestions, and were eager to try out cutting edge technologies even when it involved risk like using products in BETA version for production 😝. For example, they wanted to use Cloud Firestore even it was marked as BETA at the time.
The Fintech company was understandably more closed about the tech stack we would use. Even the packages we had to install had to go through a thorough review process, by both their technical team and their security team. Not to mention that anything that they couldn’t have 100% ownership was out of the question.
I’m still not sure if this is affected by the type of product, I’m inclined to think it’s more because of the scope, but for the MVP we had a team of 1 Project Manager, 2 Developers, and 1 QA. There were no UX people on the team because the client had their designs already.
The team for the Enterprise project was a lot bigger, we had 1 Project Manager, 6 Developers, 2 QA, and 2 UX experts.
As I said, it’s more about the scope, the MVP was a 2-month project, the Enterprise Software was a year-long engagement
This is an aspect where we found A LOT of difference, the startup needed to get to market ASAP, so we were focused on deploying new functionality every week.
For Enterprise Software™, things are different, we had a multi-part process for releasing code:
We started with a roadmapping session where we analyzed the entire project and defined the features to build in each release.
We set up a monthly release with 2 sprints in each release.
After each sprint, the features went to our QA team.
After QA certification we generated an installer for the client’s QA team.
After client QA certification the features were approved and integrated to the project. Or they were sent back for fixes.
I talked a little about this in the previous point, but there were some differences in quality assurance too. For example, for the Startup project, our QA had more say in how things worked and what she considered to be a met expectation.
For the enterprise client our QA team certified the features, but then after that, their own QA team had to certify it before giving the go to integrate it with the master branch of the project.
This is another part where the process was A LOT different, with the startup client they handed the designs for us to implement them and it was a less rigorous process.
With our enterprise client the design was also a multi-step process:
Our UX team created the designs for the feature for the next sprint.
The client’s design department approved the designs.
The client sent the approved designs for user testing.
The client sent back the designs to implement changes based on user testing.
Our UX team made the changes/fixes and then send the designs back to the client.
I think this has to be more with the type of client than with the type of project, but it’s worth mentioning because things were very different.
For our startup client, we set up a deployment using Firebase and WordPress (for the content part of the app).
The enterprise client had different requirements, it was all done with internal tools/platforms they had, we had the source code inside our VSTS account but only while we were “on development”.
Once we had an approved release by the client we moved the source code to their own repositories where they handled everything.
The Money Talk
As you might imagine the money 💰 talk was very different for both clients.
The startup client had a team about 1/3 of the size of the enterprise client that impacts the costs a lot, also, processes and scope were different.
As a company, I think the biggest lesson we learned from both those projects is how different our approach should be depending on the type of client. Tools, communication, methodology, etc.
On a more personal note, I learned to keep a more constant and fluid communication with clients, there were a lot of moments when talking things together helped us avid major roadblocks.
What do you think, are you a Startup looking to get to market fast? Or an established company looking for a technical partner?
Don’t hesitate to reach out, we’d love to talk about how we can help you get to market and make that project come through.
Reach out to me or Yuxi Global — firstname.lastname@example.org — if you are going through similar challenges in your organization and are looking for help in building your next MVP or Digital Product. We love a good challenge and are always looking for ways to innovate with you.