Plan B — Code Review

Code Review, Architecture Analysis & PRD Assessment

9 March 2026 — NVISION Digital
1
Critical
4
High
10
Medium
7
Low
Critical
Critical
Production backdoor in Footer exports entire codebase
src/components/Footer.tsx — Lines 23-75

A hidden element labeled "NVISION" triggers handleDevExport on click. This function:

  • Fetches the complete list of project files from api-platform.sticklight.com using credentials: 'include'
  • Dynamically injects JSZip from an external CDN
  • Creates a ZIP archive of the entire codebase and downloads it

This is a Sticklight platform dev utility left in production code. The credentials: 'include' flag transmits authentication cookies to a third-party domain — a cross-site credential exposure risk.

Fix

Remove handleDevExport and the hidden NVISION button entirely. ✓ Fixed — removed in deployment commit.

High
High
React Rules of Hooks violation in NumberDecoder
src/components/NumberDecoder.tsx — Line ~18

The component calls useReducedMotion(), then conditionally returns JSX early, and only after that calls useEffect and useCallback. React requires all hooks to be called unconditionally in the same order on every render.

Fix

Move the reduced-motion guard inside the useEffect/animation logic, or restructure so all hooks run unconditionally.

High
Contact form is non-functional — data silently discarded
src/pages/ContactPage.tsx — handleSubmit

The form's handleSubmit calls setSent(true) and resets after 4 seconds. A comment reads: "In production, hook up to a real API". The form collects name, phone, email, company, and message — and silently discards all of it. Users see a success confirmation but their message is never delivered.

Fix

Connect to a real backend: Resend, SendGrid, Formspree, or a Cloudflare Worker that emails submissions.

High
NeuralCanvas isMobile computed at module scope — never updates
src/components/NeuralCanvas.tsx — Lines 29-31
const isMobile = typeof window !== 'undefined' && window.innerWidth < 768;
const NODE_COUNT = isMobile ? 30 : 60;
const CONN_DIST = isMobile ? 120 : 160;

These values are computed once at module evaluation time, not inside any React hook. They never update on resize or orientation change.

Fix

Compute inside a useState/useEffect + resize listener, or use a media query hook.

High
Inconsistent contact email across pages
Multiple files — office@plan-b.systems vs info@plan-b.co.il

Four legacy service pages use office@plan-b.systems via window.open(). All other contact surfaces (Footer, CTASection, ContactPage) use info@plan-b.co.il. Messages sent to the wrong address may be permanently lost.

Fix

Align all CTA links to one authoritative address. Replace window.open('mailto:...') with <a href="mailto:...">.

Medium
Medium
Duplicate SVG defs IDs break gradients on multiple instances
SVGBrainCircuit.tsx, SVGWaveform.tsx

Both components define SVG <defs> with hardcoded IDs. SVG id attributes must be document-unique. PlanBLogo.tsx already solves this with a per-instance uid via useRef.

Fix

Generate unique suffix per instance using useRef(() => Math.random().toString(36).slice(2)).

Medium
SVGWaveform permanent rAF loop — no reduced-motion guard
src/components/SVGWaveform.tsx

Runs an unbounded requestAnimationFrame loop with no prefers-reduced-motion check. Other components (NeuralCanvas, SVGOrbitSystem) respect this. The global MotionConfig only covers Framer Motion, not raw rAF loops.

Medium
ScrollProgress uses continuous rAF polling instead of passive scroll
src/components/ScrollProgress.tsx

Reads window.scrollY 60 times/second even when idle. A passive scroll event listener has zero cost at rest.

Medium
LiveStatus announces fake metrics via role=status
src/components/LiveStatus.tsx

Uses role="status" with randomly generated values presented as real-time AI system metrics. Screen readers announce meaningless numbers as genuine data. Violates WCAG 3.3.2.

Medium
Navbar mobile menu uses wrong ARIA roles
src/components/Navbar.tsx — Lines 100-115

Uses role="menu" and role="menuitem" — these are for application context menus, not site navigation. Requires arrow-key/Home/End/type-ahead keyboard behavior that isn't implemented.

