The marketer's stack for building internal tools without a dev team
Cursor plus Claude has quietly become a viable way for marketing operators to build the scrapers, dashboards, and automations they used to buy or beg for. Here's how I think about the stack, what it actually replaces, and where it still falls apart.
For about a decade, the answer to “can we build a small internal tool for this?” was always the same. Either pay a SaaS vendor $200 a month for something that does 30% of what you need, or file a ticket with engineering and wait two quarters.
That answer is changing. Not because marketers learned to code, but because the tools learned to meet marketers where they are.
What the Cursor plus Claude stack actually is
Cursor is a code editor that wraps an AI agent around your project files. Claude (specifically Sonnet and Opus) is the model doing most of the heavy lifting inside it. You describe what you want in plain English, the agent writes the code, runs it, and fixes its own errors when things break.
The interesting shift is that you’re not writing code anymore. You’re writing requirements. The model handles syntax, imports, file structure, and most of the debugging. Your job is to know what you want and to check whether the output does it.
That sounds like a small change. It isn’t. It’s the difference between needing to learn Python and needing to learn how to describe a problem clearly. Marketers already do the second one for a living.
The tools worth building yourself now
I’ve been keeping a running list of things I used to pay for or wait on, and which of them I can now build in an afternoon. A rough taxonomy:
Scrapers and enrichment scripts. Pulling competitor pricing pages weekly, scraping a list of LinkedIn URLs for company info, monitoring a set of sites for new blog posts. SaaS pricing for this stuff is wild ($99 to $500 a month is common) and the actual code is maybe 80 lines.
Internal reporting glue. Pulling from GA4, GSC, and a CRM into one Google Sheet or Notion database. Zapier and Make can do this, but they get expensive and brittle past a certain complexity. A small Python script triggered by cron is cheaper and easier to debug once you can read it.
One-off data cleanups. Deduping a 40,000-row contact list with fuzzy matching. Standardizing job titles across CRM imports. Splitting a messy CSV by region and emailing each chunk to a different rep.
Custom GPT-style tools for the team. A Slack bot that answers questions from your brand guidelines doc. A landing page generator that pulls from your product taxonomy. These used to require a developer. Now they require a weekend.
Where it falls apart
I want to be honest about the failure modes because the demos always skip them.
The first wall is environment setup. Getting Python installed, getting API keys into the right place, handling permissions on macOS. Cursor helps, but if you’ve never opened a terminal, the first two hours feel hostile. Get past that and the rest is genuinely easier.
The second wall is anything that touches authentication. OAuth flows, Google service accounts, anything with a token that expires. The model can write the code, but when it breaks (and it will), debugging requires understanding what’s actually happening. This is where most non-engineers get stuck and quit.
The third wall is scale. A script that processes 500 rows is fine. The same script trying to process 500,000 rows with rate limits and retries is a different animal. If you’re building something that needs to run reliably for other people, you’ve crossed back into needing real engineering judgment.
How I’d actually start
If you’ve never touched code and you’re a marketer reading this, here’s the order I’d go in.
Install Cursor. Pick one specific annoying task you do every week that involves a spreadsheet or a copy-paste loop. Open a new folder in Cursor and describe the task in the chat panel. Let the agent write a script. Run it. When it breaks, paste the error back in and let it fix itself. Repeat until it works.
The first project should be small enough that you can verify the output by hand. The second one can be twice as big. By the fourth or fifth project, you’ll have intuition for what’s worth building and what’s worth buying.
The mindset shift that matters: stop thinking of code as a thing engineers write. Start thinking of it as a thing you describe and review. You’re the product manager and the QA. The model is the junior dev. That framing changes what feels possible.
The catch most marketers will miss is that building your own tools creates an internal maintenance burden you didn’t have when you were paying a vendor. The $200 a month SaaS includes someone fixing it when an API changes. Your script does not. So my rule: build the things you’d happily rebuild in an hour if they broke, and keep buying the things you wouldn’t. The economics of this stack work best on the long tail of small, weird, specific problems that no SaaS would ever build for you anyway.