Custom CRM With Email Sequences: Real Cost and Timeline

What this actually is once real people are enrolled

A CRM with email sequences is two systems that disagree with each other. The CRM is a mutable graph of people, companies and deals that sales reps edit all day. The sequence engine is a scheduler that made a promise three days ago about what it would send today. Every hard bug in this build lives in the gap between those two facts.

Week two of real usage, the version that shows up: a rep imports a list, and the same buyer exists twice, once as sarah@acme.com from a webform, once as s.johnson@acme.com from a conference scan. Both records get enrolled in the four step sequence. On Tuesday a different rep notices the duplicate and merges them. The naive implementation keeps enrollments keyed to the record ID, the losing record is soft deleted, and one of two things happens: either the merged contact silently drops out of the sequence and nobody follows up on a deal worth $40,000, or both enrollments survive on the surviving record and Sarah gets step 2 twice within ninety seconds. She replies once, to complain. The reply lands on the record that no longer exists, so the reply detector never fires, so step 3 goes out on Thursday to a person who has already told you to stop. That is a CAN SPAM problem now, not a UX problem.

Nobody quotes for merge semantics. Everybody ships the merge button.

Deliverability is the product, sending is a library call

Sending an email is four lines of code. Getting it into the inbox is the actual scope. Since February 2024, Gmail and Yahoo enforce bulk sender rules on anyone sending over 5,000 messages a day to their users: SPF and DKIM both passing, DMARC published with at least p=none and alignment on the From domain, one click unsubscribe implemented per RFC 8058 with both the List-Unsubscribe and List-Unsubscribe-Post headers, and spam complaint rates held under 0.3 percent as measured in Google Postmaster Tools. Cross 0.3 percent and your mail goes to spam for everyone on that domain, including your transactional password resets.

Then there is the sending path itself, and the choice is a fork in the build.

Send from your own domain through Amazon SES, Postmark, Resend or SendGrid, and you inherit domain reputation and warmup. SES starts every account in a sandbox at 200 messages per 24 hours and 1 message per second until you file a production access request, and it reviews your account when hard bounces exceed 5 percent or complaints exceed 0.1 percent. SES list pricing is $0.10 per 1,000 emails and a dedicated IP is about $25 a month, which is nothing. The two to six weeks of ramping a cold domain from 50 to 2,000 sends a day is not nothing, and it is calendar time you cannot compress with money. Note that Postmark and some others explicitly prohibit cold outreach, so check the acceptable use policy before you architect around a vendor.

Send from each rep's own mailbox, which is what sales teams actually want, and the problem changes shape. Gmail via the API or SMTP relay caps a Workspace user around 2,000 recipients per day. Microsoft 365 throttles Exchange Online at roughly 30 messages per minute with a 10,000 recipient daily ceiling. You now hold OAuth refresh tokens for every user, and tokens die: password changes, admin revocation, MFA resets, license removal. A competent build treats a dead token as a first class state with a re disconnect prompt, not a 500 in a worker log.

The one that ambushes teams: reading a user's Gmail to detect replies requires a restricted scope. Google puts gmail.readonly and gmail.modify behind a CASA security assessment performed by a third party, priced from several hundred to several thousand dollars annually depending on tier, and the review takes weeks of calendar time that has nothing to do with your sprint board. Find this out in month one or find it out the week before launch.

The scheduler is a distributed system, not a cron job

Every failed version of this feature has a table called scheduled_emails and a cron that runs every minute and sends whatever is due. It works until the worker restarts mid batch and re sends forty emails, or two workers pick up the same row.

What a competent build does: model enrollment as a state machine with an explicit current step, a next_action_at timestamp and a terminal reason. Every send carries an idempotency key on the tuple of enrollment ID plus step ID, written before the provider call and checked after, because queues give you at least once delivery and your job is to make the second delivery a no op. Exactly once does not exist at the transport layer, so you build it at the record layer.

Exit conditions are where the money is. Reply detection cannot be a From address match, because buyers forward you to a colleague, reply from their phone alias, or loop in procurement. You match on the RFC 5322 threading headers: you set Message-ID on your send, you look for your ID in the In-Reply-To or References chain of anything inbound, and you fall back to domain plus subject heuristics. You also filter automatic replies, because an out of office should not count as engagement. RFC 3834 gives you the Auto-Submitted header, and real world mail also needs checks for X-Autoreply and Precedence: bulk. Miss this and every August your sequences stall on vacation responders.

Watching for those replies has its own decay. A Gmail Pub/Sub watch expires after seven days and must be re registered, and best practice is renewing daily. When you miss a window, you resync from the stored historyId, and if that ID is too old Google returns a 404 and you fall back to a full mailbox scan. Microsoft Graph subscriptions for messages max out at 4230 minutes, just under three days, and Graph sends lifecycle notifications you must handle to keep the subscription alive. Generic IMAP has neither, so you hold IDLE connections and reconnect on the provider's whim. Supporting Gmail plus Microsoft plus generic IMAP is not one integration, it is three, and it roughly triples this slice of the estimate.

Last piece: send windows. "Weekdays 9am to 5pm in the recipient's timezone" means you store an IANA timezone identifier, not a UTC offset, and you handle the twice yearly DST transition where a scheduled 2:30am job either does not exist or runs twice.

The data model that survives contact 50,000

