Judge a marketing engineering partner by what is still running a quarter after the builders move on: on your own data, with someone who did not build it already changing it and able to switch it off. A deck runs nothing, a demo runs on sample data with its builder at the keyboard, and a license runs nothing until somebody builds on it.
The test is for systems you are buying to keep: lead routing, qualification, the weekly pipeline report, and outbound. An experiment you mean to throw away needs none of it. The owner can be on your payroll or on the consultancy’s team, but never the person who built it.
Empact Partners builds the agents its own consultants lean on every day, and since 2020 it has done its go-to-market work as a consultancy from inside B2B software marketing teams. We build agents for partners as part of our RevOps work, so we sell what this verdict recommends. Our own systems face the same test, and some of them fail it.
A Demo Is The Builder At The Keyboard
Everything you see before you sign is evidence about the person who built it. The demo works because its builder is driving. The architecture slide works because nobody has run it yet. The license works the way a gym membership works.
A quarter later the builder is on other work, and something underneath the system has changed: a field in the CRM, a tool the team swapped, a rule sales rewrote in a meeting nobody minuted. That is the first week nobody is in the room to cover for it.
We use a quarter as the horizon because it is long enough for both to happen and short enough to write into a contract. Ask these before you sign, and ask to see each answer working:
The system I am proudest of fails the first one.
Ownership Shows Up In The Change History
I built our Reddit watcher. It checks the Reddit threads we track for partners around the clock and posts what changed to Slack. It has run on a hosted service since June, with an off switch and alarms I am proud of. Every change made to it since June is mine. On the first question, it fails.
The opposite case is a content system one of our consultants built in May for a B2B software partner’s blog. Its rules are the partner’s own editors’ reviews, each one written in as a rule. Five people who did not build it have changed it since, the latest on November 1, and it still drafts into the partner’s own publishing system.
.png)
Who changes it only matters if it runs somewhere your team controls and reads what your team holds to be true.
Where It Runs And What It Reads Set Its Lifespan
My laptop died at the end of August, and every scheduled job that lived only on it died with it. The ones whose code was on GitHub came back when we reinstalled them. The Reddit watcher, on its hosted service, never stopped. Ask a builder whose machine the system runs on, whose login it uses, and what happens to both when they leave.
What it reads is the quieter half. One of our consultants built a second partner’s content system in September on rules that were our reading of how that partner writes. The partner’s own writing guide disagreed on how the product is named and on words the partner never uses, and we retired the system ten days after building it.
Same consultancy, same kind of system, opposite outcomes. The one that reads its partner’s own rulings has run since May. The one that read our interpretation lasted ten days, and its replacement was built from the partner’s guide.
A System Has To Stop Loudly, On Purpose And By Accident
When the second version of the Reddit watcher replaced the first in June, we stopped the first one’s schedule. It had two. The schedule inside the first watcher’s own database kept syncing and pushing to our boards four times a day until September 26. We found it while shutting down the board tool it wrote to, 113 days after we retired it.
The accidental stop is worse, because nothing announces it. On August 2 the database behind the watcher hit its usage limit, and every call failed for about 21 and a half hours. The worker never went down. The alert arrived 40 hours after the data stopped, because every alarm we had built ran through the database that had failed.
.png)
The fix was two alarms that share nothing: one inside the worker that never touches the database, and one inside the database that runs on its own clock every five minutes. The off switch leaves a record too. While it is off, every job writes down that it skipped its run, and if the switch stays off too long, an alert goes out.
Our partner panels cost money every week they collect, so their offboarding page opens with the one command that stops the weekly job. Without it, the job keeps collecting long after the partnership ends.
A Vendor’s Engineer Is Free
The strongest objection comes with the license. Vendors now send an engineer to build on their product for you at no extra cost, and that engineer knows the product better than any consultant will. If what they leave behind passes these questions, take it. Paying us for the same outcome would make no sense.
Run the questions anyway. If only the vendor’s engineer can change it, it runs inside the vendor’s product, it reads the vendor’s copy of your data, and it stops when the license does, you have bought a license with an engineer attached.
That can be the right purchase. The difference from a system your team owns shows the week the engineer moves to the next rollout.
A consultancy’s builder who is the only name in the history fails in exactly the same way, which is why our own builds get the same scorecard.
Our Own Builds, Scored On The Same Questions
Here is how our systems answer, as of November 3:
| Build | Running since | Who changes it now | Where it runs | How it stops | A quarter on? |
|---|---|---|---|---|---|
| A partner’s content system | May 19 | Five people who did not build it | Writers’ machines; drafts land in the partner’s own publishing system | Runs only when a writer starts it | Yes |
| Our Reddit watcher | June | Its builder, alone | A hosted service | A switch that alerts if it stays off | Yes, except who changes it |
| Our first Reddit watcher | Retired in June | Nobody | A schedule inside its own database | Ran 113 days after we retired it | Stopped late |
| Our partner panels | The first week of September | The consultant on each partnership | The owner’s laptop and a hosted app | An offboarding page that opens with the stop | December |
| A second partner’s content system | September 14 | Nobody, retired | The writers’ machines | Retired September 24 | No, ten days |
The content system from May passes on the question that matters most: its builder still works on it, and so do five people who did not build it, so it no longer waits for one person.
The watcher passes on everything but that question. The panels reach their quarter in December, and until then they are a promise. The second content system failed on what it read before anyone could ask who owned it.
Put The Answers In The Scope Before Anyone Builds
Write the answers into the scope beside the number the system is meant to move, and make the name next to “who changes it” somebody other than the builder. A proposal that cannot fill those lines before the build is offering you a demo with a contract attached.
Empact Partners scopes agents for a partner’s revenue work the same way in our RevOps workstream, whether the job is lead routing, qualification, the pipeline report, or outbound:
If your revenue team needs agents that keep working after the people who built them have moved on, book a meeting with me, and we’ll see together whether we should be the ones building them.
