1. 17
  1. 5

    As a solo entrepreneur, I can confirm: you have to be absolutely ruthless in cutting scope and avoiding feature creep. Maintenance will eat all your time. For instance, my billing site does not support logins, does not use a database, etc. just the bare minimum to CRUD Stripe subscriptions.

    1. 4

      This is a good article, I made most of the same mistakes with a failed SAAS I worked on a few years ago. You’ve really really got to keep things simple for the MVP.

      1. 3

        I discovered that creating a backend API and rich client side single page app (SPA) came with a ton of overhead.

        My flow with Ember was like:

        1. Figure out the data model for the next feature.
        2. Create models in Django.
        3. Create JSON APIs in Django.
        4. Create models again on the client side with Ember Data.
        5. Decide on the routes and controllers to finish the user interface for the feature.

        I’ve been working on a personal project, and I’ve chosen Postgres, Hasura (GraphQL) and Typescript. My API creation (actually, I don’t have to create APIs anymore) looks like this:

        1. Create Postgres schema for new feature
        2. Develop GraphQL query in GraphiQL, copy into Typescript code.

        I get my Typescript types automatically constructed from the query, and the GraphQL schema is automatically created by Hasura. It’s such a fast development process, and it’s also type-checked! It’s been a complete revelation for me, coming from a background akin to what the author experienced with their API development.

        Granted, I haven’t got much in the way of business logic - my app is very CRUDy.

        1. 3

          Why take on building out a backend api and SPA at all if your goal is to keep maintenance minimal and simple? Server rendered or hybrid both seem like dramatically simpler choices than full blown api/spa. Especially given author’s django experience.

          Also (having done my fair share of CRUD apps) if you’re doing largely CRUD/form-over-data work, then how necessary is a SPA really? Personally, if I was the sole-developer on a project that could potentially be more than a hobby, then I’d consider refactoring to a richer UI if, and only after, I had a product with legs (and paying customers).

          1. 4

            In general I’ve never understood the point in building SPAs for things that are inherently multi-page, like web apps with lots of CRUD and the like. SPAs are good for interactive things like dashboards and so on, in my opinion. Otherwise they’re just a maintenance overhead, useless code.

            1. 1

              In my case I omitted that I’m using Next, so I am actually building a server-rendered app. But I get to do it with React - which I am very familiar with, and I vastly prefer JSX to Jinja or Handlebars (also: type-checked).

              For small, CRUDy apps there’s a good chance even a small cheap VPS instance will execute database queries and render HTML more than quickly enough.

              1. 1

                I haven’t seen NextJS yet, but I agree that react/jsx are a lot more pleasant to work with than the templating offered by most server-side frameworks. I can definitely see the appeal of rendering react server-side. I’m also on the fence regarding graphql, but my experience with it is limited. But, like NestJS, Hasura is another one I haven’t encountered yet. Great info - two items I need to check out!

              2. 1

                I don’t find building a sever rendered thing to be particularly easier than building an SPA if there’s going to be at anything interactive on the front end, which has been the case for like 80%+ of the things I’ve made.

                1. 3

                  It depends on the app. As mentioned above, inherently interactive apps like dashboards readily lend themselves to SPAs. In my experience CRUD apps generally don’t, but that’s probably debatable. However, I would argue that for the moment anyway, server-rendered is likely the simplest solution for this class of app. The tooling is more straightforward, frameworks less prone to breakage, and maintenance is easier (i.e., it’s boring). Experience is a prominent factor, though, and the TFA describes not being intimately familiar with at least two critical pieces of the stack chosen.

            2. 3

              I can totally relate with the “too low energy to work on meaningful stuff” part:

              I’d spend a long day working at my day job and doing a lot of software development there. Then I wouldn’t have the energy to make real progress on my app, so I’d tell myself that upgrading one of the packages that was out-of-date was a good use of my time.

              I think the solution is finding and arranging dedicated time for the sideproject. For example, go from full-time to part-time, and make the side-project your other, equally important “day job”.

              1. 2

                I’m submitting this because I think it has some good information about scoping systems for business use.