Pick a tool that fits the job

Shrishti and I were on a call, going over draft posts for Microapp. One was about no-code tools. These let you build an app by moving pieces around on a screen, without writing all the code yourself.

A line in the draft said a tool had trouble when too many people used it. I stopped there. That wasn’t the problem I wanted to explain.

The problem was that the tool was hard to change for a special need. A tool that can’t handle more people and a tool that can’t do what you need are two different things. If we mixed them up, the reader would walk away with the wrong idea.

I didn’t want to make no-code sound bad, either. I think it can be a good choice. Say you need a simple list of tasks. If a tool helps you make that list fast, great. You can get on with your day.

But say the list needs to work in a very different way. Can you change it? How much work will that take? That’s the part I wanted our post to help someone think through.

I also asked about a number in the draft. Where did it come from? If I’m going to put my name on a post, I want to know what we’re asking the reader to believe.

We were working on a post, but I kept coming back to the same question I ask when picking a tool: what is the person actually trying to do? I want to understand that before I tell them what to use.