If your firm runs Clio for matters and Lawmatics for intake, you already know the problem. The same client gets typed in twice. A phone number gets updated in one system and goes stale in the other. Someone spends a morning every month exporting CSVs to answer a question that should take four seconds.
So you ask a developer whether it can be automated. It can. Then you ask the two questions that actually matter — what does it cost, and how long does it take — and you get a shrug and a request for a discovery call.
That shrug is not evasion, but it is a bad answer. Here is a better one: what drives the price, the three common shapes of this work and how big each one is, and the line items that tend to be missing from the proposal you get.
Why nobody quotes this over email
The number of platforms is almost irrelevant to the price. Connecting two systems and connecting four systems differ by less than you would think, because the hard part is not the connection — it is the mapping.
Clio has a concept of a Matter. Lawmatics has a concept of a Contact moving through a Pipeline. These are not the same object, and neither is a subset of the other. Somebody has to decide what happens when a Lawmatics lead converts: does it create a Clio Matter, a Clio Contact, or both? What if the contact already exists in Clio because they were a client three years ago? Which system owns the phone number when both changed since Tuesday?
Those are business decisions, not engineering decisions. Until they are made, nobody can quote the work — and making them is often the most valuable part of the engagement, because it forces the firm to write down rules that currently live in one person's head.
The integration is easy. Deciding what the integration should do when your two systems disagree is the project.— Kathan N. Patel
The four things that actually drive the price
1. Direction
One-way sync is dramatically cheaper than two-way. In a one-way sync, one system is the source of truth and the other is a mirror — there is never a conflict to resolve. In a two-way sync, both systems can write, which means every single field needs a rule for what happens when both changed. Two-way is not twice the work. It is closer to three times.
2. How many object types
Contacts alone is a small project. Contacts plus matters plus activities plus custom fields plus documents plus calendar events is a different animal, because each object type has its own mapping, its own edge cases, and its own way of failing. Price scales with object types far more than with platforms.
3. Custom fields
Almost every firm has custom fields, and almost every firm underestimates how many. Custom fields are where practice-specific logic hides — a personal injury firm's date-of-loss field, an immigration firm's visa category. Each one needs a mapping decision and each one is a place the sync can break when someone renames it in the UI six months later.
4. Historical backfill
Syncing new records going forward is a fraction of the cost of reconciling the ten thousand records already sitting in both systems in slightly different states. Backfill is its own project, and it is worth asking whether you actually need it — many firms are perfectly served by a go-forward-only sync plus a one-time cleanup of the last twelve months.
Three shapes, and how long each takes
Most legal integrations fall into one of three shapes. Each step up is roughly a step up in cost, because it adds object types, a second direction, or more platforms. The durations are typical for scoping, not quotes. A fixed price comes after a call where the actual field mappings are walked through.
Shape A — one-way sync, one object type
For example: Lawmatics intake contacts pushed into Clio when a lead converts. One direction, one object, standard fields plus a handful of custom ones.
• Typical duration: 2 to 3 weeks
• Relative size: the smallest of the three, and the cheapest way in
• Best for: proving the integration works on real data before committing to more
Shape B — two-way sync with conflict rules
Both systems can write. Contacts and matters stay aligned in both directions, with a documented rule per field for who wins a conflict.
• Typical duration: 4 to 8 weeks
• Relative size: often around three times Shape A, because every field needs a conflict rule
• Best for: firms where staff genuinely work in both systems daily
Shape C — full automation pipeline
Multiple platforms, documents and call recordings included, plus a reporting layer that joins data across systems. This is the shape of a pipeline I built connecting Clio, Lawmatics, Zoom and Box — scheduled background jobs moving contacts, call recordings, and transcripts between platforms with single-click OAuth setup. It removed more than ten hours a week of manual data entry from the firm's admin workload.
• Typical duration: 8 to 16 weeks
• Relative size: the largest, and it pays back fastest when admin time is the main cost
• Best for: firms where the admin overhead is measured in FTEs, not hours
What is usually missing from the proposal
API access tiers. Some platform API features sit behind a specific subscription level. Confirm your plan covers the endpoints the integration needs before signing anything — this is a five-minute check that occasionally kills a project in week three.
Sandbox availability. Testing an integration against your live matter data is not acceptable. If a platform has no sandbox, the plan needs a test firm account, and someone has to pay for it.
Your own decision time. The mapping decisions above need a person at the firm with authority to make them, available for roughly a half day a week during the build. Projects stall here far more often than they stall on code.
Ongoing maintenance. APIs change. Tokens get revoked when someone leaves. Budget something for the year after launch — typically 10 to 15 percent of the build cost — or accept that the first breakage becomes an emergency.
The hidden cost: duplicate records
The single most common defect in legal integrations is duplicated client records, and it is worth understanding why, because it tells you something about whoever is quoting you.
The naive approach is search-before-create: look for a matching contact, and if none exists, create one. This works perfectly in testing and fails in production, because two overlapping job runs both search, both find nothing, and both create. Now the firm has two of every contact from an eleven-second window last Tuesday, and someone has to merge them by hand.
The fix is not more careful searching. It is keying every write on a stable external identifier, backed by a database constraint that makes a second insert impossible:
// The mapping table is what prevents duplicates — not the search.
// A unique index on (FirmId, ExternalKey) makes a double-insert a
// database error rather than a silent second client record.
modelBuilder.Entity<ContactMapping>()
.HasIndex(m => new { m.FirmId, m.ExternalKey })
.IsUnique();
// Every write keys off the source system's own id.
var externalKey = $"clio:{clioContact.Id}";
var map = await db.ContactMappings.SingleOrDefaultAsync(
m => m.FirmId == firmId && m.ExternalKey == externalKey, ct);
if (map is not null)
{
await lawmatics.PatchContactAsync(map.LawmaticsId, clioContact, ct);
return;
}
var created = await lawmatics.CreateContactAsync(clioContact, ct);
db.ContactMappings.Add(new ContactMapping
{
FirmId = firmId, ExternalKey = externalKey, LawmaticsId = created.Id
});
await db.SaveChangesAsync(ct);If you are evaluating quotes, ask how duplicates are prevented. An answer involving a mapping table and a unique constraint is a good sign. An answer involving "we check if it exists first" means you will be merging records in six months.
Should you just use Zapier instead?
Sometimes, yes — and a developer who won't tell you that is selling, not advising. No-code connectors handle the straightforward path well and cost a fraction of custom work.
Custom development earns its price when you hit one of three walls. Volume: per-task pricing that made sense at 500 records a month stops making sense at 50,000. Logic: conditional field mapping, deduplication against existing records, or multi-step operations that need to roll back together. Compliance: a requirement that client data cannot transit a third-party processor, which is increasingly common in firms handling regulated matters.
Below those walls, use the cheaper tool. Above them, no-code becomes a liability precisely because it looks like it is working right up until it isn't, and it rarely tells you it stopped.
How to brief a developer in ten minutes
If you want a useful answer quickly, come with these five things. It is genuinely enough to scope from.
1. Which platforms, and which is the source of truth for client contact details.
2. Which records get typed in twice today, and roughly how often.
3. Whether you need history reconciled or only new records going forward.
4. Roughly how many custom fields matter, and who at the firm owns them.
5. Any constraint on where data can be processed or stored.
That is enough to tell you whether you are looking at a two-week fix or a two-month project, before anyone writes a proposal.
If you have a stack you would like a straight answer on, tell me what it looks like on the contact page, or read more about how I approach this work on the legal tech integration page. There is also a free cost estimator if you want a ballpark before speaking to anyone.