Medium
Heebo font referenced but never loaded
src/theme.css, index.html

theme.css declares --font-sans: 'Heebo', 'Inter', system-ui but index.html has no font link. Typography silently falls back to system-ui on every platform.

Medium
Legacy pages bypass PageLayout — design divergence
6 pages: PrivacyCompliance, SIEMSolutions, AIIntegration, LLMExpertise, Architecture, Transformation

Six legacy pages use direct Navbar import, bg-slate-950 background, cyan/blue accents, and inline footers — completely different from the modern pages' design system.

Medium
No 404 / catch-all route
src/App.tsx

14 explicit routes, no <Route path="*"> fallback. Invalid URLs render a blank white page.

Medium
MatrixRain canvas doesn't update on resize
src/components/MatrixRain.tsx

Canvas dimensions set once at mount. No resize listener. Device rotation or browser resize leaves canvas clipped.

Medium
FeaturesDeep bar chart uses Math.random() in render
src/components/FeaturesDeep.tsx

Math.random() called inside whileInView produces different bar heights on every render/re-mount.

Low
Low
PageTransition component defined but never used
Dead code in production bundle

Fully implemented but not imported anywhere. PageLayout.tsx handles transitions directly.

Low
useCounter hook unused — logic duplicated inline
src/hooks/useCounter.ts

Defined but never imported. TrustBar.tsx and NumbersStrip.tsx duplicate the same counter animation logic.

Low
AnimatedText uses physical margin (mr-) — wrong in RTL
src/components/ui/AnimatedText.tsx

Uses mr-[0.3em] instead of logical me-[0.3em]. In RTL, margin-right adds space on the wrong side.

Low
Missing SEO meta tags — no OG, Twitter Card, or structured data
index.html

Only <title> and basic description. No Open Graph, Twitter Card, canonical link, or JSON-LD schema.

Low
LogoCloud marquee ignores prefers-reduced-motion
src/components/LogoCloud.tsx

TrustBar respects reduced motion; LogoCloud (near-identical marquee) hardcodes repeat: Infinity.

Low
Legacy pages use left-8 instead of start-8 — wrong in RTL
4 legacy service pages

Decorative background numbers positioned with physical left-8 instead of logical start-8.

Low
Duplicate data-ev-id values — analytics misattribution
src/pages/Index.tsx

Same tracking ID ev_050b10447f on two different elements. Sticklight analytics events will be misattributed.

Current Stack Assessment

The Plan B website was built on Sticklight (a Lovable-like AI code generation platform) using React 18 + Vite 6 + Tailwind CSS v4 + Framer Motion. The demo impressed the client, but the production code has structural problems.

What Was Shipped
MetricValueAssessment
JS Bundle614 KBToo large — 10x what's needed for static pages
Components60+Many duplicates (4 service components doing the same thing)
Issues Found22Including 1 critical security backdoor
SSR/SSGNoneClient-side only — blank page until 614KB JS loads
Code SplittingNoneAll 14 pages bundled together
Contact FormFakeSilently discards submissions
Design SystemsTwo6 legacy pages on completely different visual system
Build ConfigMissingNo package.json, tsconfig, or vite.config shipped

Why Sticklight Is Wrong for Production

Sticklight is good for demos — which is exactly how it was used. But the output is:

  • JSON-wrapped source files — all 76 files were wrapped in {"path":"...","content":"..."} JSON, not actual source code
  • No build configuration — package.json, vite.config.ts, tsconfig.json all missing
  • Platform artifacts left in productiondata-ev-id tracking attributes on every element, Sticklight API backdoor in Footer
  • Over-generated — 60+ components with significant duplication (ServicesList, ServicesShowcase, ServicesSection, ServicePuzzleGrid)

If Built From Scratch

Recommended Stack: Astro + React Islands
AspectCurrent (Sticklight)Recommended (Astro)
Components60+ generated~15 intentional
Bundle per page614KB everywhere0-50KB (JS only where needed)
SEOClient-side, Google sees blankPre-rendered HTML, fully indexable
Content editingEdit TSX filesEdit Markdown/MDX files
Contact formFakeWorking from day 1
Time to first paint~2-3 seconds~0.3 seconds
Footer changeTouch 6+ filesTouch 1 file

