How to Save Time When Building an MVP Prototype App
If you believe that time is the most valuable resource, then you will want to read on. As the CTO at Mootli (An instant event app for connecting like-minded locals together), I needed a way to build a MVP mobile prototype as quickly as possible in three months. We’ve gotten quotes from $15,000 to $20,000 to build the prototype with the feature sets we needed. We didn’t have any money so I knew I had to step it up and rely on my very own human capital.
To accomplish my goal given the resource limits, I chose to go with a hybrid mobile app approach. Ionic Creator for rapid prototyping, Ionic Framework (HTML/CSS/Angular.JS) for the front-end, and Google’s Firebase for the back-end (Hosting, database, and Facebook Authentication). I will breakdown my reasoning behind why I chose to use each one of these technologies for my project. I hope that it will inspire you to start your own project!
Why Ionic Creator for Prototyping
Time saving. I traded precise pixel by pixel control of the design for super fast prototyping that generates code.
Drag and drop interface is so quick and easy to use. It’s like using Squarespace or Weebly but for mobile apps. It makes prototyping your app really fast.
It generates code. Biggest advantage over using prototyping tools like Invision or Sketch is that it generates Ionic code(html/css/angular) after creating the prototype so you can jump straight into coding the functionality right away without wasting time coding the html/css from scratch.
Based on Material Design. The UI (User Interface) styling is based on Google’s Material Design so the apps you create already looks pretty good. You can customize the UI styling further if you want but this is a good starting point.
Cost. The paid plan cost me $29/mo, $87 total for three months. The paid plan allows you to do the Angular codes directly in Ionic Creator along with making some API integrations easier. I learned later on that there were limitations that blocked me from doing Facebook Authentication directly in Ionic Creator so if I was to start over, I would’ve just went with the free plan and done all the Angular coding in my editor locally.
Inline-css. One drawback of using Ionic Creator generated code is that it generates inline-css code for all the html elements, which is perfectly fine for prototyping but as you probably already know, inline-css is not a scalable solution. So if you want to further build your startup project on top of your prototype, you would have to manually convert all the inline-css into a css file which can be very time consuming. You might be better off scrapping the prototype code and just start from scratch. For the purpose of my prototype, the inline-css was just fine.
Minimal design control. Another drawback is you won’t have the precise control of using prototyping tools like Invision or Sketch. For e.g., you can’t line up elements pixel by pixel directly in the visual interface, which makes it very limited for a professional designers to use. You can always modify the css code to line elements up to your liking so it’s really targeted more for developers than designers.
I’ve also made a video demo of how you can build a simple app in 10 min with Ionic Creator to show you how much time it can save.
Why Hybrid Mobile Apps and Ionic Framework for the Front-End
Time saving again. I traded some performance for tremendous time saving.
Cross platform compatibility. I can write the code once and use it for mobile web, Android Play Store, or iOS Appstore which again saves me time from having to learn Java for android or Swift for iOS.
High quality docs with live preview examples. I can quickly reference something if I don’t remember it.
Performance. While it’s getting closer and closer to native apps’ performance, it still lags behind React Native (another hybrid app alternative) and of course, actual native mobile apps. I felt that this was a reasonable tradeoff considering that 1) This is not a 3D gaming app 2) This is only a prototype.
Why Firebase for the Back-End
Time saving yet again. Realtime database without having to learn back-end.
Backend as a Service. A godsend for front-end developers. Imagine having access to a realtime database without having to learn how to host and manage your own server in the back-end.
Performance and 3-way data-binding via AngularFire Library. It‘s super fast and it’s realtime. Once a user makes an update in the view, the change is reflected in the model, the change is then updated in Firebase database and reflected back the other way, from Firebase database, to the model, then back to the view so the user can see the change they’ve made right away, all in realtime!
Minimal setup. It’s no drag and drop but I was able to figure out how to hook up the firebase API from reading the docs fairly quickly.
Scalability. It’s backed by Google, uses google cloud and is built to scale to millions of users. If you need to migrate or backup your data, you can easily export all of your data in JSON format.
All-in-one solution. Hosting, Database, and User Authentication. I like having my front-end, back-end, and user authentication all hosted on Firebase because it makes managing much easier and I trust the reliability of google cloud servers.
Excellent free plan. Met all my needs for my prototype project. Their free plan gave me 1gb of realtime database storage(I only used 20kb out of 1gb for text data), 5gb regular storage (for pictures and other media, which I did not use), and 1gb of static hosting (I only used 45mb out of 1gb for my entire front-end codebase).
Potential for breaking changes. Firebase is updating and evolving so fast that there might be constant breaking changes. Firebase v2 to v3 was a complete change which required you to make lots of changes in your code to work with the new version. Many tutorial course creators also lost a lot of time and money that they invested in teaching Firebase v2. For me, this was a trade-off I was willing to accept for such a useful, cutting-edge product.
Data Modeling is different. Firebase is a NoSQL database so you have to model your data differently compared to traditional SQL database. I’ve learned that you have to 1) Keep your data shallow — Even though Firebase allows 32 levels deep of nesting, you should keep only one to two levels of nesting as necessary to keep data reading fast and efficient. 2) Keep your data as streams — provides great scalability and prevents large queries that slow down your Firebase. 3) Duplicate your data to match your UI view— In Firebase, it’s ok to duplicate your data and you want to match it to what the user sees in each screen to speed up your reads. The trade off is that it can slow down your writes and be a bit of hassle to manage because for e.g., when a user updates their profile name, you need to update every single place that you duplicated their profile name data. However, by doing this, it will allow your app to scale easily to millions of reads without slowing down.
**If you want to learn more about this topic, by far the best video I’ve found on Firebase Data Modeling is the one by Chris Esplin: **
To sum it up, although the startup itself didn’t work out (I will talk about the product side of things in a upcoming post), investing three months to build this prototype was one of the best decisions I’ve made. I’ve learn so many new programming concepts, tools, and practical ways to apply it. It gave me the confidence that no matter what problems I come across in programming, I can always figure it out. Some problems may take longer than others, but I can always be self-sufficient to solve it and ship the feature that my product needs. Best of all, I didn’t have to pay $20,000 to a dev agency and go into debt just to get a prototype built. It only cost me $87 for three months of Ionic Creator Pro and three straight months of blood, sweat, and tears.
I also came to the realization that I’m no longer afraid of learning new programming languages or frameworks. To me, it’s just a different way of accomplishing the same things. At the end of the day, you’re still programming. It’s like switching cars from a Toyota Camry to a Porsche Boxter. It might take you some time to get used to it, but in the end, you’re still driving from point A to point B.
This post was just a glimpse of my thought process, what I’ve learned, and why I chose the tools that I did to build my startup project, Mootli. I truly hope that it’ll be a useful reference to you and save you some time and money when building your next project!
*Just a side note. Although I kept the project as a mobile web app and did not deploy it to the Android or iOS app stores, by using Ionic Framework, it would be fairly simple to convert it into the native app store formats.