| Wow, the stack in the article feels like a ton of innovation tokens[1]. I hate to be an armchair expert, but I'll do my best to give the _counter_ opinion to "this is a model of a good startup stack". If you're looking to build a web app for a business on a small team, some guiding values I've found to be successful (that feel counter to the type of values that lead to the stack in the article) 1.) Write as much "Plain Ol'" $LANGUAGE as possible[2]. Where you do have to integrate with the web framework, Understand your seams well enough that it's hard for your app _not_ to work when it receives a well formed ${HTTP/GQL/Carry Pigeon/Whatever} request 2.) Learn the existing "boring" tools for $LANGUAGE, and idioms that made _small_ shops in similar tech stacks successful. 3.) Learn $LANGUAGE's unit test/integration test framework like the back of your hand. Learn how to write code that can be tested, focus on making the _easy_ way to write code in your codebase to be to write tests _then_ implement the functionality 4.) Have a strong aversion from adding new technologies to the stack. Read this [1], then read it again. Always be asking "how can I solve this with my existing tools". Try to have so few dependencies that it would be hard to "mess up" the difference between local and prod (you can go a LONG way with just Node and PostgreSQL). Some heuristics to tell if you're doing a good job at the above points, 1.) You don't have to prescribe Dev tool choices (shells, editors, graphical apps, git flows, etc) 2.) You can recreate much of your app on any random dev machine, and feel confident it acts similar to production. 3.) Changing lines of code in your code base at random will generate compiler errors/unit test failures/etc Most every real world software project I've worked on in the SaaS world ended up with "complexity" as the limiting factor towards meeting the business's goals. When cpu/network/disk etc was the culprit, usually the hard part of fixing it was trying to _understand_ what was going on. Plain may be very successful in their flow, but I'd say most everything in this article runs counter from the ideas that I've seen be successful in the past. [1] https://boringtechnology.club/ [2] At our shop we'd say "You're a ruby programming, not a rails programmer, your business logic is likely well factored/designed if it could be straight-forwardly reworked into a rails free command line app" |