Press Parrot

A modern SaaS-style link building marketplace where SEO agencies, brands and marketers browse vetted websites and buy guest posts, niche edits and digital PR placements.

Live domain: pressparrot.com (not yet connected - see Next steps).

Built with Next.js (App Router), TypeScript and Tailwind CSS. The whole application runs locally on mock data with no external accounts required.

---

Quick start

npm install
cp .env.example .env.local   # optional - defaults work as-is
npm run dev

Open http://localhost:3000.

Command	What it does
npm run dev	Start the dev server
npm run build	Production build (also type checks)
npm run start	Serve the production build
npm run lint	ESLint
npm run typecheck	tsc --noEmit

Main URLs

URL	Access	Page
/	Public	Homepage - the main SEO and conversion landing page
/link-building	Public	Link building service page
/guest-posts	Public	Guest posts service page
/niche-edits	Public	Niche edits service page
/content-writing	Public	Content writing service page, with pricing
/digital-pr	Public	Digital PR service page
/link-building-agencies	Public	For SEO agencies
/marketplace	Both	Gateway when signed out, the marketplace when signed in
/how-it-works	Public	Product explainer and vetting criteria
/pricing	Public	Plans and typical placement prices
/resources	Public	Guides, benchmarks and contact
/login, /signup	Public	Authentication screens
/websites	Account	Redirects to /marketplace
/websites/[slug]	Account	Website listing detail and order builder
/dashboard	Account	Customer dashboard
/dashboard/content	Account	Content orders
/dashboard/content/new	Account	Content brief and basket
/dashboard/content/[id]	Account	Content order detail, messages and revisions
/dashboard/orders	Account	Placement orders and current draft
/dashboard/saved	Account	Saved websites
/dashboard/billing	Account	Invoices and plan
/dashboard/account	Account	Profile and session controls
/admin/login	Public	Admin sign-in
/admin	Admin	Admin dashboard
/admin/websites	Admin	Website database with row actions
/admin/websites/new	Admin	Website editor (create)
/admin/websites/[id]	Admin	Website editor (edit)
/admin/websites/import	Admin	Bulk CSV import
/admin/orders	Admin	Placement order management
/admin/content-orders	Admin	Content order queue
/admin/content-orders/[id]	Admin	Assign writer, change status, deliver content
/admin/users	Admin	Accounts
/admin/categories	Admin	Niches
/admin/settings	Admin	Brand, marketplace defaults and content pricing
/sitemap.xml, /robots.txt	Public	Generated by src/app/sitemap.ts and robots.ts

Editing content

Copy, links and images on the public pages are editable from the admin. The model is content, not layout: a page declares the fields an editor may change, and the design around them stays as built.

• /admin/pages lists what can be edited; /admin/pages/[slug] edits it.
• Defaults live in src/lib/cms/pages/ as the shipped copy. A page always renders correctly against an empty database, and any field can be reset back to the original - individually or for the whole page.
• Saved values are overrides layered on the defaults. An override is ignored when its shape does not match the declared field, so adding or changing a field cannot break a live page.
• Long copy is markdown, rendered by src/lib/cms/markdown.tsx. That renderer produces React nodes rather than an HTML string, so no dangerouslySetInnerHTML sits in the path and markup cannot be injected through content.
• Saving rebuilds the value tree field by field against the schema. Keys the client invented are dropped, and link fields accept only internal paths or http/https/mailto/tel - a CTA cannot become a javascript: URL.

Editable today: the homepage and the five service pages. To add another, write a module under src/lib/cms/pages/ and register it in src/lib/cms/registry.ts.

Blog

Posts live at /resources, with category filtering and individual pages at /resources/[slug].

• /admin/blog lists every post including drafts; create, edit and delete from there.
• Three statuses: Draft (admin only), Scheduled (goes live on its date, with no deploy needed) and Published. Drafts and future-dated posts are filtered at the service boundary, so they cannot leak through a page that forgot a filter, and they never appear in the sitemap.
• Markdown with a live preview that uses the same renderer as the public page.
• Cover images are referenced by path today. Put files in public/images/posts/; direct upload arrives with Supabase storage.

Marketplace access

The publisher inventory is a benefit of holding an account, not public content.

• proxy.ts gates /websites, /websites/:path* and /dashboard/:path* before a page renders, and each page re-checks with requireCustomerSession() because server actions have their own endpoints.
• /marketplace is deliberately public: signed out it renders a gateway that explains the marketplace and sells the signup; signed in it renders the marketplace itself.
• The signed-out preview is redacted in the service layer, not with CSS. websiteService.getPublicPreview() returns rows through src/lib/services/marketplace-preview.ts, which drops the domain, slug and id and bands the metrics. A public page has no way to obtain a real domain, so nothing leaks into the HTML, the RSC payload or the structured data.
• Listing pages carry robots: noindex and are rendered per request rather than pre-rendered, and the sitemap contains no listing URLs.

