We’re building Ever Works in public. Some things may be incomplete, missing, or broken while we continue improving the platform.We’re building Ever Works in public — expect a few rough edges.
Use Case
A website is not done the day it launches. Ever Works generates a marketing or product site from a template — with researched content, not lorem ipsum — and then keeps it alive: new pages, updated copy, fresh examples, all on a schedule, all committed to your own Git.
Researched, on-brand content from the same pipeline every Work runs — kind-specific page copy is rolling out.
Generated from a strong Next.js or Astro base.
New pages and updated copy ship on the cadence you set.
Deploy to Vercel, Docker, or your own host. Nothing locked in.
Because the runtime keeps researching and publishing, your site compounds in value instead of decaying. Add a Mission and it can even propose the next pages and sections your goal needs.
Nothing here is a wizard you have to finish in one sitting. This is the shortest honest path from a sentence to a deployed site that keeps working, using the screens exactly as the product names them.
Click + New in the sidebar, say what the site is for — “a marketing site for a two-person physiotherapy clinic, calm tone, booking as the main call to action” — and pick the Website chip. Your prompt and the kind carry through to the create form, where you name the Work and can open Advanced to choose the research pipeline and AI provider before pressing Create.
The template picker shows two layers for the Website chip: your own Work templates first, then the blueprints published for that chip — Marketing Site among them, with placeholder blueprints filtered out. Pick nothing and the Work resolves to the general-purpose Website base on Next.js, unless you have saved a default template of your own; Website (Minimal), the static Astro build, is the opt-in alternative. Choose your Git provider and deploy target in the same form: Vercel, your own Kubernetes cluster, or managed hosting on ever.works. Choose deliberately: the template locks after the first generation, and switching it later from Settings resets the Work repository from the new base, replacing whatever is in it.
The Work lands on Overview; open the Worker tab to start the first run — Start Work streams progress live, and a run can be cancelled mid-flight. Do not wait for it to finish before you open the Memory tab — put your positioning, your tone of voice and the words you refuse to use in there, because that Knowledge Base is what every later run reads before it writes a line.
Deploy from the Deploy tab. On managed hosting — ever.works, or your own Kubernetes cluster — the Work is allocated its own managed address on ever.works and the Deploy tab shows the card for it; deploy to your own Vercel instead and the build lands in your Vercel project rather than on an ever.works address. Custom domains work either way: add one and the page hands you the exact DNS record to create, then verifies it. Once the first generation has completed you can arm a cadence on Worker → Schedule — seven of them, hourly through monthly, retried after 15 minutes on failure and auto-paused after repeated failures, three consecutive by default and settable from one to ten — and assign an Agent so the site has someone minding it between runs.
Every Work kind gets a different set of tabs and tiles. The website kind keeps what a marketing or product site needs and hides the directory machinery it does not, so there is less to learn and none of it is decorative.
The items surface is renamed Pages for this kind, and the affordances a directory needs are switched off: no categories and tags, no head-to-head comparisons, no bulk item import or export, no source-URL validation. Fewer tabs, all of them relevant.
A website Work provisions all three runtime repositories in your own Git account, and the product names them on the Work: the Data Repository holding the structured content; a readable Markdown mirror, shown as your GitHub — or other provider — Repository, which people browse on the provider and which is never deployed; and the Work Repository, the template output that is built and deployed. Every autonomous change lands in them as a commit you can read.
The Overview tiles for this kind are page views, sessions, registered users, deploy status and generation status — whether the site is live and being read, rather than how many catalog entries it holds. The two traffic tiles report as not configured until you connect an analytics provider.
The Memory tab is a workbench, not a notes field: drop files or use Add doc, classify and edit them, lock the ones that must never drift, and clear the review queue where proposals arrive to Accept, Edit then accept, Supersede or Archive. A health panel shows the backlog and the topics the site still has nothing to say about.
Website is a first-class Work kind rather than a directory wearing a different label: the chip is live on the create page, and the Pages surface, the Knowledge Base, the schedule, the deploy, the custom domain and the three Git repositories all work now. One part is still landing, and it is the part worth knowing before you plan around it — the content generator was built for directory-shaped content first, and a website Work is built from the general Website template, so kind-specific page-copy generation is rolling out rather than shipped. In practice the site, the repositories, the deploy and the upkeep loop are yours on day one, while the first pass of page copy is a conversation you have with the Work rather than something that arrives fully written.