6
18 Comments

How Does SaaS Application Development Actually Work? (Edited)

Hello everyone,

I've been dwelling on the theoretical details, and now I want to "do" application development, not just think about it. Luckily I came across the fantastic Indie Hackers community a few weeks ago, and maybe some of you can help me answer some questions:

  1. What are good resources on building scalable web applications?

  2. How can I get started when I want to build my own application?
    2.1 I know how to code and I know the common SE patterns,
    2.2 I don't know how user authentication implementation works, and
    2.3 I don't know scalable database design in practice.

  3. Pure theory doesn't work outside of development environments. Where can I learn more about how to actually bring (distributed) applications into production?

  4. How can I structure my application so that it remains maintainable and extensible as more people work on it?

  5. When do you move from hacking the MVP to designing an application based on the system architecture?

I realize that some questions need to be answered in a more specific context, but I am hoping that some of you can provide best practices, insights, or other resources that might help me.

There are more questions I need to answer, but since books and Google have not been able to answer my current questions at a level that helps me right now, these are the five questions I will limit myself to. Happy holidays and thanks in advance!

Edit: after some reflection on the initial responses I received to my questions, here is a revised version of my question for anyone who might come across my post in the future.

1. I am familiar with developing very small distributed systems with limited functionality using RabbitMQ/Java. Now I'm looking for some good resources for developing (scalable) web applications using the JavaScript front- and backend ecosystem. Does anyone have resources in mind that include an introduction to relevant system design concepts for developing (scalable) web applications using the JavaScript ecosystem?

2. Does anyone have some good SaaS flowcharts that would help me get started with my first Saas idea?
MVP would be mobile first, just a handful of features that don't require complex onboarding or complex database operations. From my research, customers include startups, small businesses, and freelancers with a particular focus on those that are in the early stages or don't have strong growth yet.

3. Preferably someone has some information on how to get from the development environment - which consists of front-end and back-end on two Node.js servers running on localhost - to an actual production deployment (previously managed by another team in my day job). What are some good resources for the Express.js/Node.js + Next.js case?

4. Should I start with a separation of frontend and backend code or should I use Next.js for both my frontend and backend in the same codebase?
More specifically, frontend and backend with separate APIs? What are the best practices for SaaS applications?

5. How much time should I spend on system design at the very beginning when trying to code my first SaaS with JavaScript front-end and back-end frameworks?
Should I focus on making it functional at the beginning, or can you give me recommendations on what system design patterns I can include from the beginning without over-engineering my MVP?

