Should I build custom software or use an existing SaaS product?

Use the product if it covers most of the requirement and the gap is preference rather than operation. Build when the workflow is the client's differentiator, when several tools are being joined by manual work, or when data has to live somewhere specific. Compare current subscription spend plus manual labour against build cost plus annual maintenance.

Who owns custom software built by an agency?

It depends entirely on the contract, so make it explicit. Best practice is that the client owns the code, the database and the deployment accounts once paid, with everything hosted on mainstream infrastructure under credentials they hold. That removes lock-in concerns during the sale and makes the end of any relationship administrative rather than contentious.

How much does it cost to maintain a custom internal tool?

Maintenance is ongoing rather than optional: dependency and security updates, third-party API changes, credential renewals, and performance work as data grows. Most agencies price it as a monthly retainer covering hosting oversight, updates, a small allowance of changes and a response commitment, with new features billed separately at an agreed rate.

What should be in the first version of a custom CRM?

Three core objects and the relationships between them, for example customer, job and technician. Version one should create and list those records, filter them, move them through statuses, and produce the one report the client currently assembles by hand. Everything else belongs in a version two with its own scope and price.

All field notes

June 19, 20267 min read

Reselling Custom Software: CRMs, Portals and Ops Tools Under Your Brand

Clients ask for software more often than they realise. We want all the jobs in one place. Our technicians are texting photos to the office. We need a portal so clients stop emailing us for files. Those are software briefs wearing everyday clothes. You can route them to an off-the-shelf tool and take no margin, or you can build the thing they described, put your brand on it, and deepen the relationship.

Custom Software
White-Label
Pricing

When Bespoke Beats SaaS

The default answer should be an existing product. If a mainstream tool covers most of the requirement and the remainder is preference rather than operation, sell the product, charge properly for configuration and migration, and move on. Being the agency willing to say that buys more trust than a build you talked someone into.

Bespoke wins under specific conditions. The workflow is genuinely the client's differentiator rather than a generic process. They pay per seat for a large platform and use one module of it. The data has to live somewhere particular for contractual reasons. Several tools are held together by a person copying between them. Or the process has a shape no product models: staged approvals, unusual pricing rules, an industry-specific record that maps onto nobody's contact object.

Apply an economic test before the design conversation starts. Take the annual subscription spend across the tools being replaced, add the labour cost of the manual work between them, and compare against build cost plus realistic annual maintenance. If the payback stretches past a couple of years on the client's own numbers, recommend against it.

The Three-Objects Rule

Most operational software is three objects and the relationships between them. A field services business: customer, job, technician. A clinic: patient, appointment, practitioner. A recruiter: candidate, role, placement. A wholesaler: product, order, customer. Ask the client to name their three and the scope starts drawing itself.

Everything else is an attribute of one of those objects, a status it can hold, or a view onto them. That reframing is a scoping tool as much as a design one. If the client's answer contains nine objects, you are either looking at three projects or at an ambition rather than a specification, and it is far easier to have that conversation now than after a fixed price has been agreed.

Version one should do a small number of things well with those three objects: create, list, filter, change status, and produce the one report the client currently assembles by hand. That last item is usually the thing they show other people. Anything beyond it belongs to version two, and version two is a separate conversation with a separate invoice.

Who Owns the Data

The client should own the database. A mainstream Postgres, in a project on an account they control, with credentials they hold. They should be able to log in and export everything without asking you, and without a line of code from your team. Anything less turns a system they bought into a system they rent.

Commercially this is one of the strongest positions available to you, and it costs nothing to give. When you tell a client they will own the code, the database and the deployment account, you separate yourself from every subscription product they are comparing you against, and from any agency that keeps clients tied through infrastructure. Ownership is also the answer to the objection you will hear most: what happens if you disappear.

It protects you as well. Relationships end for reasons that have nothing to do with quality: budgets, acquisitions, a new marketing director with a preferred vendor. When the client already owns everything, the ending is administrative rather than adversarial, and you keep a reference instead of gaining a dispute.

Maintenance Is a Line Item

