What is the difference between adapting a platform and custom development?

Adapting a platform means changing an existing product within the limits it allows — fields, workflows, automations and sometimes code inside the platform — while the vendor keeps maintaining the base. Custom development means the system is written from scratch for your process and delivered to you as code, with no product dependency. The practical difference: on a platform the customization investment is locked to it; with a custom build the code is yours, and so is the responsibility to maintain it.

When is a custom CRM worth building instead of using an existing product?

Almost never because of contact and call management — off-the-shelf products do that well. A custom build is justified when your sales or service process differs in a way that sets you apart with customers, when the system has to talk to internal systems that have no ready interface, or when customers and suppliers themselves use it and their experience is part of the product. Even then, the answer is often an off-the-shelf CRM for the standard part and custom development only for the unique process.

How do you compare the cost of an off-the-shelf system with a custom build?

Pick one period — three years, for example — and fill in five lines for each route: licensing, implementation, integrations, maintenance and change. Fill in the licensing line from license terms you have actually checked, including expected user growth; fill in the build line from a quote based on a scope document. The right comparison is between the totals for the period, not between a monthly price and a development quote.

What is the biggest risk in adapting a platform?

Customizations piling up beyond what the platform officially supports. Every release upgrade becomes a test of every customization, and over time the organization avoids upgrades — and is then stuck with an old version and an investment that cannot move to another product. The practical rule: if a customization requires code inside the platform, first ask whether that part would be better built outside it and connected through an interface.

Can you start with an off-the-shelf system and move to a custom build later?

Yes, and sometimes it is the right path — especially while the process itself has not yet stabilized. The condition is checking export capability up front: which data can be taken out, in what format, and including which files and history. Whatever cannot be exported today will not move to the next system. It also helps to document the process as it actually runs in the off-the-shelf product — that is the best scope document you can bring to a development project.

What should you bring to a first meeting about this decision?

One page: the process as user actions, who the users are and how many, where the data lives today and which system is the source of truth for each entity, and which existing systems must not be replaced. Without it, every meeting becomes a conversation about features. With it, the three routes can be covered in one meeting and you leave with a decision — or with one defined question that still needs checking.

GUIDE · BUSINESS SYSTEMS · DECISION

Buy a system, adapt a platform or build from scratch?

The right comparison is not between products. It is between three ways of running the same process — over time.

Onezero LabsOctober 22, 2026Updated October 24, 202610 min read

The short version — three routes, six items
Item	Off-the-shelf	Adapted platform	Custom build
Fit to the process	The process adapts to the product	Mostly standard, exceptions configured	The system is built around the process
Time to first use	Shortest	Depends on customization depth	Longest — built in stages
Integrations	Only what the product offers	Ready connectors + custom at the edges	Any interface you define — your responsibility
Cost over time	Recurring licenses that grow with users	Licenses + keeping customizations alive per release	Upfront build + maintenance and change
Data export and ownership	Whatever the vendor allows	Data exportable; customizations are not	Data and code are yours
Vendor dependence	High — pricing, features, continuity	High — the investment is locked to the platform	Dependence on the maintaining team, not on a product

"Buy or build" is usually asked too early — before it is clear what exactly would be bought or built. The result is a comparison between a monthly license and a development quote, two numbers that do not measure the same thing. An off-the-shelf system is measured by how much the business will have to change to fit it; a custom build is measured by how much the system will have to change when the business does.

This guide proposes a different order: first define one process — not "a system to run the business" but a specific process with a start, an end and users — then examine three routes on that same process, against the same six items. There is also a section on when not to build, because that is a perfectly legitimate answer.

Define the process and its constraints — before comparing

Comparing routes is only possible when there is something to compare against. Three things should be written on one page before you open anyone's product page:

Core actions — five to ten actions the process must support, phrased as a user would: "a rep enters an order", "a manager approves a credit exception", "the warehouse marks the order as picked". Not features, not screens.
The users — who touches the process, how many they are, and how their permissions differ. An external customer and an internal employee are two different worlds for every route.
The data — which entities the process manages (customer, order, product, document), where they live today, and which system is the source of truth for each. If the ERP is the source of truth for inventory, no route exempts you from connecting to it.

Then the constraints: regulation (privacy, data retention), existing systems that must not be replaced, budget and the decision horizon. Constraints are what turn a list of three theoretical options into the one or two that are actually open.

Three routes on the same process — an example

A wholesale distributor takes orders from business customers by phone, email and text message. The process: a rep enters the order → the system checks stock and credit → a credit exception goes to a manager for approval → the order moves to the warehouse for picking → an invoice is created in the existing accounting system. Users: six reps, two managers, the warehouse team and — in future — the customers themselves, entering orders through a portal. Data: customers and inventory live in an existing ERP that is not being replaced.