Custom fields are the request every buyer makes and every vendor underprices. Entity attribute value tables give you flexibility and destroy your query planner. A JSONB column with GIN indexes on Postgres is usually the right answer for a build in this range, with a fields registry table for types, validation and picklist options, plus generated columns for the two or three fields that get filtered constantly.

Merge deserves a designed answer, not a DELETE. The pattern that works: never hard delete the loser, write a tombstone row mapping old ID to surviving ID, and resolve every foreign key through it. Enrollments, email events, timeline entries and suppression records then follow the survivor automatically, and the double send from the opening scene becomes impossible because the dedupe key resolves to one contact.

Suppression must be global and instant. An unsubscribe, a hard bounce or a spam complaint belongs to the email address at the account level, checked at send time inside the same transaction as the send, not at enrollment time. Per sequence opt out lists are how you end up with a regulator's attention.

Then row level access. Reps see their own records, managers see their team, admins see everything, and this has to hold on every list endpoint, every export and every search. Postgres row level security enforced at the database is far cheaper than a WHERE clause someone forgets in the reporting query eight months later.

Compliance has a price tag attached

CAN SPAM requires a real physical postal address in commercial email, an honored opt out within 10 business days, and no deceptive headers. The FTC's civil penalty ceiling per violating email sits above $50,000, and each email counts separately. CASL in Canada requires express or implied consent, with implied consent expiring on a fixed window, and carries penalties up to CAD 10 million for organizations. GDPR needs a lawful basis under Article 6 and, for marketing to individuals in most of the EU, consent under the ePrivacy rules. The engineering consequence is concrete: consent source, timestamp and jurisdiction are columns on the contact, and the send time check reads them.

What it costs and how long it takes

These bands come from Digital Heroes delivery experience across 2,000 plus projects, not from a market survey.

Adding a sequence engine to a CRM you already have, sending from one verified domain, single provider, with reply detection and suppression: $15,000 to $60,000, roughly 4 to 8 weeks. Building the CRM and the sequences together as a first release, with custom fields, merge, permissions and reporting: $50,000 to $130,000 in 10 to 16 weeks. A full platform, multi tenant, per user mailbox sending, deliverability tooling and analytics: $150,000 to $350,000 over 6 to 12 months.

What pushes this specific capability up the band: the number of mailbox providers (Gmail only versus Gmail plus Microsoft plus IMAP is the single biggest lever), per user OAuth sending instead of one domain, anything requiring Google restricted scopes and therefore CASA, A/B testing at the step level with statistical reporting, branching sequences with conditional paths, and migrating history out of HubSpot or Pipedrive where the old event timeline has to arrive intact. What pushes it down: sending from one domain, sequences that only branch on reply or no reply, and accepting a rented sending provider instead of managing IPs.

When you should not build this

If your objects are contact, company and deal, and your sequence triggers are lifecycle stage changes, buy HubSpot. Sales Hub Professional lists at $100 per seat per month, sequences included, and at ten seats that is $12,000 a year against a $60,000 build plus maintenance forever. You will not beat their deliverability team. If you are doing pure cold outreach, Instantly or Smartlead already solved mailbox rotation and warmup and cost a rounding error. If you need lifecycle messaging off product events, Customer.io or Braze will out ship you.

Build when the trigger for the email lives in data that only exists inside your product and cannot be synced out fast enough or cheaply enough: a job status changing on a dispatch board, an inspection failing, a marketplace order going unclaimed for 90 minutes, a device going offline. Build when you resell this to your customers, because per seat SaaS pricing collapses the moment your users are the seats. Build when the CRM is not really a CRM and calling it one is just what the buyer knows to search for.

Most vendors will not offer you the split build, because it is smaller work: keep HubSpot or Pipedrive as the system of record and build only the sequence engine against its API, or the reverse, build the CRM you actually need and rent all sending through SES or Customer.io. In our experience the split is the right call more often than either extreme.

How to brief and vet the developer

Give them three things before any estimate: which mailbox providers your reps use, whether email must come from the rep's address or your domain, and your expected daily volume per sender. Those three answers move the number more than the feature list does.

Then ask these, and listen for specifics rather than confidence.

What happens to two active enrollments when a rep merges two contacts? A shipped answer describes tombstones and a dedupe key. A fake answer says "we handle merges."

How do you stop a sequence when the prospect replies from a different address than the one enrolled? You want References and In-Reply-To header matching, plus a domain fallback. If you hear "we match the From address," they have not shipped this.

Where does the Gmail watch renewal live, and what happens when it misses a cycle? Correct: renewed daily, backfilled from historyId, full sync fallback when Google returns 404 on a stale ID.

Which OAuth scopes does the reply detection need, are any of them restricted, and who pays for the CASA assessment? Anyone who has done it names the assessment. Anyone who has not will say verification is a formality.

Show me the idempotency key for a step send. There should be an answer in under ten seconds.

Does a hard bounce suppress the address globally or only in that sequence? Global, at the account level, checked in the send transaction.

How do you test sends without emailing real humans? Expect the SES mailbox simulator addresses, or Mailpit locally, not "we use a test list."

How do you warm a new sending domain, and what does the ramp look like week by week? If the answer does not include weeks and Google Postmaster Tools, they have never watched a domain get burned.

Last one: what was your spam complaint rate on the last system you shipped, and how did you know? Anyone who has actually done this remembers the number.