Developers January 21, 2021

How do you evolve your MVP's tech architecture?

Edu @palmerotti


I'm building an Airbnb-like product where clubs can post sport tournaments and players can enroll to them.

The frontend is a custom React app built with Nextjs (I'm following the JAMStack Architecture), but for the backend I need something simple for building the MVP as soon as possible (atm i'm going too slow and i want to ship faster).

Since the idea is to iterate the product over time to a more complex sass (payments, roles, gamification...). I want something that can scale, or that I can easily migrate later.

In the future, ideally i would like to use NodeJS + GraphQL + Mongodb or any other non-relational db.

I have found very promising, but it doesn't support embedded types in mongodb, which treats as a relational database. I'm not sure if this would be a problem, since data modeling is one of my main concerns. What do you think?

What approaches do you take for evolving your MVPs from a tech point of view?

  1. 4

    Regarding the scale/DB piece: You might be fine with a relational DB and avoid a lot of the nosql headaches. It's usually a good exercise to calculate the expected number of rows in various tables - relational DBs can easily handle millions of rows and imo make a lot of sense for user entered data, unless you're facebook or twitter scale.

    1. 2

      (and by headaches, I mostly mean transactions and schema evolution / data migrations)

    2. 1

      Hey! thank you,

      I don't really know a lot about data modeling and the structure/requirements will change a lot. That's why I was thinking on choosing a no-relational DB, since it seems to be better for my needs (?)

      As i said i'm not really sure. I'll take a look to it too :)

      1. 5

        I don't really know a lot about data modeling and the structure/requirements will change a lot. That's why I was thinking on choosing a no-relational DB, since it seems to be better for my needs (?)

        This is a proverbial footgun, and I would say is the more crucial thing to get right from the start to make scaling your product not suck later.

        Many times Ive seen people/companies take this approach; they start with Mongo because "my data model changes" and they eventually end up having to rewrite everything when moving to an RDBMS like MySQL or Postgres (looks like @lgrammel has had similar experiences).

        Generally "my data model changes a lot" with Mongo is code for "Im stuffing unstructured, messy data into collections and have tons of app-side logic to make sense of it that is really a mountain of tech debt I'll have to rewrite later"

        I would argue that a relational database is actually easier to work with when your schema is in flux because you cant just stuff random key/value into an object. You have to actually think about your data and how you can atomically move from one schema version to the next. Is it going to be slow? Yeah, but you'll thank yourself later down the line when you don't have to completely rewrite your backend for a new database.

        1. 3

          Hey thank you @seanmcgary @lgrammel guys!

          This is really great advice. I have never had to design any complex data model myself and i just turned to mongo to this project since it seems to be the "default" option for startups (or at least it is what i have heard).

          After some research i think it will pay off in the future! so i'll spend a little more time learning Postgres and going on with it for my project :)

          1. 3

            You're welcome :)

            One thing that I learned is schema and data migration is extremely important in practice (requirements change and schemas evolve all the time), but rarely talked about. In SaaS this can get even harder if you come to the point of needing zero downtime (which can be ignored initially imo). Therefore it's worth not just looking into the DB/data modelling itself, but also into migration frameworks (for the language of your choice). This will enable you to more easily update and change your schema going forward.

            1. 1

              Oh that's a good one. I'll give a look to it too!

          2. 2

            You can also have a hybrid approach of this and mix and match noSql and relational data models. PostgreSQL has a JSON column type, which would allow you to move fast with some portion of your data while it evolves, and then refactor this to use regular tables and columns once this part of your model becomes more stable. This way you also avoid being locked into using MongoDB with a large refactor waiting for you, if your end goal is using a relational DB anyway.

            1. 1

              Oh that’s cool. It solves a couple of problems I’m having. Thank you!!

      2. 3

        Well, my experience is pretty much a war story from a startup I worked at (plus what I took from Fowler's nosql book). We chose mongodb initially, and because of all the schema changes etc the DB content ended up being a mess quickly. Maybe things have changed since, but with relational DBs you usually get solid DB migration libraries such as Liquibase in the Java world.

  2. 2

    It's a bit hard to say since the choices you've laid out so far generally slow down an MVP.

    A custom React app means building a SPA, which is a lot more work than a traditional app. GraphQL is also great for teams with separate people working on the front-end and back-end, but a definite cost at the beginning.

    Node on the back-end also means asynchronous logic and more work than other alternatives. Mongo is also a very questionable choice.

    If you want to ship quickly, why aren't you using Rails or another framework it inspired such as Laravel or Phoenix? It's what Airbnb themselves used until they had a sizeable engineering team to invest in a more complex front-end.

    Another possibly even quicker choice would be WP, Zappier and some well-chosen plugins.

    1. 1

      Hey! Thank you for your reply! I agree with some of your points.

      The reason I've chosen this stack is because they are the technologies i'm most confortable working with. I don't want to spend too much time learning a new framework just to ship a MVP, or get stuck with bugs with because of not knowing what i'm doing.

      Also, I have already validated some of my business hypotheses with other projects, so I want to start thinking on the foundation of my future codebase too.

      • graphql + typescript + codegen, save me for a lot of bugs and troubles.
      • at some point i'll build an app. I profesionally work with react native so I'll go faster in the future by developing now my frontend in react too (i think).

      Regarding Mongodb that's true. After some other dev's comments and some research i have decided to change my mind and use Postgres instead.

      This has been a very constructive feedback to think more deeply in some of my choices. Thank you!

      1. 1

        I think the core issue here is that what stack makes the most sense for an indie isn't what makes sense for larger companies with resources to employ people.

        If you're a company with a dev team of ten even more, then a separated SPA, GraphQL, microservices, Kubernetes, etc is likely a great idea. If you're a fledgling project run on a single dev's nights and weekends, then it's a disastrous choice.

        Bringing the tools learned on a job for a large operation to a fledgling one seems to be one of the most common causes of self-inflicted pain I see on IH.

        FWIW, I was in that situation myself in late 2015 and it cost me half my runway. I'd been writing Backbone and then React apps on a Node back-end for three years and the job I'd left was also using GraphQL, so I just gravitated towards it for my own projects after quitting to try digital nomadism.

        Imagine my shock after finally messing around with Rails and turbolinks for a couple of weeks, after realizing I was already more productive than with the main stack I'd been using for years.

        I guess the trade-off depends on how quickly you expect to get to where you're going to be raising or earning enough to hire a larger team and how long you think it would take you to learn tools more suited to solo devs.

        In my case, I had an absolute minimum of 50 to 100 hours of dev work ahead of me before getting to where I could hire, so it was clearly a good choice to invest in expanding my skills. YMMV

        1. 1

          Yep! I get your point.

          I think for the front I'm happy using React. Nextjs, Chakra UI and reusing code from other projects allow me to develop flexible and good looking things pretty fast. Also with Vercel I can deploy in seconds.

          But I agree it may not make much sense to code a different backend as being indie...

          I have been playing around this weekend with Strapi and I have set up a graphql API with Postgres in just a couple or hours. It is enough for what i need for the next months, and I can customize its controllers or use nextjs serverless functions for more complex stuff i need. I think I'll continue with it!

          For managing the server I've being recommended to use, which seems a pretty cool tool for that.

          For my future projects I'll definetly take a look at Rails or Phoenix from the beginning. I'm now curious to use them!

          Thank you! So much valuable advice!

  3. 2

    We have been building our MVP for the past two months using Mongo/Apollo/GraphQL on the backend. But are realizing we may have made some bad choices with mongo and a few other small things. So I've been experimenting with Hasura for the CRUD part of out backend and I pretty much rebuilt all of it plus some things we still needed to do in a day. We will still need to use our own auth system for user logins, but other than that Hasura covered a lot of our needs for the MVP. I would highly recommend looking into Hasura and consider dropping mongo for something like Postgres.

    1. 2

      Hey! Thank you for your advice!

      Yepp after some thought and other people's recommendations I've been researching more and I'll finally go on with postgres. Thank you!

      Regarding Hasura it seems pretty cool, I'll take a look.

  4. 2

    Maybe the fastest way is to use something like Firebase. But I personally am not fond of NoSQL, my brain just works best when it can relate or normalize data. So I would recommend That's an open source Firebase alternative only using PostgreSQL. It also has rest, GraphQL, JS client lib, and for some custom logic, use a couple of serverless functions on Vercel.

    1. 1

      It seems very interesting, i'll give it a try! Thank you!

  5. 2

    If it's an MVP, does the back end need to be dynamic? If I'm wrong then my apologies... But it sounds like you need to finish your MVP meaning you want to be able to show it to potential customers for validation or feed back maybe.JAMSTACK is perfect because it abstracts away certain things that can help you focus on presenting the solution. I would wonder if your MVP is supposed to feature "STRAPI"-luje functionality, or should you focus more on showcasing the intent to allow a business to fill out a form and images that display on the site with some CTA for contestants.

    1. 1

      Hey! Thank you for your reply!

      I have already validated some of my business hypotheses so my main goal now is to ship asap and frequently to start getting feedback and plan for the next features.

      Since i'm a solo founder working full time, I don't have much time to do everything from scratch, but the product itself will become more complex in the future. That's why i'm looking from the beginning to use something flexible and which I can ship fast, but having in mind that at some point I may need to build a custom solution to fit my needs.

      At that point hopefully I'll have more time and resources, so I'm trying to not make bad decisions that can be a really problem later.

      Hope i explained myself!

  6. 2

    I reccommend Django Rest Framework.

    You get:

    • admin panel out of the box
    • api docs out of the box
    • migrations
    • define model and crate a viewset and you get all CRUD routes for it
    • huge community
    • tons of third pary libraries
    1. 1

      Thank you for your recommendation! It seems very interesting but unfortunately i don't have much idea on Python/Django so it maybe will take me a lot of time to figure it out everything. Anyways I'm sure someone else reading this will find it useful.

  7. 2

    This is fairly general advice, but worry about coupling. The important things are the boundaries between different components. If Strapi imposes some opinion on your data layer, that is something that will be an impediment to removing Strapi later.

    Ideally you want to keep each component as encapsulated from the others as possible, so you can migrate the parts of your system piecemeal without having to do big sweeping refactors.

    1. 1

      Hey Jake!

      Yep... this is the thing that is bothering to me. I want to find the balance between start testing my product asap but without compromising the tech stack and architecture too much for future migrations.

      I'm mainly a frontend developer so building a custom backend will take me a while to build and to later deploy / maintain.

      I have liked Strapi a lot because I was able to built a POC last weekend with the data structure i wanted and a GraphQL API without spending almost any time writing the code. What i don't like is that:

      • what should be embedded in 1 collection is in like 20, so the performance may not be the best soon.
      • i'm not sure if i'll be able to migrate my backend to a custom one easily.

      Thank you so much for your reply. I'll give it a new thought with that in mind.

      1. 1

        As to your two bullet points, I would worry not at all about the first and almost entirely about the second. Preemptive performance optimization is almost always a bad idea. And when (and if — you may not even run into the performance problems you anticipate) it does become an issue, the only way you’ll be able to overcome it is by being able to isolate poorly performing pieces and improve them.

        1. 1

          Yep that makes totally sense! I'll focus on have a good foundation + shipping asap :)

  8. 1

    Hey Edu, I can help you with that.

    1. 1

      Hey! I'll take a look. Thank you!

Recommended Posts