Are you on top of your tech stack?

I read quote that has stuck with me:

"Software decisions are business decisions."

Treat software choices with the same weight you would any other tangible business decision. They hold the same weight (if not more in software-focused biz).

Here's a quick cheat sheet of the top of my head for how to make software/tech stack choices:

• What do I need my software product to do?

• What does this framework let me do that I can't without it?

• What CAN'T I do without this framework?
  Note: lots of technologies simply let you shave off a month or two from development time. for a bootstrapped business, this can be a 20-33% reduction in development time. So even if you technically can code something by hand, you have to weigh the value of your time against the opportunity cost of spending your own time rather than another framework.

• How will this affect my users?
  Note: Some of the bigger frameworks add a non-negligible SYNCHRONOUS load time measured in hundreds of ms (if not outright seconds for shaky connections). Measure and decide for yourself -- this is a big factor for me but YMMV.

• Do I trust this codebase to be supported in the future?
  Note: this is why I end up avoiding most frameworks/libs myself. I've been on the net for like 20 years and I've seen just how ephemeral most new technologies ACTUALLY are, no matter what they SAY in the NOW...

Always keep the sunk cost fallacy in mind. If you realize that going down a technical path is the wrong decision, stop going down that path. Sunk costs are irrelevent.

Falling prey to the "Well I already spent $xx and x hours" will only hurt you in the long-run.

I have spent 1-2 weeks building a software tool then immediately dropped it when a better solution came along. It sucks, but it's the right decision.

I can easily see billions of $$ and time going down the drain across the world because of choosing a wrong tech stack or not using whats already available..

I had posted this on HN. Look at this interesting comment someone made.
In 2009 a company I worked for operated several coupon/deal sites and they published affiliate links on them. They had a team of several editors who monitored a shared email account that received updates from the various affiliate programs. In order to keep track of which emails had been read by each editor, they hired a contractor who built a custom Ruby on Rails app to read the inbox, ingest the emails into a database, and display them in a dashboard so they could be assigned to users and tracked. The paid tens of thousands of dollars to have it created. When I was hired, the first thing I asked was, why didn't you just use Email Center Pro (now Outpost) for $10/month?

I think you simply need a few things:

1. A good understanding of system/distributed design
2. Be curious and read books/forums/github trends
3. Always schedule some refactor time (not rewrite from scratch time)

Right now there are many stacks you can use that are "modern" stacks out there right now, but you can use pretty much any of them with a good design. Java is still strong for API dev.

In summary, make sure you have an API language, a front End language/framework (Vue, React, etc), a DB, A Queue system and a Cache system (Redis, memecache).

Once you have this components separate, you can pretty much build anything and just refactor to newer languages/framework if you calculate you need them (which you might not unless you are doing heavy computations/big data then go back to Go, Java, C++)