Build, buy or configure

Most build-or-buy advice is written by whoever profits from the answer. These guides give the honest call for each situation, including the many where buying an off-the-shelf product is obviously right.

Should we build a custom CRM or use Salesforce? Buy Salesforce if your process is a recognisable sales process — leads, opportunities, stages, a close. Build custom if the thing you track is not an opportunity at all: a file submitted to several parties at once, a matter with statutory deadlines, a unit with a service history, a placement with a margin. The deciding question is not company size or budget. It is whether your core object exists in the standard model.

Should we build a custom CRM or stay on HubSpot? Stay on HubSpot if your problem is attracting and converting leads. Build alongside it if your problem starts after the deal is won — fulfilment, documents, compliance, recurring service, anything with a state that is not a pipeline stage. HubSpot is a marketing and sales platform that also stores contacts. Most firms who outgrow it have not outgrown the marketing half at all.

Should we buy software or have it built? Buy when the problem is common, the category is mature, and your version of it is ordinary — accounting, payroll, email, e-signature, helpdesk. Build when the process is the thing customers actually pay you for, when no product models your core object, or when the category tools all assume a business shaped differently from yours. Everything else is configuration, which is neither and is usually the cheapest correct answer.

How much does custom software cost? Any firm quoting a figure before understanding your scope is guessing. What genuinely moves the number is scope, integration count, data migration quality, compliance requirements, and whether you need a prototype or a production system. The most useful thing you can do is get two firms to quote the same narrowly-defined first deliverable — comparable quotes tell you far more than a range ever will.

Is it time to replace our CRM? Replace it when people are keeping the real information somewhere else — a spreadsheet, a notebook, a group chat — because the system cannot hold it. That is the one signal that reliably means the tool is wrong. Poor adoption, messy data and unhappy users are usually process and ownership problems, and they will follow you to the next CRM.

Should we configure what we have, buy something new, or build? Configuration is the answer far more often than either vendor will tell you, because nobody makes money recommending it. Try it first, deliberately and with a deadline. Buy when the function is a commodity. Build only when you can name the specific object or workflow that no product models — and then build only that, not everything around it.

Should I keep automating with Zapier or have it built properly? Zapier is the right answer until the volume, the branching, or the debugging costs more than the build would. The usual tell is that a person now babysits the automation. Prototype in Zapier. Move it when it starts needing a babysitter or when the task bill grows with your success.

Should I hire a freelancer, an agency, or a developer on staff? Freelancers are the cheapest way to get one defined thing built. Agencies are how you buy a team without hiring one. In-house is right when software is a permanent part of how the business runs, not a project. Scoped and finite, hire a freelancer. Broad and time-boxed, hire an agency. Permanent and central, hire in-house.

When should we stop running the business on spreadsheets? Move when more than one person needs the same truth at the same time. Spreadsheets are an excellent thinking tool and a poor system of record. Keep spreadsheets for thinking. Move to a system the moment two people depend on the same numbers.

Is Airtable enough, or do we need a real database? Airtable is a genuine step up from a spreadsheet and a genuine step below an application. It holds until the number of records, the permissions, or the logic outgrows what a table view can express. Use Airtable to find the right shape. Build when people need screens for their job rather than a view of a table.

Can a broker or lender run on a generic CRM? A generic CRM models a contact and a deal that closes once. Brokered finance models a merchant who comes back, several products in flight at once, and submissions to many funders per file. Those are different shapes, and the difference is where generic CRMs break. If your team creates a second record for a returning merchant, your CRM does not model your business.

Should I hire offshore developers or work with someone local? Offshore buys hours at a lower rate. It does not buy fewer hours. The decision turns on how well you can specify the work, because specification is the cost that offshore does not reduce. Choose it when you can specify precisely, and not otherwise.

Can AI build a CRM? Yes. AI can genuinely build a working CRM now — screens, records, pipelines, the whole application — and that is exactly why the build-vs-buy line has moved. What AI does not do is own the decisions: the data model for your business, who is allowed to see what, the connections to your phone, email and accounting, and the migration of the records you already have. A wrong decision generated faster is a faster wrong decision. The realistic question is not whether AI can build it but who owns the mistakes.

Can AI build a website? Yes. AI website builders produce a working site in minutes, and AI-assisted development produces custom ones in days. For a simple brochure site — who you are, what you do, how to reach you — a builder is often the right call, and hiring anyone would be a waste. It stops being enough at three points: when the site has to sell, when it has to be found, and when it is really software wearing a website. Which of those applies to you decides everything else on this page.