The blank repo tax
A new Next.js app looks fast on day one. Then you wire the CMS, duplicate the page schema, hand-maintain a component map, and discover that what the editor sees is not what the app renders. The second project copies the first with the messy bits intact.
That is not a talent problem. It is the cost of treating every marketing site as a unique codebase. We described the engine alternative on the CloudPack site in The velocity advantage — why solo developers choose project engines. That article is the canonical product essay. This is how MethodGate uses the same idea across three products.
Engine, landings, or conversation
CloudPack is the full marketing engine: one schema for CloudCannon and the app, static export, visual editing without a second Markdown pipeline. Live at cloud-pack.com.
CloudTemplates is the landing pack: complete page patterns, bind-level editing, git previews. Live at cloudtemplates.io. Use it when you need variants, not a whole site architecture.
Neither of those replaces a site that must answer. Cintesa is the conversational generative-UI product with its own CMS — cintesa.run — when the visitor’s job is to ask, not to browse a starter layout.
Pick the engine that matches the job
Velocity is not “ship any HTML faster.” It is refusing to re-litigate the stack on work you already know how to repeat. If fulfillment across many unique sites is the pain, read the fulfillment bottleneck. If the page tree itself is the wrong model, read the static site problem.
