Picking the right tools to build your product/SaaS is incredibly important. Most people just use the same tools to build every project no matter what it is, and if you're building an MVP or validating a product, sometimes this is perfectly fine! But you should still pause and think a little before selecting the right tools to avoid skyrocketing overhead, technical debt, impossible requirements, etc.

Here's a little insight on my process when I'm planning projects.

Goals

I first create a list of goals. These should not be technical requirements, like programming languages and platforms. Don't think on a technical level yet. These are overall things you are trying to accomplish with the project. Here are three that I almost always start with:

• Scales financially: Scales up and down with the budget/needs of the project. If I'm not making any money yet, I shouldn't have any overhead.
• Collaborative: Hear me out on this one even if you're not collaborating. If you're working on a team, high-collaboration tools mean you don't have to work on other people's problems. If you're working alone, high-collaboration tools mean you can outsource when you make it big or go through life changes. This one can protect you from disaster no matter what happens.
• Efficient: The tool should be fast at the job its doing, and not require much or any maintenance. I don't want to work on the tool itself, I want to build with it.
• Optimized for change: There are no perfect solutions, and your needs will change over time. You can sidestep a lot of problems by making sure all tools and platforms you use are easy to swap out when the time comes.

All projects are unique, and usually require additional goals. So I make sure to adjust my goals for each unique project.

Features

Now that I've identified what my goals for the project are, I identify features that are commonly seen in the software that get me closer to those goals.

• Web-based: Helps me move much quicker, and easy/cheap to outsource.
• Skill-agnostic: For me, this usually means no/low-code tools when possible. Anything that's efficient and easy/cheap to outsource and collaborate with.
• Free plan available: I don't want to pay if I'm validating an idea and don't have customers yet.
• Shareable: It should be easy to share account control to another employee/freelancer.
• Modular: No monolithic frameworks. This helps me optimize for change when I need to swap out part of the stack for any reason.
• Popular: I was surprised to find this one was important to me. But to put it bluntly, popularity generally means there is more documentation and free resources available. Network effects are real. Don't just always pick the most popular option without research, but when you're on the fence about 2 options, go with the popular one.

Now think about how different this list would look if even one of those goals in the first section was replaced with a different one. Even one small change would likely lead to completely different features, which would lead to completely different software choices. There is no one-size-fits-all solution for building software, so make sure you're looking in the right places to find what you need.

Prototype

Make a to-do list of every task you will need to do to build your project. Put question marks next to things you're unsure about how long it will take to build, or if it will even be possible.

Select software that has most or all of the features you're looking for and try to build out the parts of your project you're unsure about first. Utilize free trials with everything and just go for it. If you start with the hardest/most unclear tasks first you will very quickly get an idea for which platforms will and won't work for your purposes.

Revise, Revise, Revise

If you use this strategy, you will probably want to edit or add to the features you listed out previously as you discover new issues. This is okay, and a big reason why I go with modular services to build things. If something doesn't work, you don't have to uproot everything you just built, you just replace the one small service that doesn't work for you.

Avoiding Bias

By starting with goals and working your way towards software, you can usually filter out some bias, but not always. For example, most designers will always pick Adobe, and most developers will always always pick code. Bias is normal and expected.

But try to consider the user of the software (the client in many cases). For example, if you're building a blog for a non-technical writer, you should probably avoid giving them something that requires them to edit HTML to make a change on the blog. But if you're building a documentation site for a code library and the only people who will ever edit the documentation are developers, then using code to edit the site is probably fine.

Another example: You absolutely could edit social network marketing images with Ink if you like open source software. This may even be a great option if you're working with a team that is very familiar with Ink. But probably not. Try exploring tools you wouldn't normally use. It's possible using boring tools like Canva would lower the entry barrier and get more people to help you do the things you probably didn't want to do in the first place. If you're working alone and you get overwhelmed, you can find help for dirt cheap if you're using boring tools. The more complicated the tool set, the more likely you are to work alone on your project forever.