Developers November 29, 2020

How to choose a stack for an MVP, and build the right skills as a fall-back plan?

oba2311

Hey makers,

2020 coming to an end soon and I've been a little bit all over the place.
Started my journey in March with an idea for an app for workout and coming from a Python background worked with Flask.

After realizing the difference between an app and a webapp, I moved to Flutter to try to build something for both iOS and Android.

Having read a lot about MVPs and the sort of spreadsheet-based no-code apps I tried my next thing which was an app for plants-giveaway with a single FB post and Google Forms. It was quite a success (had almost 100 people show up for an event, and over 100 phone #s and sign-ups).

Given that sort of success, I'm now trying to build the MVP (have no $$ for a full-time developer...). People I trust recommended the MERN stack which I've been learning for the past month.

I understand that progress is not linear, but I feel like this has been quite all over the place, and if I decide to quit and look for a job, there would be no "hard skills" or a tech stack that I can say that I mastered.

Building on this year's experience, I'm determined to focus during 2021 on a much more specific path and am trying to decide how to go about it.
I have an idea for a SaaS app I'm pretty happy with and wondering how to start as a one-man project?

What tech stack? Maybe stick to google sheets and Figma before anything else?

Would very much appreciate your thoughts and advice!

  1. 5

    My tip: You can get pretty far with a monolithic framework. Some of the largest companies in the world were built/run on many of them.

    Django, Rails, Laravel, etc... You can't go wrong with either. Sprinkle some React/Vue when you need it, and you've got yourself a pretty solid setup for a one-man product.

    They'll take care of migrations, middleware, sessions, common security flaws, database connections, caching, etc... And they'll help you focus on building your product, instead learning the framework of the week.

    You can pick almost any framework/language out there, just make sure you learn it well. In particular, learn the bad parts. No tool is going to be perfect, and if it seems so, it's probably not battle-tested yet.

    You'll also be learning concepts that are highly transferable by leveraging the conventions that these frameworks will teach you. Just make sure you keep building complete projects, as opposed to several half-assed ones :) The learnings come from struggling, and the struggling comes from getting out of your "comfort zone".

    To be honest, when we're hiring at my full-time job, we rarely care about specific technologies. We're mostly evaluating how a candidate solves problems, with their tools of choice.

    No whiteboard algorithms, or random language specific questions from Stackoverflow. We just describe an actual feature we recently had to work on, and ask guided questions to understand how a candidate deconstructs the problem, and comes up with his/her own solution. I've seen a big push in this direction from various other companies in the industry. It's a much better indicator of how well a candidate will perform on the job.

    My point being: tools don't matter. They're just a means to an end. Leverage battle-tested tools with a big community around them. You're standing on the shoulders of giants.

    1. 1

      Thanks @asimon for this thoughtful comment.
      Do you think that Django could go a long way for both web+mobile?

      1. 2

        +1 for django TableFiller.com is built on it with AWS. Rails larvel and django all handle web apps well. But if you are looking to have mobile apps you might want to think of a nodejs backend and frontend so that you can use react native and the same tech stack across all platforms. I would stick with web apps + reactjs or vue when its needed but not at the start.

        1. 1

          Thanks!
          I'm just wondering whether I should use Flutter instead because I believe I'm building with a mobile-first approach. What do you think?

          1. 2

            I think you should just make a mobile-friendly web app. Trying to build bother mobile and we apps as one person and one who's still in the early learning stages is playing on extra hard mode.

          2. 2

            Unless you are building a B2C - I wouldn't. The time it takes to talk to users, update a feature, and release is too long for my liking, especially during the first 6-12 months. Indiehackers and ProductHunt are good examples of web apps that are functional without a mobile app (I know PH has a mobile now). My general strategy is to use web apps to test ideas and features with customers and then to use mobile for growth when I know what I'm doing and what makes my startup different from other competitors. Keeping in mind the second you go mobile app - you have to deal with app reviews and how many downloads your app has. Some people will shy away from apps with little downloads (in the same way they do with Twitter profiles with little followers). In terms of Tech. Flutter I've heard is good - if not better than react-native - but the eco system of react-native is mature (for me anyway) and if I needed to hire a freelancer or full-time dev with reactjs and react-native I know I will be able to hire.
            ..... that all said :) I have built side projects to learn a new tech stack and then get a job. So if that is your Plan B - than learning flutter could be a good option for you.

            1. 1

              Thanks @shanedevane!
              There's an app that I know people want and I"ll build it with flutter.
              The other one in my mind would be a SaaS project - what would be your suggestion re a SaaS MVP?

  2. 2

    So, I am fairly biased on this, since I make Nodewood, a web app boilerplate, but... start with a boilerplate.

    There is a lot of code you need to write to start a SaaS and most of it is wasted time. Yes, your app needs user authentication & management, password resets, user profiles, etc. You're probably going to want subscription management, an admin section, all kinds of common stuff. But! Writing all that doesn't make you any money. The only code that really makes you money is the business logic that makes up your actual app idea. Spending even a day writing the code that lets users cancel their account is a waste of your time, when you could have spent that time writing the business logic that your customers are interested in paying you for.

    Now, it sounds like you're more of a Python developer, so I can't really recommend Nodewood for you -- Nodewood is Javascript-only, with a focus on code re-use between the server and client -- but there are all kinds of app boilerplates out there. For example, in Python, there's SaaS Pegasus, written by another IndieHacker, which might be more up your alley.

    But strongly consider finding an app boilerplate that uses the language and has the features you need. The time and money you save -- compared to building it yourself or paying a developer to build it for you -- are immense.

    1. 1

      Thanks @DanHulton!
      I'll definitely use a boilerplate no question.

      1. 1

        Thanks for the Pegasus shout out @DanHulton :)

        @oba2311 if you are interested in using Pegasus and have any questions don't hesitate to hit me up: [email protected] (or just ask them here :) )

  3. 2

    My advice would be:

    1. Don't spend a ton of time on containers or complex devops. As a solo dev, it will suck up a lot of time and you don't need it early

    2. Avoid using a full-blown front-end framework if you can. SPAs are a great UX in some cases but it takes more code and more time to ship them.

    3. Do use some kind of full featured backend framework with database migrations and generators. Rails and Laravel are great examples.

    4. Don't worry about scaling to more than 10x your current number of users. Much of the advice you'll encounter online is from engineers working as one of many employees for a business with completely different needs than a new startup has.

    1. 2

      Thanks @alchemist !
      Great advice re scale at this point.

  4. 1

    Stick with Python Flask since it sounds like you've worked with that in the past.

    I would take an online course and learn how to deploy a basic Python Flask web app to a Linux virtual machine on AWS EC2 or Heroku.

    For development use Docker and learn how to build and launch a Python Flask container so you can develop code on your local workstation or laptop.

    Store all your code in a GitHub repo. When it comes time to deploy to AWS just SSH into that server you created and do a "git clone" then "git pull" to fetch your latest code. Start with that simple setup and grow from there. Don't go down the rabbit hole of learning anything too complex. If you're successful then you have plenty of time to add complexity later on.

  5. 1

    The MERN stack is great! Node/Express are easy scalable, MongoDB is flexible, and React is just a library so your options are quite limitless. This stack is also nice because it is all JavaScript, so you only need to know one language to build an entire web application.

    On top of that, if you know React you basically know React Native, so you can build your API and applications for all devices with one language!

    1. 1

      Additionally, I share non-UI code between React and React Native so you don't have to write duplicate frontend logic which is a big time saver

      1. 1

        Thanks that's awesome!

  6. 1

    It depends on what you want to build and what technical skills you already have. I like to start new projects with new languages and tools, but in a business context this may not be a good advice. If you want to get things up and running quickly stick with the things you are already learning/knows. In the end the tech stack is not as important as some hyped tech stacks may suggest.

    1. 1

      Thanks.
      I'm considering starting with Flutter.

  7. 1

    I go with what I already know. Allows me to get something out the door a lot quicker.

    1. 1

      Thanks @maker256 , it seems like many guys are choosing this path.
      I wonder whether we can find someone who decided to learn something new for a particular reason.

  8. 1

    The best tool for the job is the one you know (or at least familiar with). Pick something simple, easy to work with. If it takes off, you will have time and $ to rebuild on more suitable platform.

    1. 1

      Thanks, @javadiagrams .
      I guess that my question is not just about a tech-stack, but rather more generally - what is the next step?

Recommended Posts