Counterintuitively, the more GTM teams that adopt agentic coding to build apps...
This post was originally published on LinkedIn.
Let's take a popular example: Using AI to build your own CRM
(Note: I don't see any serious companies doing this successfully, but lets roll with the example)
In the past, you would:
- Buy a CRM
- Have people on your team to implement, maintain, build on top of it
- But the underlying code, security, updates, hosting, support, etc was not something you had to staff for in-house
- If the tool has AI capabilities, you also just get the AI features without having to setup the AI integrations, manage the cost of tokens, decide on model section, etc
If you vibe code your own:
- Buy a CRM turns into working with AI to build the CRM
- Still need to: Have a team of people to implement, maintain, build on top of it
- Now also need a team of people to: dev and harden the underlying code, build in security, build a roadmap and push updates, manage and pay for hosting, handle support
- Manage all the AI features, token costs, test models to ensure the features stay ahead
Your GTM Ops team went from:
Building your GTM system by architecting and building on top of tools that were built and maintained by hundreds/thousands of people.
To:
Building your GTM system by building, maintaining, securing, and developing tools from scratch that need to be secure and meaningfully better than the best in breed tools (that have millions of dollars and hundreds/thousands of people building them).
To be clear, agentic coding is HUGE for GTM. Building hyper-specific apps that don't exist, developing automation/agents that leverage code, and even replacing apps that are easy to replace.
BUT: you have to be clear about how you'll manage the maintenance and development cost over time.
There is a place for both build and buy. Just be sure you know what you are signing up for before you vibe code your way to a place where your team is drowning in maintaining buggy tools that are worse than something off the shelf.