The most useful skill on my marketing teams has rarely been a marketing skill. It has been the ability to open a code editor on a Tuesday and have the thing running by Friday.
Most marketing leaders face a version of the same fork. You need a piece of infrastructure: a funnel, an integration, a members area, a data feed. You have three ways to get it.
Buy a tool that mostly does the job. Borrow an engineer from a team that already has its own roadmap. Or build it yourself. Scott Brinker's 2026 marketing technology landscape counts 15,505 products, so the first of those is never short of candidates.
The received wisdom says marketing buys and engineering builds, and for a long time that split made sense. It makes far less sense once the marketing function can ship its own production code.
Leverage Companies brought me on as its first marketing hire, and the role came with an unusual condition: there was no engineering team to borrow from.
Leverage Companies is a holding company, and under its roof sat a private-lending brand, a real-estate wholesaling operation, and an education-and-community business. Each needed marketing infrastructure that did not exist yet, and the line to build it was a line of one.
So I built. This is what that changed, and where I learned to stop.
A members area, and a browser problem most marketers hand off
The education business needed a members-only platform: a place where people who paid could sign in once and move between the marketing site where they joined and the separate community tool where the community actually lived.
That sounds trivial. It is one of the harder problems in front-end web work right now, because browsers have spent years making exactly this kind of shared sign-on difficult in the name of privacy.
Safari in particular treats a login cookie set on one domain and read on another as the fingerprint of a tracker, and quietly drops it. A member logs in, clicks through to the community, and gets asked to log in again.
This is the moment where most marketing teams file a ticket and wait. I built the bridge instead: a sign-on flow that carries identity across the two domains without depending on the third-party cookie the browser refuses to honor.
It took a few days of arguing with the browser's privacy model on its own terms. What came out was a members area that felt like one product across two domains, shipped without a ticket, a sprint, or a new vendor.
One lead-gen backend, deployed across brands
The next thing every brand wanted was a lead funnel: a branching set of questions that qualifies a visitor and routes them to the right next step. The obvious approaches are to build one per brand, or to buy a quiz tool per brand and pay for each seat.
I built a single lead-gen backend once, then deployed the same codebase across the brands with a per-brand toggle, so each got its own funnel without its own rebuild.
Then came the part that mattered more than the code. A funnel earns its keep only if the people running marketing can change the questions, and those people are not developers.
So I built an admin tool with a visual flow-builder, where a non-technical marketer could edit the branching question tree, add a path, reorder steps, and publish, with no developer and no deploy in the loop.
The engineering effort went into making sure no engineering effort was needed to run it day to day.
When rented automation gets expensive, own it
A lot of marketing automation starts life on a per-task platform: the kind of tool that connects app A to app B and charges by the run.
It is the right tool to start with. It gets an integration live in an afternoon with no code, and at low volume the price is invisible.
The catch is that the pricing scales with your success. Every automation you add and every extra bit of traffic pushes the monthly bill up, because you are paying per run, forever.
When a handful of those workflows grew into the tens of thousands of runs a month, the arithmetic stopped working. I moved the highest-volume ones onto a self-hosted webhook: the same logic, running on infrastructure that costs a flat and near-trivial amount whether it fires a thousand times or a million.
The per-task platform kept the long tail of low-volume glue, where it still earns its price. The heavy lifting came in-house.
The trigger to move was mechanical. A workflow that once cost pennies had quietly become a four-figure line item, doing nothing it had not done a year before. The numbers above are illustrative; the pattern repeats in any per-run bill at volume.
Most martech subscriptions rent you a worse version of something that three weeks of building would let you own outright.
The obvious reflex here is to go build everything, which is its own kind of trap. But the builds only matter because of what they change.
What changes when marketing can build
Put these four builds together and the calculus that governs every buy-borrow-build decision quietly flips. When building is genuinely on the table, a tool earns its subscription only by being better than the version you could make yourself.
Mere availability stops being a selling point. Gartner's 2023 martech survey found marketing teams using a third of their stack's capability, down from 42% the year before.
Vendor lock-in loses most of its menace too, because the thing you would be locked into is a thing you could rebuild if you had to.
Knowing what is easy to build changes what you dare to ask for. The expensive constraint turns out to be the wait in someone else's queue far more often than the tool itself.
None of this is abstract. If your customer records are scattered across systems that each claim a different version of the truth, that is a build too; I made one for this same holding company and wrote it up as the customer-data platform I built myself.
Swapping one email vendor for another without touching the CRM only worked because the integration layer was mine to redesign, which I cover in the ESP migration. All three fold into my growth operating system essay.
The part nobody puts on the recruiting slide
Every system I have described is now a system that has to be maintained. Code you ship is code you own at three in the morning when it breaks.
A vendor has an on-call team and a status page; your webhook has you. Google's site reliability engineers call that upkeep toil, the manual and repetitive work that scales linearly as a service grows.
That cost is real, and it is the reason building indiscriminately is how a marketing team turns itself into an understaffed software company nobody asked for.
So the discipline is a matter of taste more than coding ability: knowing which things are safe to build and which will hurt you.
The safe ones are dull, small, and easy to swap out. Glue between two tools. A funnel. An internal admin panel. Small pieces with clear edges that another person could rewrite in a week if you disappeared.
The dangerous ones share a smell. Billing, where a bug costs real money and a chargeback.
Authentication and the security around it, where a mistake is a breach with your name on it. Anything with a compliance surface, where the penalty for getting it wrong shows up on legal letterhead.
I built a members area; I did not build the payment processor behind it, and I did not build the identity security underneath the sign-on. Those I bought, on purpose, from companies whose whole job is to get them right.
Build boring and replaceable, and never build the thing that can sue you. The whole skill is knowing which category a given piece is in.
The coding is the cheap half; you can hire it or learn it. What you cannot shortcut is having owned the outcome the last time a build went wrong, which teaches the sorting in a way that writing the build never does.
So when someone asks whether marketers should learn to code, the honest answer is that they should learn enough to change the question.
A marketing team that can ship stops treating the tool market as the full menu of what is possible, and starts treating it as a convenience it can take or leave. That shift, more than any single build, is what having the ability buys you.
If your roadmap is stuck in another team's queue and you are weighing whether to buy, borrow, or build, this is the kind of call I help make. Let's talk.