quorla-website/REQUIREMENTS.md

Quorla website: requirements

What to build for quorlasocial.com, the public marketing site for Quorla. Read this file and README.md before changing anything.

1. The product (what the site must explain)

Quorla is a social media management tool for marketing agencies that run many client accounts. A team uploads finished posts per client, plans the week, an admin approves the exact post, and Quorla publishes it on the right platform at the client's local time, then reports what worked.

• Made by: Metatroncube Software Solutions, Waterloo, Ontario, Canada.
• App: https://app.quorlasocial.com (sign-in only; this site links to it, it is a separate codebase).
• Contact: support@quorlasocial.com.
• Plans: hosted (we run it) and self-hosted (agency runs it on its own server). Prices are not decided yet.
• Access: by invitation for now. The main call to action is "Request access" (email or contact form).

What the product does today (OK to describe as available)

• Content library per client: designers and editors upload finished work; only approved items can be scheduled.
• Drafts → admin approval → publishing at the scheduled time, in the client's time zone. Nothing posts without approval.
• Platforms connected: Instagram, Facebook, YouTube, Google Business Profile, TikTok.
• Comments and DMs inbox (Instagram/Facebook) with replies drafted for a person to approve.
• AI-assisted monthly account audits, weekly content plans and weekly reports, exported as PDFs with the agency's branding.
• Team roles (admin, manager, designer, editor); admins add teammates and reset passwords.
• Respects each platform's limits (quotas) and waits instead of failing.

Being added (say "coming soon" or leave out; never present as available)

• LinkedIn, Pinterest, Threads and Reddit publishing (built, waiting for platform approvals).
• Published-posts page with per-post results, a visual content calendar, competitor tracking, client approval links.

2. Hard rules

1. Keep these URLs working at all times. Google's OAuth verification and TikTok's app review point at them:
   • / must explain what Quorla does and link to the Privacy Policy.
   • /privacy and /terms. Change wording only on purpose and keep them in sync with the app copies in the app repo (dashboard/server/legal/privacy.html, terms.html), update the "Effective" date when the text changes.
2. No made-up proof. No fake testimonials, client logos, reviews, user counts, star ratings or results. Leave a clearly marked placeholder until real ones exist.
3. No claims we can't back up ("#1", "AI that grows your followers 10×", guaranteed results).
4. Don't name or show real client accounts (white-label: clients must not be linked to the agency publicly). Use invented example businesses (like "Green Corner Café").
5. No platform logos in a way that suggests partnership (no "official partner" badges). Plain text names are fine.
6. Never put secrets, API keys or passwords in this repo.

3. Brand and writing

• Colours: navy #242142 (text, primary buttons), coral #FC6D45 (accents, highlights; don't use coral for body text on white, the contrast is too low). Light lavender #F6F5FB for alternate sections.
• Fonts: Plus Jakarta Sans (headings, 700/800), Inter (body). Already loaded in src/layouts/Base.astro.
• Logos in public/assets/ (logo.png for light backgrounds, logo-white.png for dark).
• Voice: like a sharp agency owner talking to another one. Short, specific, plain English. Lead with the outcome.
• Avoid: "Elevate", "Unlock", "Revolutionize", "Seamless", "In today's fast-paced world", emoji walls, buzzword lists.

4. Pages

URL	Purpose	Main content
/	Explain Quorla in 10 seconds, get access requests	Hero, how it works (connect → plan → approve → publish & report), feature highlights, platforms, approval/safety, CTA. Exists.
/features	Detail for evaluators	One section per feature from §1 with a screenshot or illustration each
/platforms	What each platform supports	Table: platform, post types, notes (e.g. TikTok: Direct Post after review, "finish in TikTok app" meanwhile)
/agencies	Why agencies pick Quorla	Many clients in one place, approvals, client time zones, team roles, white-label reports
/pricing	Hosted vs self-hosted	Two plan cards with "Contact us" until prices are set; FAQ (data ownership, setup, which platforms)
/security	Trust page for buyers and reviewers	Approval before publishing, encrypted tokens, platform sign-in (no passwords), data deletion, self-hosted option. State the hosting location only after confirming it
/contact	Request access / book a demo	Simple form (name, agency, email, number of clients, message) + email link. See §6 for how the form sends.
/blog + /blog/[slug]	SEO and updates	Markdown posts in src/content/blog/ using Astro content collections
/privacy, /terms	Legal	Exist. See rule 1
/404	Not found	Friendly page with links home and to the app

Navigation: Features · Platforms · Pricing · Blog · Sign in (button to the app) · Request access (primary button). Footer: product links, legal links, contact email, © Metatroncube Software Solutions.

5. Technical requirements

• Stack: Astro 7 static site (output: "static"). Plain CSS in src/styles/global.css (keep the existing tokens); add component CSS in .astro files with scoped <style>. No heavy UI framework unless a page truly needs it.
• Components: move repeated pieces into src/components/ (Header, Footer, CTA band, FeatureCard, PlanCard).
• Responsive: works from 360 px phones to wide desktops; no horizontal scroll; tap targets ≥ 44 px.
• Accessibility: semantic headings in order, alt text on every image, visible focus states, colour contrast AA, forms with labels and error messages.
• Performance: Lighthouse ≥ 90 on Performance, Accessibility, Best Practices and SEO. Images in WebP/AVIF via Astro's <Image>, lazy-loaded below the fold. No external scripts except Google Fonts (and analytics if added).
• SEO: unique <title> and meta description per page (pass them to Base.astro), canonical URLs (already in Base.astro), Open Graph image, sitemap.xml (@astrojs/sitemap), robots.txt, clean URLs.
• Analytics (optional): privacy-friendly only (e.g. Plausible or Umami). Update /privacy if added.
• No cookies banner needed as long as there are no tracking cookies.

6. Contact form

Built. /contact posts to public/api/contact.php (copied as-is into dist/api/). HestiaCP runs it with PHP and sends through the server's own mail (exim, DKIM-signed for quorlasocial.com) to support@quorlasocial.com, with the visitor's email as Reply-To. No passwords or API keys in code.

• Spam protection: honeypot field website_fax, minimum 3 s on the page (hidden field t), 5 requests per IP per hour, origin check (only quorlasocial.com / www).
• Fields: name, agency, email, clients, deployment, message. Don't add more without updating /privacy.
• If you change field names in contact.astro, change them in contact.php too.
• The PHP only runs on the server. npm run dev shows the form, but submitting locally fails; test it on the live site.

7. Done means

• npm run build passes with no errors and npm audit shows no high/critical issues.
• Every page in §4 exists, is linked from the nav or footer, and passes the rules in §2.
• Checked at 375 px, 768 px and 1440 px wide, in light conditions (the site has no dark mode; that's fine).
• Lighthouse targets from §5 met on / and one inner page.
• Deployed with the steps in README.md, and /, /privacy, /terms checked live afterwards.