Hybrid Landing Pages
How do you build a website that sells AND teaches — using components you already own?
A hybrid landing page combines informative content with sales content. The platform makes this repeatable: venture content in the Dream repo, component composition in the Engineering repo. Same components, different copy, new site.
The Protocol
Every venture landing page follows this pipeline. Dream repo produces the WHAT. Engineering repo builds the HOW.
Phase 1: Content Brief (Dream Repo)
Complete the venture run first. The 9-phase algorithm (SCAN through MEASURE) produces all the source material.
Required inputs before engineering handoff:
| Source | What It Provides | Location Pattern |
|---|---|---|
| Tight Five | Headlines, rhetoric mapping, pitch versions | .ventures/{slug}/tight-five.md |
| Strategy | Positioning statement, competitive map, GTM | .ventures/{slug}/strategy.md |
| Business Plan | Pricing, unit economics, packages | src/pages/ventures/{slug}/index.md |
| Sales Pitch | SPIN framework, objections, conversion funnel | src/pages/ventures/{slug}/sales-pitch/index.md |
| Outreach Plan | Offer structure, CTA copy, audit protocol | .ventures/{slug}/outreach-plan.md |
Phase 2: Section Mapping
Map each page section to a specific platform component. No custom components unless a gap exists.
Standard section sequence:
| # | Section | Component | Data Type |
|---|---|---|---|
| 1 | Hero | HeroWithImage or HeroSplit | headline, subheadline, cta, image |
| 2 | Stats | StatsCounter | Stat[] — 3 proof points from financials |
| 3 | Problem | BenefitSection | title, 3 pain points as benefits (inverted) |
| 4 | Solution | FeatureGrid | Feature[] — 3-5 steps with Lucide icons |
| 5 | Differentiator | BenefitSection | Benefit[] — "us vs them" as positive statements |
| 6 | Social Proof | TestimonialCard + LogoWall | Testimonial, Logo[] |
| 7 | Pricing | PricingTable | PricingTier[] with PricingFeature[] per tier |
| 8 | FAQ | FAQSection | FAQItem[] — 5 Q&As |
| 9 | Footer CTA | CTABanner | headline, cta |
| 10 | Newsletter | NewsletterSection | headline, submit label |
Phase 3: Data Structures
Write the exact TypeScript objects that engineering drops into the page. No placeholder text except genuine unknowns (e.g., testimonials before pilot clients exist).
Required typed objects:
stats: Stat[]features: Feature[]pricingTiers: PricingTier[](withPricingFeature[]per tier)faqItems: FAQItem[]testimonial: Testimonial(or placeholder)differentiators: Benefit[]
All types imported from @stackmates/ui-marketing.
Phase 4: Copy Deck
All final copy in one place. Engineering copies verbatim.
| Section | Copy Source |
|---|---|
| Hero headline/subhead | Tight Five answer 1 + current brief |
| Problem copy | Sales pitch SPIN framework |
| Solution steps | Outreach plan audit protocol |
| Pricing | Business plan packages table |
| FAQ | Landing page brief |
| CTA language | Outreach plan offer structure |
Phase 5: Visual Direction
| Element | Spec |
|---|---|
| Color palette | Theme variant name + 6-8 CSS custom property values |
| Typography | Font choices (or inherit from design system) |
| Hero image | Source file or description for illustration |
| Icons | Lucide icon names for each feature step |
| Tone | One sentence describing the voice |
Phase 6: Integration Specs
| Integration | What to Specify |
|---|---|
| Booking CTA | Calendly/Cal.com URL pattern for each tier |
| Analytics | Event names and payloads (reuse lib/analytics.ts pattern) |
| Newsletter | Email capture + storage service |
| Domain | Vercel project + DNS |
| SEO | Title, description, keywords, og:image |
Phase 7: Platform Readiness
Before engineering handoff, verify what the platform already provides vs what needs building or external services.
| Check | How | Fail If |
|---|---|---|
| Map each integration to a feature matrix ID | Read src/pages/feature-matrix.md | Any integration has no plan (built, build, or external) |
| Verify built features (L2+) | Read engineering repo for actual adapters and endpoints | Handoff claims "reuse" but the adapter is a stub |
| Flag L0 blockers | List features at L0 that block launch | Launch-critical feature at L0 with no interim solution |
| Check CRM readiness | Verify repository implementations exist, not just schemas | Handoff assumes CRM tracking but repos are unimplemented |
| Confirm interim solutions | For each L0 feature, document the external fallback | "TBD" appears anywhere in the integration spec |
Output: Platform Dependencies table split into three sections — Built and Reusable (L2-L3), Needs Building (L0), and Architected but Incomplete. No "TBD" integrations remain. An engineer reading the handoff knows what to import from existing libs vs what to build new.
Phase 8: Responsive Behavior
Specify stack/reflow behavior at 375px, 768px, 1024px. The platform components handle most of this, but call out pricing card stacking, hero image placement, and CTA sizing.
Content Structure
The 8-step hybrid content flow. This is the WHAT to say.
Topic and Title
- Identify the main problem your business solves.
- Create a title that addresses the problem.
Write the Content
- Connect with the reader over their problem.
- Make the problem relatable with specific examples.
- Transition to a positive outlook.
- Structure the main content as a list or steps.
Bridge the Solution
- Transitional sentence from content to sales.
- Introduce the company and expertise.
- Include a photo or illustration to build trust.
- First CTA with specific action text.
Highlight Benefits
- Three main benefits, not features.
- Icons or images for each benefit.
Showcase Testimonials
- Video testimonials if available.
- Testimonials that highlight results or address objections.
- Customer name and photo.
Simple Process
- Three-step process showing how to get started.
- Clear, effortless for the client.
Beneficial Outcomes
- Feature list for logical decision-makers.
- Brief descriptions for each.
Final Call-to-Action
- Simple CTA block — are you ready?
- Action-oriented button text.
Platform Reuse
The same components power every venture site. The economics:
| Shared (build once) | Venture-Specific (per site) |
|---|---|
| 25 marketing components | Theme variant (color palette) |
| Tailwind preset + design tokens | Copy deck (from venture run) |
| Analytics library | Hero illustration |
| Vercel deployment pipeline | Booking integration URLs |
| Auth + payments (when needed) | Domain configuration |
Reference implementations:
apps/dreamineering/drmg-design-system/src/app/(marketing)/— design system showcasesrc/pages/ventures/berleytrails/business-plan/landing-page/— first venture handoff (BerleyTrails)
Context
- Web Design Prompts — Visual design engine (HOW it looks)
- Landing Page Checklist — Conversion audit criteria
This page handles WHAT to say (structure + substance) and HOW to hand it off (the protocol). The web design spec handles HOW it looks (design system + animation). Use both.
Questions
Does the protocol produce engineering handoffs that build without questions — or does every venture still need custom interpretation?
- At what point does a venture need components that do not exist in the shared library?
- Is the 10-section standard sequence sufficient for all service businesses, or do product businesses need a different flow?
- What is the minimum viable copy deck — which sections can ship with placeholder text and which must be final?