on December 26, 2021
  1. 1

    These are non-trivial questions but here are some answers:

    1. Online of course. Pick a tech stack that you are comfortable with. Once you understand how it works, you can interchange skills to different platforms/products/services. Unlike most from bay area, I actually recommend Microsoft as they are one shop that does everything in pretty much all kind of patterns, platform, product/services.

    2. Find out what you want to build first, then determine which stack is most suitable. You need to know basic authentication on how it works. You don't need to know how scalable database is going to work (at the start). Basically, I'd recommend you have decent solid foundation but you don't need to know all the details to start. You can learn along the way when you need it.

    3. Depends on what your requirements. Again, don't need it until you need it. Expect your product to be re-architected many many times.

    4. Have opinion on code quality.

    5. I'd say stay on MVP first and worry about architecture later. Once your idea is proven and revenue is coming, you can decide on how you can spend on architecture relative to how much you can spend

    1. 2

      @Alienroid I appreciate your answer very much! Based on your advice, I'm going to look into the tech stack and make my requirements more clear. It's very good to be reminded of "don't need it until you need it", it keeps you focused on going forward.

      And, very interesting take on Microsoft, that I haven't heard before!

      1. 2

        Hmm I disagree with almost everything @Alienroid said depending on your reasons for wanting to build an app. Some typical reasons:

        • Experience to help you in your job or get a new one
        • To build a business out of it
        • Fun and working with others

        For most of those reasons there are strong arguments for not building something throw away. Anyway you would have to give a lot more detail if you want useful advice.

        1. 2

          I agree with @disrael that whatever I said was all over the map (due to lack of requirements I guess). I am also opinioned and biased ;)

          One thing I realized over the years is that different cultures approach problems and learning differently. I am educated in Asia (Taiwan) and Canada. For most, I'd say my education approach is more design and planning first, closer to European approaches. What I find in US or California in general is that often times they just hack first without planning. The problem is to address the turn around cycle. Once that's addressed, things would fall in place. TLDR; people think differently and just got to keep an open mind and learn. Good luck!

          1. 1

            This comment was deleted 3 years ago

            1. 1

              funny story... at my previous employer, one time, so many people complaint about the code base and they decided to do a rewrite (in secret). 8 months to a year later, code doesn't even work. So the lesson is never to touch that legacy code again.

              It's a critical infrastructure technology and i've seen a super important file that has 32k lines of code. If you remove a line from that file, shit would not work. No one knows why. No one dares to bother. It's been tried many many times... lol

              1. 1

                This comment was deleted 3 years ago

                1. 2

                  cellular technology that runs the world. You need to understand why any changes to a file will affect the output to understand the magic.

            2. 1

              @ShaneBellone What does your design process look like regarding your average LOC/Day? And, could you elaborate on "It is too bad programmers don't get paid to remove code. Tech would look very different"?

              1. 1

                yeah LOC is really poor measure. I was a BIOS engineer and my 50 lines of code in x86 asm can't be beaten by any language in performance nor size.

              2. 1

                This comment was deleted 3 years ago

                1. 1

                  Wow, this is a new angle for me. I'm just starting my indie hacking journey, but this is exactly the kind of input I was hoping to hear here on this platform. Exciting views!

                  1. 1

                    This comment was deleted 3 years ago

        2. 1

          @disrael Thank you for sharing your views! What details would you need to give useful advice?

          1. 1

            You said it yourself:

            I realize that some questions need to be answered in a more specific context, but I am hoping that some of you can provide best practices, insights, or other resources that might help me.

            You haven't asked anything that doesn't require more specific context. There is no such thing as general SaaS building.

            1. 1

              You are right. I hope to generalize a lot of things starting out so I can have some sort of blueprint for future projects. But it's good to hear from people who have already started some time ago that my magic SaaS blueprint is perhaps too generalized.

              1. 1

                Instead of asking for a SaaS blueprint you would be better off asking for a SaaS flowchart. There are categories like pure mobile versus mobile and desktop or B2B versus B2C that can help narrow down what you need to think about.

                1. 1

                  Would you happen to have said SaaS flowchart?

                  1. 1

                    Only the branches we took:

                    Desired startup and programming experience => chose stack of React / PWA / AWS Python Lambdas / DynamoDB => learning curve but very scalable

                    You could go that way - ask everyone to answer three questions:

                    1. What was your motivations for building SaaS?
                    2. What stack did you choose?
                    3. How did that stack work for you?
        3. 1

          I mostly agree with what @Alienroid and @disrael have said, but I'd like to add on the following tips:

          • Pick a stable, established framework and spend time getting to know the ecosystem. "Boring technology" is your friend as it will be easier to find support and existing solutions.

          • Pick a simple, stable open source project that you know and try to write your own clone (wordpress, cal.com, ghost, etc.). Compare your solution to the currently publicly used version. Reading lots of code helped me tremendously.

          1. 1

            @jansroka Wow, thanks for those quick tips! I like "reading lots of code", I need to do that more often to see how others might approach a solution.

      2. 1

        The thing with bay area is that we keep hearing about the latest, new things/stacks to try, then it dies or another better one comes along. Most of them are so half baked that over the years, you often wonder if you just waste bunch of time on crap. You don't need to do that with Microsoft, most of their stuff works well together, with long support cycle. At least that's what I find. By the way, this new Microsoft is not the old Microsoft people use to hate. I urge all devs to try their stuff. At least not being ignorant about it.