Build, buy or no-code? How to decide before you spend a rupee
A developer's honest decision guide for founders: when an off-the-shelf tool wins, when no-code is enough, and when custom code is worth paying for.
You're a developer, so you'd expect me to say "build it custom". I won't. For most problems, custom code is the wrong answer, and a good developer will tell you so before taking your money.
You have three real options whenever you need software to solve a problem. Each is right in some situations and expensive in others.
The three options, honestly
Buy: an off-the-shelf tool
A product that already exists: an invoicing app, a booking system, a CRM. Fastest to start, cheapest to start, and tested by thousands of other users. The cost is that it works the way its makers decided, and pricing often grows with your team size.
No-code: connect existing tools
Tools like Zapier, Make or Airtable let you link apps and build simple workflows without programming. Great for low-volume, low-risk automation that you want running this week. The cost is limits: complicated logic gets messy, and the per-task pricing can climb as you scale.
Build: custom code
Software written for exactly your process. Highest upfront cost and slowest to start, but it fits perfectly and you own it. It's the right choice when the thing is central to your business, or when off-the-shelf tools fight your process.
Find your answer
Answer these six questions about the specific problem you're solving. There are no trick answers. The tool weighs your answers and shows which option fits and why.
How common is this problem?
How central is it to what makes you different?
How many tools must work together?
How much volume do you expect?
How soon do you need it?
What's your budget like?
Answer the questions to see a recommendation.
The hidden costs people forget
- Per-seat pricing. A tool that costs a little for two people costs a lot for twenty.
- Glue work. Buying five tools means someone has to keep them talking to each other. That someone is usually you.
- Switching costs. The longer your data lives in a tool, the harder it is to leave.
- Maintenance of custom code. Software needs updates, security fixes and a person who understands it. Budget for it, or pick a developer who offers it.
- The cost of waiting. If a problem costs you ten hours a week, a fast imperfect fix often beats a perfect one in three months.
A pattern that works
My default advice, for almost every small business, is to start with a bought tool or no-code and graduate to custom only when you hit a real wall.
That wall looks like one of these: the monthly tool bill has grown past what a custom build would cost over a year, the workaround has become a full-time job, or the process is now a real competitive advantage that no tool supports.
When you reach it, you'll have a bonus. You will already know exactly what the system should do, because you've been running it in a rough form. That makes custom builds cheaper, faster and far less likely to miss.
Not sure which way your problem leans? Describe it to me in a couple of sentences and I'll give you a straight answer, even if the answer is that you don't need me.