Software rots even when nobody touches it. Dependencies get security advisories. Browsers change behaviour. Third-party APIs deprecate endpoints. Certificates and credentials expire. Data volume grows until a query that was instant on launch day becomes the reason someone complains. None of that is a defect, and all of it is work.

So sell a support agreement alongside the build and present it at proposal stage rather than after handover. A monthly retainer covering hosting oversight, dependency and security updates, a fixed allowance of small changes and a response commitment for outages is easier for both sides than per-incident billing: the client's cost becomes predictable and your workload plannable. Define in writing what counts as maintenance and what counts as new feature work.

If a partner built the system, arrange the maintenance path before handover rather than after it. Decide whether they hold retained hours for you, whether your own team takes it on with a documented walkthrough, or both. The worst version of that conversation happens at nine in the morning on a day something is broken.

Packaging So a Non-Technical Buyer Can Say Yes

Sell the outcome, then show the objects. A proposal that works contains a one-line description of what the system does, the three objects it manages, five to eight screens named in plain language, an explicit list of what is not included, and the handover contents. That is enough for a business owner to picture using it, and short enough that they read all of it.

Get a working staging link in front of them as early as the commercial structure allows. Nothing sells software like clicking it, which is why we scope a narrow pilot before any full contract at Kronx. A screen carrying real field names and the client's own terminology does more than a page of description, and it surfaces misunderstandings while they are still free to fix.

Avoid feature lists written in engineering vocabulary. Nobody has ever bought role-based access control. They buy the sentence underneath it: your office manager sees every job, your technicians only see their own. Translate every technical capability into the person it affects and the thing it stops happening.

Pricing a Build the Client Keeps

Fixed price for a clearly defined version one. Clients buying their first custom system need a number they can approve, and time and materials asks them to sign a blank cheque for something they cannot yet picture. Fixed price is only safe for you if the scope is genuinely tight, which is what the three-objects rule and the named-screens list exist to produce.

Protect that price with three mechanisms: the out-of-scope list in the proposal, a change-request process with a rate attached, and a deposit covering the first milestone. If a partner is doing the build, align your milestones with theirs so you are never paying out ahead of being paid.

Then build the recurring layer, because that is what turns this into a business rather than a series of projects. Hosting managed under your account at a margin, the support retainer, and an agreed rate for the version two you already know is coming. The build fee is the entry point; the retainer is why the client is still yours in three years.

The Handover Checklist

Handover is not a zip file. It is the set of artefacts that lets another competent developer keep the system alive without speaking to whoever built it. Agree the list before the build starts and treat it as a deliverable with its own line in the schedule.

Run a small handover at the end of the pilot as well as at final delivery. It is a cheap test of whether the full handover will be any good.

Repository access with readable commit history, under an account the client controls.
A README that gets a new developer running locally without help.
Every environment variable documented: what it does and where its value came from.
Database migrations, plus a short schema explanation in words.
A deployment runbook, including how to roll back.
An inventory of every external account and service, with the owner named.
A short screen recording walking the client's own administrator through the system.
Known issues and the version two list, written down rather than implied.

Questions We Get Asked

Should I build custom software or use an existing SaaS product?: Use the product if it covers most of the requirement and the gap is preference rather than operation. Build when the workflow is the client's differentiator, when several tools are being joined by manual work, or when data has to live somewhere specific. Compare current subscription spend plus manual labour against build cost plus annual maintenance.
Who owns custom software built by an agency?: It depends entirely on the contract, so make it explicit. Best practice is that the client owns the code, the database and the deployment accounts once paid, with everything hosted on mainstream infrastructure under credentials they hold. That removes lock-in concerns during the sale and makes the end of any relationship administrative rather than contentious.
How much does it cost to maintain a custom internal tool?: Maintenance is ongoing rather than optional: dependency and security updates, third-party API changes, credential renewals, and performance work as data grows. Most agencies price it as a monthly retainer covering hosting oversight, updates, a small allowance of changes and a response commitment, with new features billed separately at an agreed rate.
What should be in the first version of a custom CRM?: Three core objects and the relationships between them, for example customer, job and technician. Version one should create and list those records, filter them, move them through statuses, and produce the one report the client currently assembles by hand. Everything else belongs in a version two with its own scope and price.