Copy-paste is not a product
Nobody starts a marketing site from a blank folder. You copy the last build that worked, then spend the first days stripping out what does not fit. The CMS — the place editors work — and the app still do not agree. The second client inherits the mess.
CloudPack is MethodGate’s answer: a project engine, meaning a marketing site you reuse. We built it for CloudCannon and a Next.js 15 site that exports static files, so it sits on a CDN and still goes through a review-then-go-live path. Live at cloud-pack.com. In February 2026 we wrote the technical walkthrough for the CloudCannon community. This page is the MethodGate record: what ships, why the wiring is the product, and when CloudTemplates or Cintesa is the better fit.
One schema. Two rooms.
Next.js does not give you a native content pipeline. Teams usually describe the page twice: once for CloudCannon, once for React. CloudPack uses one page schema — the structure that lets the site grow — so the editor and the app stay in sync through CloudCannon’s filer.
Components use Bookshop, CloudCannon’s component format. A prebuild script reads your folders and Bookshop blueprints and builds the component map. You do not maintain a separate React registry by hand. Rich text runs through one markdown-it pipeline, so what the editor sees is what the page renders. No second MDX stack.
The app exports static HTML. That is the publish path CloudCannon expects: pages are reviewed, then go live, and the files stay CDN-friendly.
What editors and developers actually get
Pages are sections on a 12-column grid. A section can hold several editable components, with its own background, spacing, appearance, and sticky behavior. Editors compose layouts without waiting on a unique build. In practice any page can be a landing: page → sections → styled blocks → configurable pieces.
The box includes 30+ editable components (heroes, FAQs, rich content, galleries, timelines, sticky image, horizontal scroll, and the rest of that library). Look and feel come from site settings: color palettes with light and dark variants, system-theme detection, Tailwind breakpoints, and fluid type. Company details, custom scripts, verification tags, and Google Tag Manager live in one project config.
On performance: code splitting, image output as WebP and AVIF, font loading, and an optional PWA so the site can install or work from cache. SEO is generated at build time — page metatags, structured data, sitemap — so a shared URL does not wait on a client render. Motion uses Framer Motion and Lenis for animation and smooth scroll; page changes can use the browser’s own navigation API.
Optional member areas sit on Firebase: Google sign-in, email and password, reset, and user management. Sections and pages can show or hide from login state, so a “members only” block does not need a second app.
i18n is in the product: more than one language without duplicating the engine. Editor and developer guides ship in the repo. Product plans stay on the product site.
Pick the product that matches the job
Use CloudPack when the deliverable should remain a full marketing site: campaigns, more than one language, editor-owned sections, a review before go-live. Use CloudTemplates when the job is campaign landing variants, not a whole site architecture. Use Cintesa when visitors should ask and get an answer from that project’s own content — a site they can talk to — instead of hunting a menu.
Why agencies hit a unique-build wall is the fulfillment bottleneck. Why a blank repo is the expensive default is the velocity advantage. When a fixed page tree is the wrong model, read the static site problem.