Astro ships zero JavaScript by default. The animated hero and contact form become React "islands" — only those components load JS. Static pages (services, about, privacy) are pure HTML/CSS with zero runtime cost.

What to Keep

  • Framer Motion animations — they work well for an AI/tech company
  • NeuralCanvas background — says "AI company" immediately
  • Text scramble effects — adds tech personality
  • Dark theme with violet accent — premium feel
  • RTL Hebrew layout — correct for the market

What to Drop

  • 3 simultaneous rAF loops running continuously — battery drain
  • Fake "live metrics" dashboard — looks dishonest for a tech company
  • 4 duplicate service components — consolidate into one
  • All Sticklight tracking attributes — platform noise

Bottom Line

The demo served its purpose — the client said yes. Now the site needs to be rebuilt properly for production. The current React SPA approach is the wrong architecture for a marketing site, but adding lazy loading and fixing the 22 issues would make it acceptable. For the v2.0 SaaS platform (see PRD analysis), the architecture needs to be fundamentally different.

PRD v2.0 Analysis — Plan-b.systems Platform

The PRD describes a completely different product from the current demo site. It's no longer a brochure — it's a full SaaS platform with multi-tenant customer portal, license management, billing, and AI agents.

Overall Assessment

The PRD is surprisingly well-architected for a non-developer-written document. The multi-tenant RLS approach, licensing handshake, and API versioning are industry-standard patterns done right. But there are gaps and risks.

What the PRD Gets Right

1. Multi-Tenant Architecture — Excellent

Shared database with RLS is exactly the right call. Per-tenant databases are a maintenance nightmare. The schema design (Organizations → Profiles → Licenses) is clean. The RLS policy example is correct:

CREATE POLICY tenant_isolation_policy ON licenses
USING (org_id = auth.jwt() ->> 'org_id');

This means even if the frontend code has bugs, the database itself blocks cross-tenant data access. This is the Supabase/AWS standard approach.

2. Licensing Handshake — Smart Design

The SIEM validation flow (POST to /v1/validate with license_key + machine_id → signed JWT valid for 24h) is well-designed. The 72-hour offline grace period is a good practical decision — it prevents customer disruption from temporary network issues while still enforcing license compliance.

3. API Versioning — Forward-Thinking

All licensing API under /v1/ from day one. This means v2 can coexist without breaking deployed SIEM systems. The specific error codes (ERR_EXPIRED, ERR_QUOTA_EXCEEDED) are also correct — much better than generic 401/403.

4. "No Direct DB Access" Rule

The PRD explicitly states the frontend never touches the DB directly (only through Supabase Client with RLS). This is the right security posture for a multi-tenant platform.

What's Missing or Risky

1. The Site Is Doing Too Many Things

The PRD mixes three different products into one:

  • Marketing site — "showcase window", presale demo, premium animations
  • Customer portal — multi-tenant dashboard, license management, billing
  • API service — SIEM validation endpoint, usage tracking

These should be separate deployments:

WhatTechURL
Marketing siteAstro (static)plan-b.systems
Customer portalNext.js (SSR)app.plan-b.systems
APIEdge Functionsapi.plan-b.systems

Mixing a marketing site with a SaaS dashboard in the same app creates conflicting performance requirements. The marketing site needs to be fast and SEO-friendly. The dashboard needs real-time data and authenticated routes.

2. Framework Choice — Next.js, Not Astro

The PRD suggests "Astro 5.0 or Next.js". For the marketing site, Astro is better. For the SaaS portal, Next.js is the clear winner:

  • Server Components for dashboard data loading
  • API Routes for the licensing endpoints
  • Middleware for tenant-aware auth
  • TanStack Query integration (mentioned in PRD) works naturally

Astro is wrong for the portal — it's designed for content sites, not authenticated multi-tenant dashboards.

3. AI Agent Security — Underspecified