Same process, three routes. 'Risk' is what can go wrong on each route — not a forecast.
What we look at	Off-the-shelf order system	Adapted CRM/ERP platform	Custom build
Capability	Order entry, stock and basic approvals from day one. A familiar interface for reps.	Approval flow, customer fields and reports configured to the business. No-code automations for most cases.	The exact process — including credit exceptions by company rules and picking in warehouse order. A customer portal as part of the same system.
Limitation	Credit exceptions by company rules are probably unsupported. ERP connection only if an official connector exists.	Whatever cannot be configured needs code inside the platform — and that must be maintained through every release.	Nothing exists on day one. Every report, screen and role is built. Time to first use is the longest of the three.
Risk	The business changes its process to fit the product — then discovers the exceptions were what set it apart from competitors.	Customizations pile up until the platform no longer behaves like the product that was bought — yet it cannot be left either.	Scope that grows without limit during definition, and dependence on the team that knows the code if there is no documentation and orderly handover.
When it fits here	If the company is willing to handle credit exceptions outside the system and a customer portal is not planned.	If such a platform already exists in the organization and the exceptions can be configured without code.	If the order process and the portal are part of the service the company sells to its customers.

Notice what is missing from the table: prices. Not because they do not matter, but because at this stage there is not yet enough definition for any figure to be reliable. Cost comes in the next section — as categories on a timeline, not as sums.

What does it cost over time?

To compare cost across routes, pick one period — three years is a common reference, because within it releases, people and at least one business requirement will change — and fill in five lines for each route. Some lines will be empty or estimated; that too is information.

Five cost categories. No figures — these are variables you fill in from quotes and license terms you have actually checked.
Category	Off-the-shelf	Adapted platform	Custom build
Licensing	Per user or tier, monthly or yearly; rises with growth and with each added module	Platform licenses + sometimes separate licenses for customization modules and test environments	No product license; cloud infrastructure and third-party services (email, payments, maps) by usage
Implementation	Settings, initial data import, training. Usually short	A project in its own right: specifying customizations, configuration, testing, training — often via an implementation partner	Part of the build: specification, staged delivery, data migration, training and handover
Integrations	Ready connectors — if they exist — sometimes at extra cost; what is missing stays missing	Platform connectors + interface development for every system without one	Every connection is built and maintained by you; a documented API is a very different job from a system with no interface
Maintenance	The vendor's responsibility; you deal with changes the vendor decides on	The vendor maintains the platform; you maintain the customizations and test them on every release	Yours, or under a maintenance agreement: dependency updates, security, monitoring, backups
Change	Only what the vendor adds; your request joins a waiting list	Change within the platform's limits — fast; beyond them — expensive or impossible	Any change is possible; the cost depends on the quality of the code and documentation you received

The common mistake is to compare the licensing line of an off-the-shelf system with the build line of a custom one and stop there. The line that usually decides is "change": how many times in three years your process will change, and what happens each time.

Ownership and control: data, export, dependence and transfer

Four questions worth asking before signing on any of the routes — and the answers differ sharply between them:

Whose data is it, and in what format can it be exported? A CSV export of the customer table is not the same as exporting order history, attachments and the audit log. Ask to see a real export before buying.
What happens when the vendor changes pricing, drops a feature or shuts down? For an off-the-shelf system this is a business risk that needs a fallback plan. For an adapted platform, the investment in customizations is lost on the way out. For a custom build the risk shifts to the maintaining team — which is why documentation and handover are part of the product.
Who can change the system tomorrow? If the answer is "only the vendor" or "only the developer who built it" — that is dependence, regardless of the route chosen.
How would the system be transferred to another team? For a custom build that means: a repository in your name, cloud accounts you own, operating documentation. For an off-the-shelf system it means: an export-and-import plan to another product, tested at least once.

What is handed over at the end of a development project — code, access, documentation and a list of what was built against the scope document — is described on our service page. It is also what you should demand from any development vendor, not just us.

Custom software development — how scope is defined and what is delivered

When not to build?

Custom development is the most expensive and slowest of the three decisions, so it needs a positive reason — not just discomfort with an existing product. These are the conditions under which an existing product is probably the right answer:

The process is standard in your industry and contains nothing your customers specifically pay you for. Invoicing, payroll, internal task management, email — almost always an existing product.
You are willing to change the process. If you can work the product's way without hurting customers, that is cheaper than building your own way.
The users are a small internal team that can be trained and supported — not customers or partners whose experience is part of your product.
There is no certainty yet that the process will stay as it is. While the business is still finding its way, a cheap off-the-shelf product is a cheap experiment. A custom build locks in decisions that have not been made yet.
Nobody will own the system after handover. A custom system needs an owner inside the organization and a maintenance budget. Without both it ages faster than an off-the-shelf product.

What a system built around a process looks like — a real example

When the process runs in a browser for customers, employees or partners — a portal, an admin system, a B2B system — the discussion about users, permissions and integrations continues on our web-systems page.

Web systems and portals — users, permissions, processes and integrations

What we do at this stage

Before pricing any development we map the routes for your system together: the process, users and data on one page; the three routes on the same six items; and which part of it actually needs to be built. Sometimes the outcome is a recommendation not to build — or to build only a part. If development is the way forward, the scope document written here is the basis for the proposal.

FAQ

Frequently asked questions

Let's talk

Got a project to scope?

One conversation. You leave knowing what the first version needs to contain and what it will take to build it.

Straight. To the point. On time.