Sessions are signed HMAC cookies (pp_session), the same construction as the admin session. Set AUTH_SESSION_SECRET in production; it falls back to ADMIN_SESSION_SECRET, and outside production to a fixed development value. In production with neither set, sign-in fails closed with a clear message.

Content ordering

Customers can order content on its own, with no placement attached.

• Public page: /content-writing.
• Ordering: /dashboard/content/new - brief an article, Add to Order, brief the next, then place the whole order. Quantities are supported, so "3 x 1,000 words" is one line.
• Tracking: /dashboard/content and /dashboard/content/[id], with the original brief, messages, deliveries and revision requests.
• Admin: /admin/content-orders - assign a writer, change status, set a price, add internal notes, deliver a draft or final article.
• Pricing is configured in /admin/settings (fixed per length, per word, or both). It ships empty: until a price is set, the public page and the order form show "on request" rather than a number or a zero.

Statuses: Brief Received, Writing, Editing, Ready for Review, Revision Requested, Complete.

Project structure

src/
  app/
    (marketing)/        Public site: home, marketplace, listings, content pages
    (auth)/             Login and signup, split-screen layout
    dashboard/          Customer area
    admin/              Internal admin area: login/ plus the (protected) group
    robots.ts, sitemap.ts, icon.svg
  proxy.ts              Gates every /admin route (Next 16's middleware)
  components/
    ui/                 Primitives: button, input, select, table, sheet, ...
    layout/             Header, footer, logo, container, page hero
    marketplace/        Filters, table, cards, pagination, toolbar
    website/            Listing detail sections and the order card
    home/               Homepage sections: hero, marketplace preview, trust
                        metrics, trusted by, feature strip, how it works,
                        niche grid, final CTA
    dashboard/          Dashboard shell, widgets and the order editor
    support/            Always-on live chat launcher
    shared/             Badges, metrics, FAQ, foliage, handwritten notes
    admin/              Admin tables and website editor
    admin/import/       CSV import wizard components
    shared/             Badges, metrics, FAQ
  lib/
    config/             brand.ts (single source of brand truth), navigation.ts,
                        support.ts (live chat), marketing.ts (headline stats),
                        social-proof.ts (logos and testimonials),
                        how-it-works.ts (the four steps)
    types/              Website, Category, Country, User, Order, Settings, ...
    data/               Mock seed data (72 websites, orders, users, categories)
    services/           Repository layer - the only place data is fetched
    auth/               Admin session signing and access checks
    import/             CSV parsing, field mapping, normalisation, validation
    hooks/              Marketplace filter state, localStorage
    providers/          Auth, favourites and order draft contexts
    utils/              Formatting, labels, class merging
supabase/
  migrations/           Proposed SQL schema (not required to run the app)
  README.md             How to create the project and apply the schema

Brand

Everything brand-specific lives in src/lib/config/brand.ts: name, domain, tagline, logo paths, favicon, colours, support and sales email, company registration details, social links, currency, locale and the browser-storage namespace. No component hardcodes the brand name, so a rename is a one-file change.

Identity. Dark navy and off-white carry the interface; parrot green is the accent; coral is the secondary, used sparingly (the beak in the mark, the "Most popular" pricing badge). The personality lives in the brand layer - the mark, the odd line of copy - while product surfaces stay literal and calm. Saved websites are "Saved websites", not "the perch".

Colour tokens are also declared in src/app/globals.css under @theme so Tailwind can generate utilities from them. If you change a brand colour, update both places. The parrot mark is drawn inline in src/components/layout/logo.tsx (exported as ParrotMark) and duplicated as src/app/icon.svg for the favicon; swap both for an <Image> when a bespoke asset exists.

Placeholders to fill in before launch: company registration number, VAT number, trading address and phone are empty in the config and are hidden from the footer while blank. The X and LinkedIn URLs assume the pressparrot handle on each.

Admin access

/admin is gated server-side, not in the browser:

1. src/proxy.ts runs before any admin route renders and redirects anyone without a valid session cookie to /admin/login. (Next.js 16 renamed the middleware convention to proxy; behaviour is unchanged.)
2. Every admin server action calls requireAdminSession(), because server actions have their own endpoints and are reachable without rendering a page.

Sign-in checks the address against an allowlist and the password against a shared secret, then sets an HMAC-signed, httpOnly cookie scoped to /admin that lasts 12 hours. Both checks failing produce the same message, so the form cannot be used to discover who the admins are.

Three server-only environment variables are required:

Variable	Purpose
ADMIN_EMAILS	Comma separated addresses allowed to sign in
ADMIN_PASSWORD	Shared password for the sign-in form
ADMIN_SESSION_SECRET	Signs the session cookie (openssl rand -base64 32)

Never prefix these with NEXT_PUBLIC_, which would ship them to the browser. If any is missing the admin area locks itself rather than opening up, so a misconfigured deployment fails closed.

Removing an address from ADMIN_EMAILS revokes access on that person's next request, without waiting for their session to expire. Changing ADMIN_SESSION_SECRET signs everyone out immediately.

This is a stopgap. A shared password is not per-person identity: it cannot be rotated for one individual, and it leaves no audit trail of who changed what. When Supabase Auth is connected, give each admin their own credentials and keep ADMIN_EMAILS as the profiles.role check.

Ordering flow

Browsing and buying are deliberately separate:

1. Marketplace - every row and card has an Add button next to View, which drops the headline service into the order with the details blank. The button then reads "In order" so a website cannot be added twice.
2. Listing page - pick which service you want, then add. No placement details are collected here.
3. Order page (/dashboard/orders) - the only place details are entered: target URL (required), anchor text, preferred landing page, notes for the publisher, and an optional article attachment. Edits save to the draft as you type and survive a reload. Switching service reprices that line.

The article attachment records the file's name and size only. The upload itself needs storage, so wire it to Supabase Storage when the backend lands.

Brand artwork

Two drop-in slots, both resolved at build time so a missing file falls back to a drawn version rather than rendering broken:

File	Where it appears
public/images/press-parrot-logo.svg	Header, footer, dashboard and admin logos
public/images/press-parrot-hero.webp	The homepage mascot

public/images/README.md has the full spec for both. The logo lookup lives in next.config.ts rather than the component, because the logo renders inside client components that cannot read the filesystem; the mascot lookup is in src/components/home/parrot-hero.tsx.

Social proof

src/lib/config/social-proof.ts holds customer logos and testimonials, and ships empty on purpose. While the lists are empty the homepage shows clearly-marked placeholders rather than implying customers or quotes that do not exist. Add real entries only with the customer's permission.

Live chat

A launcher sits bottom-right on every page. src/lib/config/support.ts chooses what it does:

NEXT_PUBLIC_CHAT_PROVIDER	Behaviour
built-in (default)	In-house panel; the message opens a prefilled email, tagged with the page the visitor was on
crisp	Loads Crisp, using NEXT_PUBLIC_CRISP_WEBSITE_ID
tawk	Loads Tawk.to, using NEXT_PUBLIC_TAWK_PROPERTY_ID and NEXT_PUBLIC_TAWK_WIDGET_ID
off	Hides the launcher

The built-in panel is a stopgap, not real live chat: it guarantees there is always a way to reach you, but nobody is watching a queue. Open a Crisp or Tawk account and flip the variable to get genuine live conversations, with no code change.

Bulk CSV import

/admin/websites/import, reached from the Import CSV button beside Add website. A five step flow: upload, map columns, review, import, results.

• Parsing uses Papa Parse, so quoted values, commas inside descriptions, mixed line endings and UTF-8 all work. Limits are 10 MB and 10,000 rows.
• Column mapping is automatic where the header is recognisable (DR, Traffic, RD, Domain URL, Category, Location and many more, listed in src/lib/import/fields.ts). Anything unmapped is ignored, and a destination can only be claimed once.
• Normalisation reduces URLs to root domains, reads 45K and 1.2M as numbers, strips currency symbols, accepts yes/no/true/false/1/0/y/n, and splits multi-value cells on commas, semicolons or pipes.
• Validation sorts rows into ready, warning, existing, duplicate and error. A bad row never blocks the rest of the file, and rows can be searched, filtered, deselected or edited inline.
• Duplicates are detected against the marketplace and within the file itself, after normalisation, so example.com, www.example.com and https://example.com/page count as one. The default is to skip existing websites; choosing update writes only the columns the CSV actually supplied, so empty cells never blank a stored value.
• Writing goes through websiteService.bulkUpsert() in batches of 200, with progress shown and a confirmation above 100 rows. That method is the single place to swap in a Supabase batched upsert.
• Afterwards the results screen offers the imported websites, an error report CSV (row number, domain, reason) and another import. Recent runs are listed under the websites table.

Only the domain column is required. Download the template from step one for the full set of supported columns.

Data layer

Components never import mock data directly. They call the service layer:

import { websiteService } from '@/lib/services';

const websites = await websiteService.getAll();
const website  = await websiteService.getBySlug('casinoguru-co-uk');
const results  = await websiteService.search({ niches: ['finance'], sort: 'dr-desc' });
await websiteService.create({ domain: 'example.co.uk' });
await websiteService.update(id, { status: 'active' });

Every method is async and returns plain typed objects, so the mock implementation can be replaced with Supabase queries without touching the UI. src/lib/services/data-source.ts holds the mock / supabase switch.

The marketplace filter, sort and pagination logic lives in src/lib/services/query-engine.ts as pure functions. The server uses it inside websiteService.search(); the client uses the same functions for instant filtering, so results are guaranteed to match.

What is still mocked

• Customer credentials - any email signs in and an unrecognised one creates an account. The session is real: a signed cookie the server verifies on every protected request, which is what gates the marketplace. Connecting Supabase Auth means replacing the lookup in src/app/(auth)/actions.ts.
• Admin identity - the admin area is genuinely protected (see below), but by a shared password rather than per-person credentials. Supabase Auth replaces that.
• Saved websites and order drafts - persisted in localStorage per browser.
• Payments and checkout - the submit button on an order draft is disabled.
• Admin writes - server actions mutate an in-memory store that resets when the dev server restarts. Bulk imports go to the same store, so an imported list does not survive a redeploy until Supabase is connected.
• Import history - recorded in memory alongside the websites.
• Live chat - the built-in panel hands off to email rather than opening a real conversation. Set a provider to change that.
• Brand artwork - drawn SVG placeholders until the logo and mascot files are added.
• Customer logos and testimonial - placeholder slots until real ones are configured.
• Article and brief uploads - the order page and the content brief record a file's name and size; the upload itself needs object storage.
• Content orders - stored in the same in-memory store as everything else, so orders placed in a session do not survive a redeploy.
• Content delivery - drafts are recorded by file name, or by pasting the article text. Downloads are disabled until storage is connected.
• Writer accounts - writerName is a plain field on a content order. The data model is ready for a writers table; there is no writer portal.
• Agency features - per-client workspaces and multiple user seats are marked "Coming soon" on the homepage and named as not-yet-built on /link-building-agencies.
• Page edits and blog posts - saved to the same in-memory store as everything else, so they are lost on redeploy. Every admin editing screen says so until the data source is Supabase.
• Image uploads - images are referenced by path or URL. Direct upload needs object storage.
• Editable pages - the homepage and the five service pages. /pricing and /how-it-works are still hardcoded.

Next steps

1. GitHub

git init                     # already initialised in this project
git add .
git commit -m "Press Parrot marketplace MVP"
git remote add origin [email protected]:<your-org>/<your-repo>.git
git branch -M main
git push -u origin main

2. Supabase

See supabase/README.md for the full walkthrough: create the project, run the three migration files, add the keys to .env.local, import the website inventory, then switch each service over to a Supabase implementation and replace the mock auth calls.

3. Vercel

1. In Vercel, Add New → Project and import the GitHub repository.

2. Framework preset: Next.js. No build command or output directory changes are needed.

3. Add environment variables for Production, Preview and Development:

   Variable	Example	Required
   NEXT_PUBLIC_SITE_URL	https://pressparrot.com	yes
   NEXT_PUBLIC_DATA_SOURCE	mock or supabase	yes
   NEXT_PUBLIC_ENABLE_MOCK_AUTH	false in production	yes
   ADMIN_EMAILS	[email protected],them@...	yes
   ADMIN_PASSWORD	a long random password	yes
   ADMIN_SESSION_SECRET	openssl rand -base64 32	yes
   NEXT_PUBLIC_CHAT_PROVIDER	built-in, crisp, tawk or off	no
   NEXT_PUBLIC_SUPABASE_URL	https://<ref>.supabase.co	with Supabase
   NEXT_PUBLIC_SUPABASE_ANON_KEY	eyJhb...	with Supabase
   SUPABASE_SERVICE_ROLE_KEY	eyJhb... (server only, never exposed)	with Supabase

4. Deploy, then add pressparrot.com under Project → Settings → Domains with "Redirect apex domains to www" unticked: the bare domain is canonical for this brand. Add www.pressparrot.com as well and set it to redirect to the apex, so the two hosts never both serve the same pages. Vercel shows the exact DNS records to add at the registrar. Copy the values it displays rather than any written down here; its recommended targets change over time.

5. NEXT_PUBLIC_SITE_URL must match the canonical host exactly (https://pressparrot.com, no www, no trailing slash), otherwise the canonical tags and point at a host that redirects.

Accessibility and performance notes

• Server components by default; client components only where there is interaction (filters, favourites, order builder, admin tables).
• Every control has a label, visible focus states are enforced globally, and the marketplace table exposes aria-sort on sortable columns.
• No website screenshots or thumbnails anywhere, so there are no large images on the critical path. The only graphics are inline SVG.
• prefers-reduced-motion is respected.