Building our MVP with Meteor

We’re building Clever — an AI-powered platform to create conversational interfaces (i.e. a chatbot o a virtual assistant) — from the ground up and, as many other before, the first thing we wanted to build was an MVP as quick as we could. Most of you already know what an MVP is but, for those who don’t, an MVP is a version of a new product that lets you collect effortlessly validated knowledge. The MVP can be used to quickly obtain knowledge about the market for the product and to validate some functionalities of the products.

Clever began with a very very small team adopting a Lean approach and, based on that approach, for our first MVP we decided to build it on top of Meteor.

What is Meteor

Meteor is a framework to build applications based on Node.js and open source. It leverages the creation of prototypes and produces multi platform code (web, Android, iOS — thanks to Apache Cordova). It comes with native support of MongoDB using DDP (Distributed Data Protocol) and a publish-subscribe pattern to automatically propagate the changes in the data allowing the developer to write less code.

Although it has reach its maturity — it’s more than 5 years old — it has had a bigger adoption outside Spain that it has had here. Nowadays it’s a bit at stake due to some doubts regarding its future development by MDG (Meteor Development Group), the UI libraries — mostly Blaze vs the new players like React, Angular and Vue.js, the lack of support of other databases rather than MongoDB -yep, we know about Apollo — and the amount of magic happening under the hood; that magic makes your life easier but it comes with a price in terms of less control.

Meteor began to tackle those issues, so they started to support other UI libraries having Blaze, React and Angular as first class citizens ( there are options to use Vue.js but they are not official). Regarding the db support, Meteor has focused the last few years in developing Apollo, their own solution based on GraphQL.

Why Meteor

We knew that in the future we would be using a more traditional approach — based on REST apis — so that we looked for a solution allowing us to cover our needs at that very moment but, keeping in mind. a posible migration to a different technological stack. That’s why we decied to use Meteor. it was a perfect match. It allowed us to develop out front web app — based on React — and cover the needs that our backend team was not able to reach due to the time frames and the focus we had — we were more into developing the core of the platform rather than spending time in the management of the surrounding functionalities ( let’s use the CRUD acronym although it was more than that).

Our first MVPs — based on Mantra — were to tied to Meteor and we looked for something more framework agnosti. We looked for an option to implement Redux in Meteor. This approach has allowed us to start a smooth transition towards a pure React application while we move our server side logic from Meteor methods to a pure API based on AWS — using API gateway and lambdas.

Pros and cons of using Meteor for your MVPs


  • Low learning curve
  • Community support
  • StackOverflow, Meteor forums, etc.
  • Huge amount of packages
  • Reactivity — huge fan
  • Hybrid apps
  • Development experience
  • Deployment
  • Galaxy
  • mupx


  • Database support
  • The magic under the hood
  • Doubts with the scalability
  • Deployment: yep, it’s in the pros section but you will discover how hard it can be to fine tune it when using environments such as AWS
  • Although it supports npm packages, it yet relays on its own packing system (this is changing and hopefully will be in 1.5)
  • It requires a high knowledge of Node and the Meteor internals to tune it for a better performance.

What we’ve learned

The use of Meteor and it’s huge ecosystem — using npm packages and Meteor packages from Atmosphere — has been a great solution since it has allowed us to smoothly transition from a monolith to an API based web app while the core of the platform was developed.

Although we were frightened in the early stages (there have been many voices advising us against this solution), to me, Meteor is a perfect match when building MVPs; it’s also the perfect partner when Lean is a native word to you and your team.

What’s in the horizon?

We are in the process of making the switch towards a pure React app. Most of the functionalities are now backed up by our API and our fronted can be deployed to S3 once our web app is completely migrated. We’re also considering to experiment with Vue.js and Angular 4.


Sure, there were other options — many, in fact — but Meteor has proved to be a very good alternative when building prototypes and the web app we are (still) running. It has allowed us to:

  • Quickly build our prototypes so we could validate our hypothesis
  • Grow while our amount of users is increasing
  • Have a backend covering our needs not covered by our APIs
  • A very pleasant development experience — although the reload times when there’s a file change is still enormous

My final conclusion is (although it’s not new, sometimes it’s hard to learn): “Use the technology that best fits to you at that given moment. You’ll have the time to make the switch (if needed)”.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.