Acquire vs Expand: Choosing a Mindlyft Membership

The split is the moment a customer signs. Acquire is everything engineered to get a signature: pipeline generation, outbound and inbound systems, demand generation, lead qualification, and sales automation. Expand is everything engineered after that signature: onboarding, adoption, renewals, expansion, support automation, and post-call follow-through. Each has its own flat fee per 4-week cycle, quoted on the free review call, and both run on the identical subscription mechanics: the same unlimited queue with one active task at a time, the same weekly shipping cadence, and the same approval-gated, logged, reversible execution through A.S.T.R.A. The only thing that changes between the two memberships is which half of the customer lifecycle your requests are drawn from, not how the work is built or governed.

Acquire is for teams whose constraint sits before the deal closes: pipeline that stalls between stages, leads that go unqualified because nobody has time to route them, outbound and inbound handoffs that still require manual work, sales automation that never got built because it fell below every engineering team’s priority list. It is worth being precise about the boundary, though. Acquire engineers the systems and automation around outbound and inbound, routing logic, qualification rules, sales-to-CRM connections, it does not run cold-email deliverability or domain warmup, build campaign sequences, or do contact scraping and list building. Those are explicitly out of scope for Mindlyft regardless of which membership you are on, because they sit in a different discipline than GTM engineering: deliverability infrastructure and prospecting data, not the systems that move a qualified lead through your stack.

Expand is for teams whose constraint sits after the deal closes: onboarding that stalls without a rep manually chasing every step, renewal risk that surfaces too late to act on because nobody is watching for it consistently, sales-to-CS handoffs that lose context the moment a deal closes, and the post-call CRM updates, tickets, and follow-ups that die in a rep’s memory instead of getting logged where the rest of the team can see them. This is the half of GTM engineering most agencies and fractional hires never touch, since the market has historically concentrated on outbound and acquisition and left post-sale execution as an afterthought. Expand is built specifically for the CSMs, solutions engineers, TAMs, and RevOps teams doing that post-sale execution work day to day, and it runs through the same approval-gated A.S.T.R.A. layer as Acquire: customer-facing and system-of-record writes still wait for a human, whichever membership they came from. The commitment taxonomy that drives post-call execution, a CRM update owed, a follow-up owed, a ticket owed, a handoff owed, a risk flag, is the same detection layer Expand requests draw on regardless of which specific system is being built in a given week.

Acquire and Expand are offered as two distinct memberships, each with its own flat fee, not tiers of a single plan you upgrade between. If your team’s bottleneck moves from pre-sale to post-sale over time, or you need both halves of the lifecycle engineered at once because the leak is on both sides of the signature, the exact mechanics of switching memberships or running two in parallel are worth confirming directly on a Talk to us call rather than assuming either way. What is fixed is the scope of each and the flat fee you agree on the call; the logistics of combining them are a conversation, not a self-serve toggle.

Start with whichever half of the lifecycle is visibly costing you revenue right now. If deals are stalling before signature, leads sit unqualified for days, or outbound and inbound require constant manual triage from a rep who should be selling, start with Acquire. If deals close and then the handoff drops, onboarding has no consistent execution, renewal risk gets noticed only after a customer has already mentally checked out, or the commitments made on every customer call scatter across five tools instead of landing in the CRM, start with Expand. Teams that eventually need both usually know it because the first membership’s queue keeps surfacing requests that clearly belong to the other half of the lifecycle, at which point it is worth raising a second membership directly.

Under Acquire, a typical request looks like: route inbound leads to the right owner based on fit signals already in the CRM, enforce required fields before a lead can advance stages, or draft the sales automation that moves a qualified prospect from one tool to the next without a rep copying fields by hand. Under Expand, a typical request looks like: parse a customer call for commitments and draft the CRM stage change and follow-up email, hold both for approval, file the Jira ticket a support escalation needs, or set up the signals that flag renewal risk from usage data before a QBR. Both kinds of requests move through the same queue, the same weekly shipping cadence, and the same approval gate, the difference is entirely which side of the signature the work sits on, not how it is built, reviewed, or logged.

The same cost comparison applies to either membership individually: a senior, fully loaded GTM engineer runs roughly $132,000 to $241,000 a year whether the work in question is pre-sale or post-sale, plus recruiting fees and a quarter of ramp before they ship anything. Either membership is one flat fee per 4-week cycle, quoted on the free review call, with no recruiting fee and no ramp. A team that tried to hire separately for both halves of the lifecycle, one specialist for Acquire-shaped work and one for Expand-shaped work, would be looking at two fully loaded salaries, roughly $264,000 to $482,000 a year, against both memberships together on one flat fee per cycle, covering the same ground.

No. A.S.T.R.A. gates actions by consequence, not by which membership the request came from. A reversible internal write, drafting a note, enriching a lead record, preparing a follow-up email, can run on its own under either membership because it is cheap to undo. Anything that touches a customer or a system of record waits for a human to approve it first, whether that is a stage change coming out of an Acquire-side qualification system or a renewal-risk alert coming out of an Expand-side onboarding flow. The gate is a property of what the action does, not of which half of the customer lifecycle produced it, so switching between memberships never changes how carefully a write is handled.