By KYN AI Advisory Team — AI implementation specialists, Singapore
Most Singapore SMEs should not replace their CRM. Keep it as the system of record and build a thin custom layer on top for the manual steps around it: intake, qualification, drafting, routing and logging. You avoid migrating records and retraining staff, and you keep the licences you already pay for. This article is about that scope decision. For the timeline and contract terms of a build, see custom software development in Singapore.
Do you need to replace your CRM to get custom software?
Usually no. Replacing a system of record forces you to migrate every record and retrain your team. Building on top of it leaves both untouched. That is the difference between a bounded project and an open-ended one.
Replace the CRM only when it is the cause of the problem: it cannot store the fields you need, it cannot be reached by any integration, or it is unsupported. Otherwise the useful question is not "which platform should we move to" but "what thin layer sits on what we already run".
What should stay off-the-shelf and what should be custom?
Run four steps on your own stack before you speak to anyone.
- List your systems of record. Anything that holds customer, deal, stock or account data reliably stays.
- Mark the manual steps between them. Chasing follow-ups, retyping enquiries, redrafting the same reply, copying a figure from one screen to another.
- Tie each gap to a measure. Lower operating cost, more enquiries answered, fewer days to invoice, hours saved. If a gap moves none, leave it.
- Write the scope down. What is in the first release, and what is deferred.
What survives that test is usually small. It is the layer worth paying for.
| Keep off-the-shelf | Build custom | |---|---| | Contact and deal storage | Capture from WhatsApp, email and web forms into one inbox | | Standard reporting | Classification and routing by your rules | | Accounting, payroll, e-signature | Drafting from CRM history, for a person to approve | | Email delivery | Logging each step back with actor and time |
How does a custom layer connect to Salesforce or HubSpot?
Through the CRM's API. The layer reads a contact's history, does its work and writes the result back. The CRM stays the single source of truth, so your team's screens and reports do not change.
A live example, by industry: an insurance brokerage runs outreach with one checkable first line per email, a reply desk that sorts each reply, and a group benefits comparison turned into a client PDF. Unit costs are about S$0.02 per email, S$0.01 per reply sorted and S$0.03 per comparison. They depend on the model and text length. Every step is logged. A person approves messages before they go out.
See integrations for what we connect, and HubSpot alternatives if the CRM itself is the question.
When is replacing the CRM right?
Three cases.
- The CRM is unsupported or end-of-life. Staying costs more than moving.
- Your data model does not fit. Workarounds fill free-text fields and nobody trusts reports.
- Licence cost has outgrown value. Per-user fees have risen faster than usage.
If you move, do it with a reconciliation: extract, load, compare counts and totals, explain every difference, then switch users. Our cloud migration strategy sets out the order.
How much does a thin layer cost compared with a replacement?
A replacement carries three costs: the new licences, the migration and the retraining. A thin layer carries one: the build. The fee shape is a one-off build fee, then a monthly retainer of at least twelve months for changes, monitoring and fixes. It is quoted after the review. There is no price list.
Compare three-year totals. Include the staff time you will not spend retyping data. Our automation versus hiring guide shows how to count it.
What parts make up a thin layer?
The original build for an insurance brokerage is a good template, because it left the CRM untouched. The layer had six parts, and most SME layers use some subset of them.
| Part | What it does | Where the result lands | |---|---|---| | Inbound capture inbox | Gathers email and WhatsApp enquiries in one place so nothing slips between channels | CRM contact and activity | | Inbound qualification agent | Labels each lead the moment it arrives | A field on the CRM record | | Engagement agent | Reads the full thread and drafts the next reply for approval | A draft, then a logged message | | Outreach engine | Runs outbound sequences with one checkable first line | CRM activity and status | | Follow-up scheduler | Tracks every open conversation and triggers the next touch | CRM task with an owner | | Data tidy-up | Restructures customer records into a clean, consistent schema | CRM fields, with a change log |
You rarely need all six. A five-person firm with steady inbound enquiries might need only the first three. The outbound parts add the most compliance work, so add them last.
What does a field-level scope look like?
The scope names the exact fields the layer reads and writes. The example below is illustrative and uses invented field names.
| CRM field | Layer reads | Layer writes | Notes | |---|---|---|---| | Contact name, email, phone | Yes | Only on a new contact | New contacts flagged "unverified" until a person confirms | | Company | Yes | Yes | Writes only when empty | | Lead status | Yes | Yes | Changes only between the first three statuses; later stages stay with a person | | Last contact date | Yes | Yes | Updated on every logged message | | Notes | Yes | Appends | Never overwrites a person's note | | Deal value | Yes | No | Money fields are read-only to the layer | | Owner | Yes | No | Routing is a task, not a reassignment |
This table is the contract between the layer and the CRM. Anything not in it is off limits. When the CRM's admin asks "what can this agent touch?", the answer is a list, not a promise.
What goes wrong when you build on a CRM?
- API limits. Most CRMs cap calls per day or per minute. Batch writes, queue them and retry with a delay, rather than assuming every call lands.
- Duplicates. The layer creates a second record for a person who is already in the CRM under another email. Match on phone and email, and flag near matches to a person instead of merging.
- Custom fields that nobody documents. A field called "Type 2" means something to one person. Document each field you touch in the review, with its allowed values.
- Permissions drift. The service account used by the layer should have its own role with the minimum access it needs. Review it when the CRM changes.
- CRM upgrades and renamed fields. A vendor change can break a write silently. Alert on failed writes and on a sudden drop in logged messages.
- Staff who bypass the layer. If people keep working outside the system, the log has gaps. Make the shared inbox the easier route, then check weekly that volumes match.
How do you decide, with numbers, whether to keep the CRM?
Compare the options on the same page. The numbers are illustrative placeholders. Fill in your own.
| Cost line | Keep CRM and add a layer | Replace the CRM | |---|---|---| | New licences, 3 years | None | Per-user fee x users x 36 months | | Build | Layer build fee | New system build or configuration | | Migration | None | Extract, load, reconcile, correct | | Retraining | Small: staff keep their screens | Every user, every workflow | | Retainer | Monthly, minimum twelve months | Vendor support plan | | Risk | Narrow: the layer can be switched off | Wide: one cutover for all records |
Sum each column over three years. In many cases the layer wins because the migration and retraining lines are large and easy to forget. If the CRM is unsupported or cannot hold the fields you need, the answer flips, and that is the time to move.
What does the first month look like?
Week 1 and 2 are the review. You list the systems of record, mark the manual steps and fix the field-level scope. Week 3 is the first connection: a read-only link to the CRM and the shared inbox, so the layer can see the data without changing it. Week 4 turns on writes for one low-risk field, such as the last contact date, and a person checks a sample of 30 records against the source. Only after that check do labels and drafts follow. Each step is small enough to reverse in an afternoon.
If the sample shows errors, stop and fix the cause before you widen. The usual causes are a field mapping that does not match how staff use it, and a duplicate-matching rule that is too loose. Both are cheap to fix at 30 records and expensive at 3,000.
What should you ask your CRM vendor?
Ask whether the plan you pay for includes API access, what the call limits are, and whether write access can be limited per field. Ask how field changes are recorded, so you can trace any change the layer makes. Some plans restrict API access to higher tiers, and discovering that after scoping costs a week. Read the vendor's current API documentation and plan page for the answers rather than relying on a sales call.
Who owns the custom layer?
You do, once the build is paid for. The layer runs in a cloud account in your company's name, and the custom code and configuration become yours at that point. Ending KYN's role does not stop the layer or touch the CRM. Agents have their own restricted accounts, the database uses row-level security, and every action is logged with the actor. Outbound messages, money, filings and deletions wait for a named person. See security.
How long does it take?
The first 14 days are a review: your CRM, your channels, interviews with the people who use them. A full build ships in under 90 days. A thin layer on one CRM is usually among the faster builds, because the records are already in place and the scope is narrow.
Where KYN fits
KYN builds custom technical systems for SMEs in Singapore, Hong Kong, Indonesia and Malaysia: cloud infrastructure in the client's own account, a front end designed around each team's workflow, and agents for sales, marketing, operations and finance. For the sales case, see sales systems and the custom sales system guide.
Frequently asked questions
Do I need to replace my CRM for custom software?
No. Build a thin layer on top for intake, qualification and drafting, and keep the CRM as the system of record. Replace it only if it is unsupported, cannot fit your data, or costs more than it returns.
How do custom agents work with an existing CRM?
They read a contact's history through the CRM's API, do their task and write the result back with the actor and time. The CRM stays the source of truth.
What should be custom and what should stay off-the-shelf?
Keep any tool that stores records reliably. Build custom for manual, repetitive steps between tools, and only where the gap moves a measure you care about.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
