CRM Development Company in San Francisco

San Francisco and the wider Bay Area carry the highest senior engineering rates in North America, and honest CRM quotes come as ranges because scope drives everything. A discovery and architecture engagement covering a full customer data inventory, identity resolution design, deletion and consent propagation map, and a target integration architecture typically runs USD 25,000 to 60,000 over four to eight weeks. A production CRM build, whether that is a substantial Salesforce implementation with custom Apex and Lightning Web Components or a custom CRM on PostgreSQL with a real relationship model, typically runs USD 120,000 to 350,000 including migration, integrations, and the consent service. An enterprise program with a customer data platform, warehouse-native identity graph, reverse ETL into operational tools, multi-brand or multi-entity separation, and CCPA risk assessment documentation runs USD 350,000 to 900,000 and up. Codazz has no San Francisco office and delivers from Edmonton and Chandigarh, so the rate carries none of the Bay Area overhead that local consultancy pricing has to. The variable that actually moves a CRM number is not the rate, though. It is how many systems hold a copy of the customer record, which is why we price discovery separately and let the resulting inventory set the build number rather than guessing at it up front and repricing later. We quote fixed fee against a signed statement of work.

Most CRM deletion implementations delete from the CRM and stop, which leaves the record alive in six other places. Under the CCPA as amended by the CPRA, a California resident can request deletion, correction, access, and portability, can opt out of sale and sharing, and can limit the use of sensitive personal information, and the obligation follows the data rather than the primary database. Enforcement sits with the California Privacy Protection Agency and the Attorney General, and a breach of unencrypted personal information carries a private right of action with statutory damages up to USD 750 per consumer per incident. We build deletion as a fan-out workflow, usually on Temporal so it is durable and auditable, that propagates from the system of record into the warehouse, the customer data platform, every reverse ETL destination, the messaging platform, ticketing, analytics, exports, and backup snapshots on their retention schedule. Enrichment vendors get a suppression record so they cannot reintroduce the profile on the next append. Any fine-tuning corpus or embedding index derived from customer text gets a deletion path too. Every step writes to an audit log with a timestamp, a target system, and a confirmation, because the log is the evidence you produce when the CPPA asks.

Usually not, and the distinction matters enough to get right. California's automated decisionmaking technology rules live inside the CCPA regulations that became effective January 1, 2026, and they attach to ADMT used to make a significant decision about a consumer, which the rules frame around outcomes like financial or lending services, housing, education enrollment or opportunity, employment or independent contracting opportunities and compensation, and healthcare services. Businesses using ADMT for significant decisions must comply beginning January 1, 2027. A marketing propensity score that decides which email a consumer receives is generally not a significant decision. A model inside a fintech CRM that determines credit offer eligibility, or a scoring model that gates access to a healthcare service, is. So the question we ask in discovery is not whether you use a model but what the model's output causes. Where the answer lands inside the significant-decision categories we build the pre-use notice, the opt-out path, and the access-to-explanation surface as product features on the 2027 clock rather than as a scramble in late 2026.

Extend Salesforce when your revenue motion genuinely fits leads, contacts, accounts, and opportunities, when your sales team already lives in it, and when the integrations you need have supported connectors. The ecosystem advantage in San Francisco is real: hiring an admin here is easy and the vendor is fifteen minutes away. Build custom when the relationship model itself is the problem. Two-sided marketplaces with participants whose lifecycles interact, usage-based software where the highest-value signal is product telemetry rather than sales activity, and financial products where a CRM record is also a regulated file all break the stock object model. Forcing them in produces a system the revenue team quietly routes around with spreadsheets, which is worse than either option. There is a third answer we recommend more often than either extreme: keep Salesforce as the seller-facing surface, move identity resolution and the customer model into the warehouse where you can actually reason about it, and use reverse ETL to push the computed model back into Salesforce fields. That keeps the ecosystem benefits, removes the pressure to model everything inside one vendor's object schema, and makes your privacy obligations tractable because the canonical customer record has one home.

The California Invasion of Privacy Act at Penal Code section 630 and following was written for wiretaps, and plaintiffs' firms have been applying it aggressively to web tracking, session replay, chat transcripts, and advertising pixels that transmit visitor interactions to a third party. The theory is that a third-party script participating in a communication between a visitor and a site is an unconsented interception. This is live litigation risk rather than settled law, and the exposure is concentrated exactly where CRM and marketing stacks live: chat widgets that route transcripts to a vendor, session replay tools recording form entry, and pixels firing on pages where the visitor is discussing health, finance, or an account. We handle it in three ways. First, we inventory every third-party script and tag on every page and record what data each one receives. Second, we move server-side wherever possible so the site owner is a party to the communication rather than a conduit for a third party. Third, we gate anything remaining behind an explicit consent surface wired to the same consent service the rest of the CRM reads, with the consent state and its timestamp stored as data. We are engineers, not your counsel, and we build to whatever posture your privacy counsel sets.

CRM projects fail at migration, and they fail late, which is why we demo against real migrated data from the first sprint rather than seed data. The work starts with profiling: how many records exist across every source, how many are duplicates, how many have conflicting values on the same field, and how much of the history is worth keeping at all. Identity resolution is the hard part. We build a deterministic match layer first on strong identifiers such as verified email, phone in E.164, and account identifiers, then a probabilistic layer on weaker signals, and we keep the two separate so a probabilistic match can be reversed. Every merge writes a survivorship record that names the surviving value, the losing value, and the rule that decided, so a merge is auditable and undoable. Household and company rollups are computed rather than destructive, which stops the classic failure where two people at one address get merged into one person and their consent states silently combine. Historical activity is migrated with original timestamps preserved. We run the full migration at least three times against production copies before cutover, using the Chandigarh overnight window, and we keep the source system readable for a defined period after go-live.