Software and automation for small teams

There is a point where a business stops needing a website and starts needing software, and it is not marked by size or revenue. It is marked by the moment the work stops fitting in a spreadsheet that three people are editing at once.

The first article in this section is about telling those two apart, because getting it wrong is expensive in both directions: building a platform for something a good site would have solved, or patching a site for two years to do a job it was never designed for.

From there it goes practical. How to scope an MVP so the first version costs what a first version should — which is mostly a matter of what you agree not to build yet. And the automations that pay for themselves fastest in a small team, which are almost never the impressive ones: a WhatsApp bot that answers the four questions asked forty times a week, an invoice that fills itself in, a lead that reaches the right person without anyone copying it across by hand.

The bias here is towards the boring answer. Most businesses do not need custom software. The ones that do usually needed it eighteen months before they admitted it, and by then they are paying for it in staff hours instead of in a build.

A practical filter before commissioning anything: write down the process you want to automate, by hand, step by step, including the exceptions. If it fits on one page and the exceptions are few, it's probably an automation and it's cheap. If the exceptions fill a second page, it's a product, it costs what a product costs, and it should be built in stages with something usable at the end of each one.