Standalone offerings audit

Standalone Offerings Audit

Date: May 1, 2026

This audit lists every offer surface in this codebase that can reasonably be sold, packaged, provisioned, routed, or presented as a standalone customer outcome.

Scope

An item is counted as a standalone offering when it meets at least one of these conditions:

• It appears in the provisionable package catalog.
• It has a public package, offer, industry, deliverable, funnel, directory, or documentation route.
• It is represented as a commercial plan, GTM play, funnel blueprint, or live deliverable module that can be bought or bundled independently.
• It has enough onboarding, delivery, or routing structure to be sold as a customer-facing outcome.

Not every item below has the same production readiness. This audit separates primary products from modules, vertical wrappers, funnel blueprints, pricing plans, and GTM plays.

Source Files Audited

• src/lib/package-catalog.ts
• src/lib/package-persona-blueprints.ts
• src/lib/live-deliverables.ts
• src/lib/catalog.ts
• src/lib/offer-engine.ts
• src/lib/public-offer.ts
• src/lib/funnel-library.ts
• src/config/gtm-use-cases.ts
• src/app/packages/**
• src/app/offers/**
• src/app/industries/**
• src/app/deliverables/**
• src/app/directory/**
• src/app/funnel/**
• src/app/marketplace/**
• docs/PRODUCT-SURFACES.md

Executive Count

Primary Standalone Products

These are the strongest candidates for standalone sales because they are defined in the package catalog.

Status definitions:

• Complete automation contract: the package has at least 8 deliverables and at least 4 autonomous workflow steps under the current package automation heuristic.
• Provisionable, workflow gap: the package has deliverables and onboarding fields, but does not yet define autonomous workflow steps. It can be sold as a product concept, but the codebase does not yet prove full automatic delivery.

Persona and Service Blueprint Coverage

Every primary package now has a dedicated persona blueprint in src/lib/package-persona-blueprints.ts and every /packages/[slug] page renders it.

Each primary package page now shows:

• who the offer is for
• the decision maker
• the resident, end user, downstream customer, or internal operator served
• the market-facing messaging
• specific pain points
• expected result
• delivery shape
• user journey
• service blueprint
• verification posture

The package provisioning test suite now requires every package to include these persona fields before the build can be considered healthy.

Canonical Microscopic Landing Pages

The website now exposes a canonical landing layer:

• /solutions
• /solutions/[slug]

Every microscopic offer landing page uses the same clarity contract:

• who the offer is for
• decision maker
• resident, end user, downstream customer, or internal operator
• direct market-facing message
• specific pain points
• expected outcome
• delivered shape and form
• proof of source or readiness
• standalone headline price
• setup price
• recurring price
• performance upside guidance
• pricing rationale
• internal CTA to the source or launch surface

The tests/microscopic-offer-landings.test.ts test verifies that all 74 current microscopic offers have this contract, including standalone pricing.

Standalone Pricing Method

Each /solutions/[slug] page now treats the offer as if it had its own standalone website and brand. The page does not ask the buyer to price a tool stack. It prices the completed outcome, including setup, delivery, monitoring, and optional performance upside.

The price bands were set from current 2026 market anchors:

• AI receptionist and voice-agent offers are priced against managed receptionist alternatives, AI receptionist monthly plans, and voice usage costs.
• Local SEO, med spa growth, paid media, and PPC-adjacent offers are priced against agency retainers rather than tool subscriptions.
• Content repurposing, social media, and distribution offers are priced against monthly management retainers, then adjusted downward when the buyer supplies source content.
• Lead reactivation, lead generation, and speed-to-lead offers include performance upside because booked appointments and qualified leads are measurable.
• Landing page, funnel, lead magnet, and deliverable-module offers are priced against one-off agency/freelancer builds with optional monthly optimization.
• AI audit, chief-of-staff, business OS, and operating-system offers are priced as consulting or implementation engagements because they change internal operations.

Every offer exposes:

• headline standalone price
• setup price or setup range
• recurring price or no-retainer statement
• performance upside guidance
• best-fit buyer
• pricing rationale

Live Deliverable Modules

These are smaller standalone modules exposed as live deliverable pages. They can be sold independently, used as plan features, or bundled into package products.

Vertical Offer Paths

These are niche wrappers that can package the core products for a market. They are not all separate product engines, but each can be offered as a market-specific version of the catalog.

Funnel Blueprints

These are standalone funnel buildouts. They can be sold as packaged funnel SKUs or used inside the larger packages.

GTM Revenue Plays

These are sellable go-to-market plays. Some should remain GTM motions until they are promoted into package catalog products.

Commercial Plans

These are standalone commercial containers, not product outcomes by themselves. They determine capacity and available deliverables.

Frontend Exposure Audit

Critical Gaps

1. Twelve primary products are not fully automated by the codebase's own package automation heuristic because they do not define autonomous workflow steps.
2. Some GTM revenue plays are sellable concepts but are not yet product catalog packages. This can confuse operators about whether they are live products, strategies, or future SKUs.
3. The niche catalog and OFFER_TEMPLATES do not fully align. For example, the catalog uses tech and health, while offer templates include technology and healthcare. This means some vertical offer pages can miss richer niche-specific blueprint content.
4. Vertical pages are market wrappers, not always separate delivery engines. They should be positioned as niche versions of core products unless the catalog defines a dedicated package.
5. Live deliverables are modules. They can be sold independently, but the strongest customer promise comes from bundling them into outcome packages.
6. External-account actions, credentials, live sending, phone numbers, payment processing, and real platform API access still depend on client-provided credentials and configured integrations. The website should avoid claiming guaranteed external provisioning when required credentials are missing.
7. Audience language is mixed across B2B operator, B2B client-business, B2B2C downstream customer, and internal operator surfaces. Primary package pages now separate buyer, decision maker, resident/end user, journey, and service blueprint, but the broader site navigation should still reinforce this hierarchy.

Recommended Standalone Offer Architecture

Use this hierarchy to avoid confusing customers:

1. Primary products: the 23 package catalog items.
2. Modules: the 12 live deliverables.
3. Vertical wrappers: the 16 niche offer paths.
4. Funnel SKUs: the 10 funnel blueprints.
5. GTM motions: the 10 revenue plays.
6. Commercial containers: the 3 public plans.

Highest-Priority Fixes

1. Add autonomous workflow definitions to the 12 provisionable packages with workflow gaps.
2. Align nicheCatalog slugs with OFFER_TEMPLATES, or add aliases so every vertical page receives the right offer blueprint.
3. Promote only the GTM plays that are truly productized into package-catalog.ts; keep the rest clearly labeled as GTM strategies.
4. Add a buyer selector across the public site: operator, agency, SMB owner, vertical business, or internal admin.
5. Make the package pages the canonical product list, and treat deliverables, funnels, and verticals as supporting ways to package those products.