Ever Works
An open-source system where AI agents research a topic, write and build the site, deploy it, and keep it updated. Everything lives in Git.
Next.js, NestJS, TypeScript, TypeORM, Trigger.dev, Turborepo
You describe a site you want. Ever Works researches the subject, writes the content, builds the site, deploys it, and then keeps working on it after you have stopped paying attention.
Both the content and the code live in Git, which is the part that matters commercially. You are not renting your own site back from a platform. If you walk away, you take everything with you.
I was the lead developer on this at Ever Co, across the web app, the API, the plugin system, the generation pipeline, and the background jobs.
From a sentence to a finished site
Turning a prompt into a real site is not one AI call. It is a sequence, and each step can fail on its own.
The system works out what the topic actually covers, generates candidate entries, searches the web to check them, fetches and reads the pages it finds, removes duplicates, sorts everything into categories, validates the sources, captures images, and writes the final pages.
Because that chain is long and some steps are slow, it saves its progress as it goes. A run that fails partway resumes instead of starting over, reports progress while it works, and stops cleanly when you cancel it.
It does not end at the first build. A directory can update itself on a schedule, so a site about a fast-moving subject does not quietly rot.
Not hardcoding a single vendor
The obvious way to build this is to pick an AI provider, a search provider, a host, and write them into the core. That works until a client wants a different one, or a provider raises prices, or a better model arrives.
So none of it is written into the core. AI models, web search, screenshots, content extraction, deployment, Git operations, storage, notifications, job runners, secret storage, and task tracking are all supplied by plugins. Each declares what it can do and what settings it needs, and the rest of the application asks for a capability without knowing who provides it.
This goes further than swapping models. A plugin can own the entire generation flow, so tools like Claude Code, Codex, Gemini, Zapier or Make can replace the built-in pipeline rather than sit inside it.
The hard part
Extensibility usually decays. Someone needs one provider-specific feature, adds a special case to the core, and repeats that until the abstraction is decoration.
Keeping that from happening was most of the design work. Everything provider-specific stays behind a capability the core defines, and the core never learns which provider is behind it. The cost is up front and real: you write more layers before the first feature works, and every new capability has to be described in general terms before anyone can implement it.
I would make that trade again. The alternative shows up six months later as a rewrite.
Working across the codebase
The project is a monorepo, so the API, web app, command line tool, automation server, and plugins all share the same types and business rules. A change to a contract fails the build everywhere it is wrong, rather than at runtime in one corner nobody was looking at.
Beyond generation, the platform grew agents with their own instructions, budgets and schedules, long-running missions, task tracking with reviewers and blockers, usage limits, and access for external automation.
Stack
Next.js and React on the front, NestJS and TypeORM behind it, TypeScript throughout, organised as a Turborepo monorepo. Trigger.dev runs the long jobs. Docker and Kubernetes for deployment. AGPL-3.0, and still pre-release.