I keep seeing stories on LinkedIn and YouTube from people who have rebuilt their website with Claude Code and dropped their expensive content management system. I’ve also seen people saying they’ve replaced Clay, or other tools, with workflows they built using Claude Code.
For a marketing team, those stories introduce a new question. When someone suggests buying software, a colleague can now reasonably ask, “Could we just build it with AI?”
That creates both interest and pressure to try vibe coding, especially when budgets are tight. It also opens up two possibilities: replacing software you’re already using, or creating a custom tool you don’t have, perhaps to automate work the team currently does by hand.
For teams that haven’t built software before, deciding where to start can be difficult. My advice is to apply two tests. Do you understand how the proposed software works technically, well enough to judge whether it’s doing the job correctly? And will it make your team more efficient and effective?
Saving subscription fees is the wrong starting point for a marketing team’s decision. The opportunity is to build something better suited to your work, so you can move faster, get more done or produce better results.
Start with the part your team needs
If you only use a small part of a large platform, the possible project is much smaller than replacing that platform. Write down what your team does with the product and what you would need to retain.
We had a project management tool where we were only using a small part of the functionality. It was frustrating to use, people didn’t like using it, and it didn’t give us the reports we needed. So we built our own around our team structure, our projects and our reporting requirements. We ended up with something highly customised to our work, and adoption went up significantly. We also saved the subscription fees, but the more important benefit was having a tool the team wanted to use.
Sometimes there isn’t an existing subscription to replace. We had a project to make SEO updates to a website and wanted to break the work into smaller tasks, assign them to people and include an audit cycle. Once someone marked a task as implemented, an AI agent could check the website to see whether the change had been made correctly.
We built a tool around that process because handling it manually was going to be a lot of work. I don’t know whether a commercial product already does exactly this. We started with a job we understood and a way to make it easier.
Build something you understand well enough to judge
The team needs to understand more than what it wants the app to do. Someone needs enough technical understanding of how it works to judge the result and recognise when something is wrong. For our project tracker, that includes how tasks are assigned, how information is stored and changed, and how the reports are produced. A report that looks right still needs to be checked against the information and rules behind it.
I wouldn’t try to recreate database-management software. I don’t understand that work well enough to assess the result. Building a workflow that uses a database is a different job, where I can understand the information going in, the rules being applied and the output we should get.
If nobody on the team understands the solution, you’re dependent on an AI agent or an outside expert to tell you whether it works. Another model or another expert might recommend a completely different approach, and you still wouldn’t know which advice to follow or what to change. Getting advice can help, but the team needs enough understanding to evaluate that advice.
Before building, identify who can judge the result and work through changes. If nobody can, reduce the scope to something you do understand or keep buying that capability. The fact that AI can build something for you doesn’t make it a sensible thing for your team to own.
Build to make the team more effective
Budget pressure can prompt you to look at how much of an app you’re using. But replacing a subscription means taking on the time needed to build and maintain the software yourself. The more useful it becomes, the more important it is to maintain it professionally.
Your marketing team could spend that time on work that brings future revenue into the company. I’d be reluctant to use it to rebuild a paid tool simply to reduce the software bill. The build needs to improve how the team works enough to justify both the initial effort and the continuing commitment.
There are company-wide decisions on a different scale. Curative CEO Fred Turner, for example, told Harry Stebbings that the company replaced a $600,000-a-year Salesforce contract with a CRM it had vibe coded internally. If a CEO wants to make a replacement like that an organisational initiative and put engineering time behind it, that’s a different proposition from a marketing team spending its time trying to cut subscription fees.
For marketing, I’d look for a frustrating process that could become faster, output that could become more useful, or a requirement particular to the team that existing products handle badly. Connecting two tools that don’t work together may do more for you than replacing either one.
I’ve looked at which products are easier to build and maintain in Is your product in the danger zone?. That may help you narrow down what your team could take on.
Decide what will improve before you start
You don’t need to begin with a whole platform. Choose a small piece of work where you can explain both how the tool should work and what difference it should make to the team.
Before you commit, write down:
- The work you’re trying to improve. Describe the frustrating step, the part of an existing product you use, or a job a new tool would make possible.
- The improvement you expect. Explain how the team will work faster or produce better output, so you can compare the result with what happens today.
- What you’re taking responsibility for. Name who understands the solution technically and can judge whether it works. Allow for their time to maintain it as requirements or connected systems change.
- How you’ll try it on real work. Choose a small initial use and review whether the expected improvement appears before expanding it.