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. Both run on the identical subscription mechanics, the same flat $5,995-a-month price, 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 ASTRA. 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 workflows 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 ASTRA 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 workflow is being built in a given week.

Acquire and Expand are published as two distinct memberships at the same price, 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 published and certain is the price and the scope of each; 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 Mindlyft membership is about $72,000 a year, flat, with no recruiting cycle. 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 against two flat $5,995-a-month subscriptions covering the same ground.

No. ASTRA 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 workflow 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.