Can you show a live system you’ve shipped that’s still running in production?
Yes — ours. Rad Shift’s own outbound runs on the exact architecture this build ships: Apollo feeding Instantly, replies firing a direct webhook into Zoho CRM, every record attributed to its campaign and sequence. Our CRM has never been manually updated. On the scoping call we share a screen and walk a live reply through the whole path — campaign, webhook, record, routing.
What happens when a step fails — and how do we find out?
Nothing in the build fails silently. Each handoff is a direct webhook with defined failure behaviour: failed deliveries retry, and anything that still can’t complete is logged and raised to a named owner instead of vanishing. The runbook you receive documents every failure point in the chain — what the system does about it, and who gets told.
Which tools have you actually integrated before?
By name: Apollo, Instantly, Zoho, and HubSpot. The stack we run ourselves is Apollo → Instantly → Zoho over a direct webhook, so those three we operate daily, not just configure. CRM wiring for HubSpot follows the same webhook pattern. If your stack differs, the two-day diagnostic is where it gets mapped — before any build hours are spent.
How do you scope and price — fixed scope, time and materials, or retainer?
Fixed scope, fixed price, no retainer. The category norm is a custom quote at the end of a discovery arc; ours is a number that locks at the two-day diagnostic — the Lead-Gen Stack starts at $4,999 USD — and goes into the SOW before a build hour is spent. It doesn’t move mid-build, and nothing recurring follows it.
What does handoff look like — are we dependent on you afterwards?
You’re handed a running system and everything needed to run it without us: the runbook, the playbooks, an acceptance checklist you sign against, and every credential — registrar, DNS, inboxes, CRM — in your own accounts. There’s no retainer and nothing that phones home to us. Dependency after handover would be a defect.
Our domains are already burned. Can this still work?
Yes — the build doesn’t send from your existing domains at all. We provision fresh custom sending domains, separate from your primary, authenticate them with SPF, DKIM, and DMARC, and start warmup on day one; the ramp to full volume runs about three weeks and hands over with its checklist. Your primary domain stays out of the sending path entirely — which also protects the reputation your everyday email depends on.
Do we own the sending domains?
Yes — outright. They’re registered in your registrar account, the DNS lives with you, and the inboxes are yours. Like everything else in the build, they pass through at handover: we hold nothing back and keep no access you didn’t grant.
What happens to deliverability after you leave?
Deliverability is a practice, and the practice is what we hand over: authenticated domains, the warmup ramp checklist if the window is still running, and playbooks that spell out sending volumes, rotation, and list hygiene. The system runs entirely on your accounts, so nothing degrades because we stepped away — the posture you inherit is documented, not tribal knowledge.
We already have Apollo and Instantly. Do we pay for tooling twice?
No. The build runs on the licences and accounts you already own — the diagnostic maps what’s configured well and keeps it. If part of your setup is already sound, the findings brief says so and the scope narrows; findings are never padded into work.
We use a different CRM. Does the build still fit?
The wiring is a direct webhook into the CRM, and the pattern is CRM-agnostic by design. Zoho and HubSpot we’ve integrated by name; Salesforce and others follow the same pattern. Which CRM you run is one of the first things the two-day diagnostic maps, so the answer is confirmed before the price locks — nothing is replaced by default.
Who actually does the work?
The people who scope it lead it. Named owners run the diagnostic, the build, and the handover — no juniors learning on your instance, no account layer between you and the person doing the wiring. If a disclosed delivery partner ever executes a piece, they’re named in the SOW with your consent before any access exists — never silently.
What if it isn’t done in two weeks?
The two-week schedule holds because the thing that usually blows it — unmapped scope — is removed before the build starts: scope quotes the diagnostic’s findings and locks. The one clock that runs longer by design is domain warmup, which starts on day one and ramps about three weeks; it’s named in the SOW with its date and hands over with its checklist. The build doesn’t drift, because the scope can’t.