The PRD says the bot should perform "Function Calling" like "generate a new license key". This is extremely dangerous without guardrails:

  • Who authorizes the bot to create licenses? Only Admin role, or any user?
  • What's the rate limit? Can someone spam "create 1000 licenses"?
  • How do you audit bot-initiated actions? Is there a separate audit log?
  • The PRD mentions injecting user context into the prompt — this must use system prompts, not user-controllable content, or it's vulnerable to prompt injection.
4. "The Website Is the Presentation" — Conflicting with SaaS

The PRD says: "When I'm at a client, I don't need presentations, the site IS the presentation." This means the marketing site needs to be spectacular — heavy animations, Three.js, premium feel. But the customer portal needs to be functional — fast, clear, data-dense.

These are opposing requirements. The marketing site should wow; the portal should work. Trying to make the portal "impressive" usually makes it slow and confusing. Separate the two.

5. Billing — Smart to Mark as Optional

The PRD correctly marks usage-based billing as uncertain. For an early-stage SaaS, start with fixed-tier pricing (Basic/Pro/Enterprise already defined in the schema). Add usage-based billing later when you have enough customers to justify the engineering cost. Stripe metered billing works but adds significant complexity in tracking, threshold alerts, and edge cases (what happens when a customer disputes usage data?).

6. Missing: Deployment & DevOps

