MAKIN 
Is this how you compete?
If a customer would never notice the difference, buy it. Build only where doing it your way is the reason someone chooses you. Most build decisions fail this first question and never get asked the other four.
What does it cost to keep, not to make?
Build estimates cover construction and ignore occupancy: upgrades, the security patch, the person who understands it leaving. A rough rule is that the first year of ownership costs about what the build did, every year, indefinitely.
How fast does the requirement move?
Stable requirements suit buying — someone else absorbs the maintenance. Requirements that shift every quarter suit building, because each change to a bought tool is a negotiation with a vendor roadmap you do not control.
Can you leave?
Ask how the data comes out and how long a migration takes. A tool you can exit in a fortnight is a cheap experiment. One holding three years of history in a proprietary format is a structural commitment, whatever the monthly price says.
The fifth question: what does it have to talk to?
The fifth question is about the edges. A build-versus-buy choice can be right on features and still go wrong at the handover to the next system. A bought tool that cannot send invoices to Tally, push leads into your CRM or accept your product codes will be fed by hand, and that manual step becomes a permanent cost nobody budgeted for. Built software carries the opposite risk: every connection is yours to write, and yours to keep working when the other side changes.
- List every system the new tool must read from or write to, and in which direction.
- For a bought tool, check for an API or a scheduled export in a format you can use, not only a download button.
- Ask whether each connection you need is maintained by the vendor or depends on a third-party connector.
- For a build, name the person who will fix each connection when the system at the other end updates.
- Wherever the answer is “someone will copy it across”, count that copying as part of the cost.
Running the five questions as one decision
Take the questions in order and stop early when an answer is decisive. If a customer would never notice the difference, the rest of the exercise is about which product to buy, not whether to build. If it is how you compete, the remaining four decide whether building still makes sense and what to buy around it. Write each answer as a sentence with its evidence beside it, such as a customer comment or a vendor’s export documentation.
Have the right people in the room when you answer. The person who will use the tool daily knows how fast the requirement moves. Whoever runs finance can price occupancy honestly. Whoever maintains your systems today knows what leaving has cost before. A decision taken by one enthusiastic sponsor risks answering the question they care about and skipping the rest.
The options between the two
Build and buy are the ends of a range, and the sensible answer can sit between them, with your own software only at the points where you genuinely differ. Each middle option below inherits some risk from both sides: buying and integrating still ties you to a vendor roadmap, and building on a platform still ties your process to someone else’s product. Ask the leaving question of each piece, not only of the whole.
- Buy and configure: use the tool as designed, and change your process to fit it wherever the difference does not matter.
- Buy and integrate: keep the bought tool, and build only the connections it lacks.
- Buy with source code and extend: start from software that already works, and own the changes you make.
- Build the core, buy the rest: write the part that is how you compete, and use bought services for login, payments, email and reporting.
- Build on a platform: a low-code or workflow tool for internal processes that change often and never face a customer.
Signs you are about to build what you should buy
When the case for building comes from the people who would enjoy the build, that does not make it wrong, but it does mean it deserves a sceptical second reading. These signals suggest the honest answer is buy, however interesting the build would be.
- The argument is that existing tools are “too complicated”, not that they cannot do the job.
- The feature list matches a well-known category: CRM, invoicing, helpdesk, payroll, booking.
- Nobody has written down who maintains it after launch.
- The estimate covers construction and stops there.
Signs you are about to buy what you should build
The opposite mistake is quieter, because a monthly subscription feels reversible and nobody has to defend a large figure up front. It tends to surface later, as workarounds wrapped around the tool. Watch for these signals while you are still evaluating, not after the contract is signed.
- Your team is already describing the spreadsheet they will keep alongside the new tool.
- The demo that won the decision needed customisations or add-ons to show your process.
- The vendor’s answer to your core requirement is that it is on their roadmap.
- The workflow is the thing customers praise you for, and the tool would make it look like everyone else’s.
Write the decision down and give it an expiry
Record the decision on a single page: what you chose, the answer to each of the five questions, the alternatives you rejected and what would make you revisit it. That last line matters most. A vendor changing its pricing model, a requirement that starts moving every quarter, the one person who understood a system handing in notice: name the triggers now, so the review happens when they occur rather than two quarters later.
If you would like the questions run with someone outside the argument, our Tech Strategy Consultation covers architecture, build-versus-buy and a roadmap, starting at ₹3,000. Where you are inheriting software rather than choosing it, Technical Due Diligence, from ₹23,000, establishes what the codebase actually is before you commit to it.