Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
  1. Home
  2. Blog
  3. Every Agency Wants Us to Connect to a Different CRM. How Do We Keep Up?
Problems We Solve

Every Agency Wants Us to Connect to a Different CRM. How Do We Keep Up?

Proptech startups stall when every estate agency needs its own CRM integration. We build one connector layer so Reapit, Alto or Street are adapters.

Updated 3 min readBy SpiderHunts Technologies

Free estimateNo obligation

Get a free estimate

Tell us what you need. A senior engineer reads every enquiry.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →

Quick answer — TL;DR

The integration backlog grows because each agency CRM was wired straight into your product, so every new one means touching core code. We build a connector layer with your own internal model of properties, applicants and contacts, so each CRM becomes an adapter that maps to it, and new integrations stop competing with the roadmap.

Deals waiting on an integration you have not built

Your sales lead has three agencies who like the demo and one question: does it work with our CRM? One runs Reapit, one runs Alto, and one is on a smaller system you have never heard of. You built the Reapit connection first because your launch customer used it, and it took a developer most of a quarter. Alto is half done. The third is not on the plan at all.

Meanwhile your existing customers are asking for fixes to the Reapit connection, because their fields do not match the ones your launch customer used. Every integration request, new or old, goes to the same two developers, and the product roadmap slides back a little each month.

Why each CRM feels like starting again

The usual cause is not the CRMs themselves. It is that the first integration was built directly into the product. Your code reads a Reapit property, Reapit's idea of a negotiator and Reapit's status values, and the rest of the product grew around those shapes.

When the second CRM arrives, its statuses do not line up, its applicants are structured differently, and it identifies branches in its own way. The only option is another set of special cases inside core code, and each special case makes the next integration harder.

ConceptWhy it differs between CRMs
Property statusSold STC, under offer and let agreed are named and ordered differently
ApplicantSome CRMs hold buying criteria on the contact, others on a separate record
Branch and negotiatorDifferent identifiers and different rules for shared listings
Change notificationsSome push webhooks, some need polling, some offer neither for every object
Custom fieldsAgencies add their own, which your product may need to read

The cost of every integration going through core code

Sales cycles lengthen because the honest answer to the CRM question is often not yet. Agencies on less common systems are turned away, even when they are a good fit. Developers who understand the integrations become a bottleneck, and a bug fix for one agency's field mapping can break another agency's sync because they share the same code path.

There is also a support cost. When data looks wrong in your product, nobody can quickly tell whether the problem is in the CRM, in the mapping or in your own logic.

A connector layer, and what goes into it

What we build separates your product from the systems it talks to.

  1. We define your own internal model for the things your product cares about: properties, listings, applicants, vendors, landlords, branches, negotiators and their statuses, with your product's vocabulary rather than one CRM's.
  2. Each CRM gets an adapter that translates between its API and that model. The adapter owns authentication, paging, rate limits, polling or webhooks, and status mapping.
  3. Mappings that vary by agency, such as custom fields or unusual status names, live in configuration per agency rather than in code.
  4. Every sync writes a log of what came in, what it mapped to and what it could not map, so support can see the source of a wrong value.
  5. We add contract tests for each adapter against recorded API responses, so a change to one adapter cannot quietly break another.
  6. We move your existing integration behind the layer first, carefully and with both paths running side by side, before adding new ones.

After that, a new CRM is a bounded piece of work: one adapter, its tests and its configuration. It can also be built by someone who does not know the rest of your product in depth.

How the week feels afterwards

Sales can give a straight answer to the CRM question, including a realistic view of what an adapter for a less common system involves. A support person looking at a strange status opens the sync log and sees that the agency renamed a status in their CRM, which is a configuration change, not a code change. Developers work on the product again, and integration work becomes a queue that can be planned rather than an interruption.

Signs the backlog is a design problem

  • Your core code checks which CRM an agency uses in more than a handful of places.
  • A fix for one agency's sync has broken another agency's.
  • Sales avoid prospects on less common CRMs because integration work is unpredictable.
  • Only one or two people can explain how a CRM field reaches your screens.
  • Custom field requests from agencies require a release.

FAQ

Frequently asked questions

The questions readers ask us after this guide.

Still have a question?

Ask us directly — a senior engineer will get back to you.

Ask about your project

Do we have to rebuild our existing Reapit or Alto integration?

We move it behind the connector layer rather than rewriting it from nothing, and run old and new paths side by side until the results match.

What if a CRM has a limited API?

The adapter works within what the API allows, and we tell you plainly which features of your product it cannot support for that CRM, so sales can set expectations.

Do we need to join CRM vendors' partner programmes?

Often yes for API access, and that is a commercial step you take. We can tell you what each adapter needs technically once you have access.

What does the cost depend on?

Mostly on how tangled the current integration is with your core code, and how many CRMs you need in the first round.

Keep reading

More on Problems We Solve

Start here

Tell us where your proptech product gets stuck with agencies

Describe what your product does for estate or letting agents, which agency systems it has to talk to, and where the friction shows up: onboarding, integrations, support or billing. We will tell you what we would build and what we would leave alone, and if the fix is a process change rather than code, we will say so.

  1. You tell us what you needTwo minutes on the form, or a message on WhatsApp.
  2. A senior engineer reviews itAnd comes back with questions, a realistic range and an honest view on fit.
  3. Free 30-minute scoping callWe talk through scope, options and a realistic estimate — with no obligation.
Free estimateNo obligation

Talk to someone who builds this

Send a short brief and we will come back with an honest view and a realistic range.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →