Skip to content

Design: AI Page Builder for Raklet (Hybrid)

Generated by /office-hours on 2026-05-21 Branch: master Repo: rakletv3 Status: APPROVED Mode: Intrapreneurship (Startup)

Problem Statement

Raklet's current page editor is a free-form textarea. Competitors (Wix, Squarespace, Webflow, Framer) ship drag-and-drop and increasingly AI-driven builders. Raklet needs a better page-building primitive AND wants to use it as an onboarding wow moment. The bet: skip the drag-and-drop arms race, leapfrog directly to an AI-driven generator that produces a complete member portal — pages + nav + data-aware components — from minimal input (URL, PDF, or short description).

Demand Evidence

  • Anecdotal from sales/support (acknowledged B+ signal). Sales/CS regularly hear "your page builder is too basic" and "how do I make my portal look like X" in calls. No churn-data or onboarding-drop-off numbers attached yet.
  • Workarounds observed across customer base: customers grind through the textarea, host their real site on Wix/Webflow + use Raklet for gated areas, hire freelancers, or skip having a portal entirely.
  • One successful manual proof: 2barevents — CEO fed their PDF into ChatGPT, pasted generated HTML into Raklet's Social Page editor. Result live at https://2barevents.raklet.com/. This is the existence proof that the LLM output quality is sufficient.

Status Quo

"Page builder is critical for small orgs as they want to manage their online presence" — CEO's own framing. All four workarounds happen in the customer base: textarea + manual HTML, external builder + embed, paid freelancer/agency, or give up and host elsewhere. The last category costs Raklet "home base" positioning.

Target User & Narrowest Wedge

Wedge user: non-technical org owner. Two specific personas, same UX: - Onboarding founder (2barevents-style) — first 30 minutes of Raklet signup, zero patience, wants a portal that looks like their existing brand. - Volunteer / part-time org lead — existing customer stuck on the textarea, wants an AI chat that builds individual pages.

Both prefer magic over control. Pixel control is explicitly a non-goal for V1. Editing primitive = chat + regenerate. If you need a designer's editor, you are not the V1 user.

Wedge product: chat-driven AI generation from minimal input, with two surfaces (see Recommended Approach below).

Constraints

  • Storage stays HTML in the existing Social Page table (no schema fork).
  • Generated pages must be data-aware: live members, events, payments are inputs the AI can reference. This is the moat against Wix-style horizontal builders.
  • V1 ships behind a measurable validation gate before broader investment.
  • No drag-and-drop in V1. Drag-and-drop is a possible V2 for power users IF demand emerges. Both modes produce HTML documents → no storage conflict.

Premises (approved by CEO)

  1. Wedge user is the non-technical org owner. Pixel control is a non-goal.
  2. Differentiator is Raklet-data-aware AI, not "AI page builder."
  3. Demand evidence is anecdotal — V1 ships with a validation gate (~50–100 new signups dogfooded in onboarding before broader rollout).
  4. Distribution is free — existing customers + onboarding funnel.
  5. No drag-and-drop in V1; possible V2 gated on V1 demand. HTML storage shared, so no surface conflict.

Approaches Considered

Approach A — AI Page Drafter

Replace textarea with single-page AI chat. Smallest possible bet. Skips onboarding wow and data-aware moat for V1.

Approach B — AI Portal Wizard

Multimodal input (URL / PDF / description) → full data-aware portal at onboarding AND in-product. Hits both stated goals but bigger surface.

Approach C — Mirror My Site

Scrape existing customer site, recreate in Raklet, then offer data binding. Strong demo moment, excludes orgs without an existing site, carries scraping fragility + IP risk.

Splits commitment by risk:

  • Onboarding surface (Approach B): new signup gets a single chat intake — paste URL, upload PDF, or describe the org. AI generates a complete portal: navigation + 4–6 starter pages (Home, About, Members, Events, Contact, Membership). Generated pages are data-aware via template tokens (e.g. {{members.directory}}, {{events.upcoming}}, {{membership.plans}}) that Raklet renders server-side using live data. Editing primitives: chat ("change hero color", "rewrite About in friendlier tone") + regenerate per page.

  • In-product surface (Approach A): the existing Social Page → Create Page textarea is replaced with an AI chat that produces a single page at a time. Same LLM, same prompt scaffolding, but no portal-level concept — no nav reconfig, no theme propagation. Drop-in replacement for the current textarea.

  • Deferred to V2 (gated on V1 signal): in-product portal-level regenerate (existing customers redo their whole portal with B's generator); drag-and-drop power-user editor; pluggable multi-LLM/agent selection.

This is the right shape because the high-ROI moment (onboarding) justifies the bigger investment (data-aware portal), while the lower-urgency surface (in-product) gets the safer drop-in. V2 expansion is gated on V1 onboarding metrics, satisfying premise #3.

Validation Gate (premise #3)

Before committing to V2 / broader rollout, V1 must clear: - Primary metric: signup → first-published-portal conversion. Target: measurable lift vs current onboarding funnel (baseline TBD from product analytics). - Secondary metric: % of new signups who use the AI flow vs skip it. - Qualitative: ~10 customer interviews after using V1 — does the generated portal match what they would have built themselves? - Cohort size: ~50–100 new signups before decision.

Open Questions

  • Which LLM(s)? Single provider vs router (OpenAI, Anthropic, Gemini)? Cost/latency tradeoffs for onboarding-time generation. Decision belongs in /plan-eng-review.
  • Token rendering layer architecture: server-side template engine vs AI-emits-component-tags-Raklet-resolves. Decision belongs in /plan-eng-review.
  • Multi-language: which locales must V1 ship for? Raklet supports DE/EN/FR/SV/ZH per existing translations — does the AI generate in customer's locale?
  • How do existing customers discover the in-product chat? In-product banner? Forced migration? Side-by-side with old textarea for a transition window?
  • IP/scraping question: if a customer pastes a competitor's URL, what do we do? Need a policy + technical guardrails.
  • Mobile app surface: is the AI page builder accessible from the Raklet mobile app or admin-only? (User noted they added access to mobile repo — worth checking if there's an existing mobile-side admin flow that should mirror this.)

Success Criteria

  • V1 onboarding: new signup can generate and publish a 4–6 page portal in under 5 minutes, no manual HTML touched.
  • V1 in-product: existing customers can create a new Social Page via chat without seeing the textarea. Time-to-first-published-page drops vs the textarea baseline.
  • AI output passes Raklet design QA without human cleanup at ≥80% of trials.
  • Validation gate (above) cleared before V2 scoping starts.

Distribution Plan

No new distribution work required. Surfaces are: - New-signup onboarding flow (existing — wire AI step in). - Admin → Social Pages → Create Page (existing — replace textarea). - Existing Raklet deployment pipeline (master → test → prod promotion per established workflow) covers shipping.

Marketing surface (landing page, in-product announcement) belongs in a separate marketing plan — CEO has marketing repo access; recommend wiring that team in once V1 onboarding metrics validate the bet.

Dependencies

  • Existing data APIs for members / events / payments (already exist; need audit for AI consumability — do they return the right shape for template tokens?).
  • Existing Social Page rendering (already exists; needs template-token resolution layer added).
  • Existing onboarding funnel — need product-side coordination for the intake step.
  • LLM provider account + budget approval.
  • Competitor research from marketing repo (CEO granted access — pull before /plan-eng-review).

The Assignment

One concrete action to take next, before architecture:

Run a 5-customer demand-validation pass. Show 5 existing Raklet customers (mix of org types) a 2-minute Loom: "we'd let you regenerate your portal by chatting with AI — here's what 2barevents looks like." Ask: "Would you re-do your portal with this? What would make it a no-brainer?" Listen for specific objections, not enthusiasm. Convert anecdotal signal into 5 named quotes you can hand to engineering with the design doc.

This converts premise #3's anecdotal signal into something that survives the maximalist review chain (per the prior burn — feedback_review_chain_scope_creep). Do this BEFORE /plan-eng-review, not after.

Next Steps (in order)

  1. The Assignment above (5-customer demand pass).
  2. Pull competitor research from marketing repo — what specifically do Wix ADI / Squarespace AI / Webflow AI / Framer AI do that Raklet must match? What do they NOT do that's our wedge?
  3. /plan-eng-review on this design doc — lock LLM choice, token rendering architecture, data API gaps, validation-gate instrumentation.
  4. Migration branch for any schema changes (per workflow: feedback_migration_branch_first).
  5. Feature-flagged rollout to ≤100 new signups for the validation gate.

What I noticed about how you think

  • You distinguished mechanism from feature when you said "I don't want to build yet another drag-and-drop page builder so I am inclining towards having an AI powered solution." That's the right level of abstraction — most operators would have specced the feature first and worked backward.
  • You said "all of the above" twice when forced to pick a user. The CEO instinct is to serve everyone; the wedge instinct is to pick one. Worth noticing whether this happens elsewhere in the roadmap.
  • You caught the drag-and-drop tradeoff before I did: "at the end of the day we save HTML as a document anyway." That's the right insight — storage parity neutralizes the "two competing surfaces" objection. The conflict I flagged was real at the UX layer, not the data layer.
  • Your test was a customer (2barevents), not a sandbox. Most operators would have tested with fake content. Running the experiment on a real customer with real content is why you have a real signal to point at.