Do Early-Stage Startups Still Need a CRM?
No, not on day one. A growing number of early-stage companies run go-to-market out of a git repository of plain files, add a database when files stop scaling, and bring in a CRM once they have a sales team whose work needs one. That order is cheaper and faster, and it leaves less to migrate later. The exception is a company that already knows it will need a CRM at scale and would rather never switch.
An audience member put it to the panel at GTM Belongs in Git: if you are a startup with no legacy data, are you better off skipping the CRM entirely? The answers disagreed in a useful way.
What we see early-stage teams doing #
From where Cargo sits, the pattern is consistent. More companies put a CRM in place later than they used to. At the start, go-to-market is a repository: a context layer of files describing the ICP, the personas, the accounts being worked, and the plays being run. Agents read it and write to it. At some point the team needs a real database, and the question becomes whether that should be a raw database like Postgres or a CRM.
John Kutay, who runs GTM engineering at Rippling, described the same progression from the other end: keep your GTM brain in git as long as you can, because files are versioned, readable and consumable by agents, and move to a database when concurrent writers make pull requests the bottleneck. Even at Rippling’s scale, that is where he starts.
The case for buying one anyway #
Noah Adelstein, who runs growth at Netic, did the opposite on purpose. When he joined, the goal was to build a very large business, and he did not want to spend any time on CRM questions later, so he bought Salesforce knowing it would scale with them.
That is a real reason, and it is a specific one. It holds when you are confident the company will need an enterprise CRM, you will hire a sales team soon, and the cost of migrating later outweighs the cost of carrying one now. His own caveat: at a company not in that situation, he would be far more pragmatic about what it actually needs to accomplish. Do you have salespeople yet? What are they doing? He does not think you absolutely need one, and plenty of teams prove it.
What a CRM gives you that a repo does not #
The decision is easier if you are specific about what you would be buying. A CRM is several things bundled together:
| Capability | Needed when | Without a CRM |
|---|---|---|
| Many people editing records at once | Several reps update the same accounts daily | Files and PRs get slow; use a database |
| Pipeline stages and forecasting | Someone reviews a forecast every week | A table and a dashboard, if it is simple |
| A rep-facing interface | Reps who do not work in a repo need to act on data | A small internal app on your data |
| Integrations that expect a CRM | A tool you rely on only syncs with a CRM | Often the deciding factor |
| Permissions and audit for sales | Territories, managers, compliance | Git history covers changes, not access |
Before you have salespeople, almost none of these apply. The founder is the sales team, the records fit in files, and git already gives you what a CRM’s audit log would: who changed what, and when.
The signs it is time #
Buy a CRM when two or more of these are true:
- You have hired dedicated sales reps, and they need to update records every day without learning a repository.
- Someone reviews a forecast weekly and wants stages, amounts and close dates in a standard shape.
- Concurrent edits are causing conflicts, and a plain database is not enough because reps need an interface on top.
- A tool you depend on only integrates with a CRM.
- Your investors or board expect pipeline reporting you cannot produce from what you have.
Until then, the repository plus a database is not a compromise. It is a better fit for a team where agents do much of the work, because agents operate on files and tables far more reliably than on a CRM’s interface.
If you start without one, keep the door open #
The teams that switch painlessly later do three things from the start:
- Use stable keys. A normalized domain for companies and a normalized profile URL for people, so records map cleanly into any system you adopt.
- Keep state and history apart. Current values in one place, events with timestamps in another, so nothing is lost when you import.
- Write down what each field means. A CRM migration is mostly a mapping exercise, and a file that says what every field is makes it a short one.
When the CRM does arrive, it becomes the process layer: opportunities, stages, forecasts. The logic that decides which accounts matter can stay where it started, in the repository, as code. That is what GTM as Code describes, and it is the part you never have to migrate.
FAQ #
Usually not before it hires dedicated sales reps. Many early teams run go-to-market from a git repository of files and a database, then adopt a CRM once reps need to update shared records daily or someone reviews a forecast every week.
A version-controlled repository for the ICP, personas, accounts and plays, plus a database such as Postgres once many writers update the same records. A small internal app can serve as the interface. This covers most needs until there is a sales team.
When two or more of these are true: dedicated reps need to edit records every day, a weekly forecast review needs standard pipeline stages, concurrent edits are causing conflicts, a critical tool only integrates with a CRM, or the board expects pipeline reporting.
Sometimes. If you are confident you will need an enterprise CRM and a sales team soon, buying early avoids a migration. Otherwise, starting with stable keys and documented fields keeps a later migration short.
Build this workflow instead of reading about it.
Cargo is the GTM infrastructure your coding agent builds on: enrichment, scoring, routing and outreach, defined in code and run in production.