The PRD mentions Vercel hosting but doesn't address:

  • CI/CD pipeline — how do changes get deployed?
  • Staging environment — essential for a multi-tenant system (can't test RLS in production)
  • Monitoring — how do you know when the licensing API is down?
  • Backup strategy — Supabase handles DB, but what about the license keys?
  • Rate limiting — the /v1/validate endpoint will be hammered by SIEM systems every 24h
7. Missing: Content Updates

The current site says "cybersecurity/SIEM" but Plan B does AI integration, bots, agents, Claude Code courses, Monday automation, enterprise integration. The PRD doesn't address the content gap — whoever builds v2 needs a content brief, not just a tech spec.

Recommended Architecture for v2.0

LayerTechnologyWhy
Marketing siteAstro 5 + React islandsFast, SEO-friendly, animations where needed
Customer portalNext.js 15 (App Router)SSR, auth middleware, API routes, real-time dashboard
DatabaseSupabase (PostgreSQL + RLS)As specified — correct choice
AuthClerk (with Organizations)Multi-tenant auth out of the box, better than Supabase Auth for this use case
APINext.js API Routes + EdgeLicense validation needs low latency globally
AI AgentClaude API + pgvector RAGFunction calling with strict role-based authorization
BillingStripe (fixed tiers first)Start simple, add metered billing in v2.1
HostingVercel (portal) + CF Pages (marketing)Best-in-class for each use case

Verdict on the PRD

This is a solid foundation written by someone who understands enterprise software. The multi-tenant architecture, licensing handshake, and API design are correct. The main risk is scope — this is 3 products (marketing site + SaaS portal + API service) described as one. Separate them architecturally, start with the marketing site + licensing API, and add the customer portal as phase 2.

The biggest gap: the AI agent needs a security design document before implementation. Function calling that creates licenses and sends invoices requires explicit authorization flows, audit logging, and rate limiting — none of which are specified.

PRD v2.0 — Plan-b.systems Platform

מסמך דרישות מוצר (PRD) - Plan-b.systems Platform v2.0

חזון המוצר

הקמת פלטפורמת SaaS מרכזית עבור Plan-b.systems שתשמש כחלון הראווה של החברה, מרכז ניהול לקוחות מרובי דיירים (Multi-tenant), ומנגנון הנפקת רישיונות עבור מערכות ה-SIEM וה-AI של החברה.

קהל יעד

  • לקוחות פוטנציאליים: חשיפה לשירותי ה-IT וה-AI של החברה בממשק פרימיום.
  • לקוחות קיימים: ניהול רישיונות, צפייה בבילינג ותקשורת עם ה-AI Agent.
  • דמו חיי במשימת PRESALE: כשאני אצל לקוח, לא צריך מצגות, האתר הוא המצגת.

3. ארכיטקטורה טכנולוגית (Technical Stack)

הערה למפתח: סעיפים 3.1 ו-3.2 נתונים לשיקול דעתך המקצועי, בתנאי שיעמדו בדרישות הביצועים וה-UX המפורטות.

3.1 שלד האפליקציה (Frontend Framework)

אפשרויות מומלצות: Astro 5.0 או Next.js.

דרישת סף: תמיכה מלאה ב-Server Side Rendering וביצועי Lighthouse (Performance) מעל לציון 90.

3.2 עיצוב וממשק משתמש (Styling and UI)

אפשרויות מומלצות: Tailwind CSS בשילוב Shadcn UI או ספריה דומה.

דרישת סף: מימוש שפת עיצוב פרימיום (Dark Mode, Glassmorphism), תמיכה ב-RTL מלא ואנימציות חלקות.

3.3 בסיס נתונים וצד שרת (Backend and Database)

בסיס נתונים: Supabase (PostgreSQL).

אבטחה: חובת שימוש ב-Row Level Security (RLS) למניעת זליגת מידע בין לקוחות שונים.

3.4 תשתיות נוספות

אירוח (Hosting): Vercel. (אופציה!)

אימות משתמשים: Supabase Auth או Clerk.

4. דרישות פונקציונליות מרכזיות

4.1 פורטל לקוחות מרובי דיירים (Multi-Tenant Portal)

בידוד נתונים: ארכיטקטורה קשיחה שבה לקוח רואה אך ורק את הישויות (מפתחות, חשבוניות, לוגים) המשויכות לארגון שלו בלבד.

ניהול הרשאות: הפרדה בין מנהל לקוח (Admin) לבין משתמש קצה בארגון. אפשרות לתת גישה לקריאה בלבד ולתת גישה לבודקים שונים מטעם הלקוח.

4.2 ניהול רישוי וממשק SIEM

ניהול רישיונות: הנפקת מפתחות API וניהול תוקף המנוי.

ממשק אימות (Validation Endpoint): חשיפת API מאובטח שישמש את מערכת ה-SIEM החיצונית לאימות הרישוי בזמן אמת.

4.3 מנגנון גבייה (Billing Engine)

תשלומים מתחדשים: חיוב חודשי מתחדש מבוסס שימוש או מנוי קבוע.

אינטגרציה: חיבור לספק תשלומים (כגון Stripe או ספק מקומי) דרך Webhooks. (נושא פתוח לדיון, גם ספק סליקה כגון טרנזילה יכול לעבוד.)

4.4 דשבורד מבוסס AI

צ'אט חכם: שילוב בוט AI המחובר לנתוני הלקוח ומאפשר שאילתות על סטטוס הרישוי, השירותים וניתוח נתונים בסיסי. תשובות הבוט רק על המידע של אותו לקוח (מולטי טננט AI).

5. דרישות חווית משתמש (UX/UI)

תנועה וגרפיקה: האתר חייב לכלול אלמנטים גרפיים מודרניים המשרים תחושת הייטק יוקרתית.

תגובתיות: פידבק ויזואלי מהיר לכל פעולת משתמש (לחיצה, טעינה, הצלחת פעולה).

1. ארכיטקטורת Multi-Tenancy ובידוד נתונים

אנחנו לא נפתח בסיס נתונים נפרד לכל לקוח (יקר ומסובך לתחזוקה), אלא נשתמש ב-Shared Database, Separate Schema/Row Isolation.

א. מבנה הטבלאות (Schema)

Table: Organizations (Tenants)

  • id (UUID, Primary Key)
  • name, subscription_plan (Basic, Pro, Enterprise)
  • status (Active, Suspended, Trial)

Table: Profiles (Users)

  • id (References Auth.Users)
  • org_id (References Organizations.id)
  • role (Owner, Admin, Viewer)

Table: Licenses (The SIEM Keys)

  • id, org_id, license_key (Hashed)
  • allowed_log_volume (GB/Month)
  • expiration_date, is_active
ב. מנגנון האבטחה (RLS - Row Level Security)

המתכנת חייב להגדיר ב-Postgres מדיניות שאומרת:

CREATE POLICY tenant_isolation_policy ON licenses
USING (org_id = auth.jwt() ->> 'org_id');

זה מבטיח שגם אם יש באג בקוד ה-Frontend, ה-DB עצמו יחסום ניסיון של משתמש לראות רישיון שלא שייך ל-org_id שלו.

2. מנגנון הרישוי והאימות (Licensing Handshake)

כאן אנחנו מגדירים איך ה-SIEM (שמותקן אצל הלקוח או בענן) מוודא שהוא רשאי לעבוד.

זרימת האימות (Authentication Flow)
  • Handshake: ה-SIEM שולח בקשת POST לכתובת api.plan-b.systems/v1/validate.
  • Payload: הבקשה מכילה license_key ו-machine_id.
  • Validation: השרת (Vercel Edge Function) בודק את ה-Key ב-DB. בדיקת תוקף (Expiration) וסטטוס תשלום (Subscription Active). בדיקת מכסה (Quota) - האם הלקוח חרג מנפח הלוגים המותר?
  • Response: השרת מחזיר JSON חתום (JWT) שמכיל את ההרשאות ל-24 השעות הקרובות.
מנגנון רישוי ל-SIEM (פירוט נוסף)

המנגנון יתבסס על Asymmetric Key Validation או Signed JWTs.

  • האתר מנפיק רישיון חתום (JWT) שמכיל: tenant_id, expiration_date, ו-allowed_capabilities.
  • ה-SIEM שומר את הרישיון לוקאלית.
  • בכל הפעלה, ה-SIEM מבצע "Handshake" מול האתר ב-Endpoint מאובטח.
  • בדיקת תוקף (Check-in): ה-SIEM חייב לבצע Check-in פעם ב-24 שעות. אם ה-API מחזיר 403 Forbidden (בשל אי-תשלום או ביטול ידני), ה-SIEM מכבה את שירותי האיסוף.
  • אופליין: ניתן להגדיר Grace Period (למשל 72 שעות ללא תקשורת) לפני השבתה, כדי למנוע תקלות בגלל ניתוקי רשת זמניים.

3. ניהול בילינג (Billing Engine) — אופציונלי

לא בטוח שנלך על זה.

במערכת SIEM, המחיר בדרך כלל נגזר מנפח דאטה.

הפתרון: Stripe Metered Billing
  • Data Ingestion Tracking: ה-SIEM מדווח פעם ביום על נפח הלוגים שנסרקו (ingested_bytes).
  • Stripe: האתר דוחף את הנתון ל-Stripe דרך ה-API שלהם.
  • Thresholds: אם הלקוח מגיע ל-90% מהמכסה, המערכת שולחת התראה אוטומטית דרך ה-Dashboard ומוסיפה שורת חיוב.

ניתן לביצוע? כן. הוכח במערכות כמו Datadog ו-Sentry.

4. ארכיטקטורת ה-AI Agent (RAG Implementation)

הבוט צריך להיות Context-Aware:

המימוש המוכח
  • Vector DB: שימוש ב-Supabase Vector (pgvector) לאחסון מסמכי התמיכה הטכנית של Plan-b.
  • User Context: בכל פנייה ל-LLM, המערכת "מזריקה" את נתוני הלקוח: "אתה עוזר ללקוח X, יש לו 3 רישיונות פעילים, האחרון פג בעוד יומיים".
  • Actions: הבוט יוכל לבצע פעולות (Function Calling), כמו "תנפיק לי מפתח רישיון חדש" או "תשלח לי למייל את החשבונית האחרונה".

מגבלה: הבוט לא "לומד" לבד בזמן אמת, הוא משתמש רק במידע שסיפקנו לו ב-Prompt.

5. דרישות ה-Premium Frontend (HLD)

דרישות ביצועים וחוויה
  • State Management: שימוש ב-TanStack Query (React Query) לסנכרון נתונים בזמן אמת בדשבורד.
  • Visuals: שילוב של Three.js או Rive לאנימציות אינטראקטיביות של "Data Flow" בעמוד הבית.
  • Skeleton Loading: כל האתר צריך להיטען עם "שלדים" (Skeletons) כדי למנוע קפיצות בתוכן (Layout Shift) ולתת תחושה מהירה ויוקרתית.

סיכום דגשים למתכנת (Checklist)

  • No Direct DB Access: ה-Frontend לעולם לא פונה ל-DB ישירות (חוץ מאשר דרך Supabase Client עם RLS).
  • API Versioning: כל ה-API של הרישוי חייב להיות תחת /v1/ כדי שלא נשבור מערכות ישנות כשנעדכן גרסה.
  • Error Handling: כל שגיאת רישוי חייבת להחזיר קוד שגיאה ספציפי (למשל ERR_EXPIRED, ERR_QUOTA_EXCEEDED) ולא סתם "Unauthorized".
  • Auth: הטמעת Clerk או Supabase Auth עם תמיכה ב-Organizations.
  • DB: הגדרת RLS Policies לכל הטבלאות.
  • API: יצירת Endpoints בגרסה v1 עבור ה-SIEM.
  • Webhooks: מימוש Listener ל-Stripe כדי לעדכן סטטוס רישיון ב-DB ברגע שחיוב נכשל.
סיכום אסטרטגי — מה עושים עם Plan B?

השורה התחתונה

האתר הנוכחי יכול לשרת כאתר שיווקי זמני — אחרי תיקון 22 הבאגים. אבל הוא לא יכול להיות הבסיס לפלטפורמת SaaS כפי שה-PRD מתאר. אלה שני מוצרים שונים לחלוטין.

מה ה-PRD באמת אומר?

הבעלים רוצה שלושה דברים במקביל:

1. אתר שיווקי מרשים ("האתר הוא המצגת")

אתר עם אנימציות פרימיום, Three.js, תחושת הייטק — שאפשר לפתוח אצל לקוח במקום מצגת PowerPoint. זה מה שיש היום (בערך), ועם תיקונים זה יכול לעבוד.

2. פורטל לקוחות (Multi-Tenant SaaS)

מערכת שבה כל לקוח נכנס לאזור שלו, רואה את הרישיונות שלו, מנהל את המנויים שלו, מדבר עם בוט AI שמכיר אותו. זה לא אתר — זה מוצר תוכנה.

3. שירות API לאימות רישיונות SIEM

Endpoint שמערכות ה-SIEM של הלקוחות פונות אליו כל 24 שעות כדי לוודא שהרישיון עדיין תקף. זה שירות Backend טהור — אין לו שום קשר לעיצוב האתר.

האם אפשר לעבוד עם האתר הנוכחי?

שאלהתשובה
האם האתר הנוכחי יכול לשמש כאתר שיווקי?כן — אחרי תיקון הבאגים, הסרת הBackdoor (כבר נעשה), חיבור טופס יצירת קשר אמיתי, ותיקוני SEO.
האם האתר הנוכחי יכול לשמש כפורטל לקוחות?לא — אין בו שום תשתית ל-Auth, Multi-tenant, DB, או API. זה אתר סטטי עם אנימציות.
האם צריך לזרוק הכל ולבנות מחדש?לא בהכרח — אפשר להשאיר את האתר השיווקי ולבנות את הפורטל בנפרד.

ההצעה שלי: שלוש שכבות נפרדות

שלב 1 — עכשיו (1-2 שבועות)

תיקון האתר הנוכחי — הוא ישמש כאתר שיווקי זמני:

  • תיקון 22 הבאגים שנמצאו (הBackdoor כבר הוסר)
  • חיבור טופס יצירת קשר אמיתי (Formspree/Resend)
  • הוספת SEO meta tags
  • איחוד כתובת האימייל
  • הוספת route 404

תוצאה: אתר שיווקי עובד שאפשר להראות ללקוחות.

שלב 2 — במקביל (4-6 שבועות)

בניית אתר שיווקי חדש ב-Astro — יחליף את האתר הנוכחי:

  • אותו עיצוב פרימיום, אנימציות, NeuralCanvas
  • ביצועים: 0.3 שניות במקום 2-3 שניות
  • SEO מלא — Google רואה HTML אמיתי, לא דף ריק
  • תוכן מעודכן — לא רק SIEM אלא גם AI, בוטים, Claude Code, Monday
  • Bundle: ~30KB במקום 614KB

זה מתיישב לגמרי עם ה-PRD — ה-PRD אומר "Astro 5.0 או Next.js" וזה בדיוק מה שמוצע.

שלב 3 — אחרי שהשיווקי מוכן (8-12 שבועות)

בניית פורטל לקוחות ב-Next.js על app.plan-b.systems:

  • Multi-tenant עם Supabase RLS (כמו שה-PRD מתאר)
  • Clerk Auth עם Organizations
  • ניהול רישיונות + API endpoint לאימות SIEM
  • בוט AI עם Claude + pgvector (עם מסמך אבטחה נפרד!)
  • Billing: להתחיל עם תוכניות קבועות, לא usage-based

האם ההצעה שלי מתיישבת עם חזון הבעלים?

כן — עם הבחנה חשובה

ה-PRD הוא מסמך מצוין. הארכיטקטורה (Multi-tenant, RLS, Licensing Handshake) — הכל נכון. מה שצריך לשנות זה לא את מה לבנות, אלא את איך לבנות:

  • לא לערבב שיווק ו-SaaS באותו פרויקט — זה הטעות היחידה ב-PRD. אתר שיווקי פרימיום ודשבורד לקוחות הם מוצרים שונים עם דרישות סותרות (יפה vs. מהיר, SEO vs. Auth).
  • לא לבנות הכל בבת אחת — להתחיל עם שיווקי + API רישוי. הפורטל הוא Phase 2.
  • הבילינג יכול לחכות — הבעלים עצמו כתב "לא בטוח שנלך על זה". נכון. להתחיל עם תוכניות קבועות.
  • בוט AI צריך מסמך אבטחה נפרד — Function Calling שמנפיק רישיונות ושולח חשבוניות הוא סיכון חמור. צריך להגדיר בדיוק מי מורשה לעשות מה.

מה חסר ב-PRD?

  • DevOps: אין CI/CD, אין Staging, אין Monitoring. בפלטפורמה Multi-tenant זה חובה.
  • תוכן: האתר הנוכחי מדבר רק על SIEM, אבל Plan B עושה הרבה יותר. צריך Content Brief.
  • אבטחת AI Agent: מי מורשה לתת לבוט ליצור רישיונות? מה ה-Rate Limit? איפה ה-Audit Log?
  • Rate Limiting ל-API: מערכות SIEM ידפקו את ה-/v1/validate כל 24 שעות. ב-100 לקוחות זה 100 בקשות ביום. ב-10,000 לקוחות — צריך CDN/Edge.
  • Backup ו-DR: מה קורה אם Supabase נופל? הרישיונות של הלקוחות צריכים להמשיך לעבוד (ה-Grace Period של 72 שעות עוזר, אבל צריך תוכנית).

סיכום: שלוש אפשרויות

אפשרותמה זה אומרהמלצה
א. להישאר עם מה שישלתקן 22 באגים, לחבר טופס, להוסיף SEOטוב לטווח קצר (1-2 חודשים). לא פתרון קבוע.
ב. Astro + Next.js (ההצעה שלי)אתר שיווקי חדש + פורטל לקוחות נפרדהמלצה. מתיישב עם ה-PRD ומפריד נכון בין שיווק ל-SaaS.
ג. ללכת לפי ה-PRD כמות שהואלבנות הכל כפרויקט אחדמסוכן. ניסיון לשים שיווק + SaaS + API באותו פרויקט ייצור מפלצת.

הפסק הסופי

ה-PRD הוא בסיס מצוין. הקונספט נכון — Plan B צריך יותר מאתר שיווקי. הוא צריך פורטל לקוחות, ניהול רישיונות, ובוט AI. אבל צריך לבנות את זה כשלושה מוצרים נפרדים, לא כפרויקט אחד מונוליטי.

התוכנית המומלצת: עכשיו — לתקן את האתר הנוכחי כך שיעבוד. במקביל — להתחיל לבנות אתר שיווקי ב-Astro. אחר כך — פורטל לקוחות ב-Next.js. ה-PRD מנחה את הכיוון, אנחנו רק מפרידים את הביצוע לשלבים הגיוניים.