Anticode Open builder

An open source project website that gets a developer from curiosity to install

Developers arrive at an open source project website with one question: is this the thing I need? The page should answer it in a sentence, show the install command, prove it works with a small example, and point to the code. Sponsors and adopters come later and need a different page. Here's the layout, and where Anticode helps.

Updated · By the Anticode team

Why a site when there's a README?

A README is written for people already in the repository. A project site does other jobs: it ranks for the problem the project solves, explains it to people who don't yet know it exists, gives the project a stable address independent of where the code is hosted, and makes the case to companies that might adopt or fund it. Small projects can live happily on a README; projects with users beyond their contributors usually benefit from a site.

The home page, top to bottom

  1. Name and a one-line description of what it does, in terms of the reader's problem: "Validate configuration files against a schema in CI", not "A blazing-fast, modern toolkit".
  2. The install command in a code block, for each package manager you support.
  3. A minimal example: the smallest real code that shows the point, with its output.
  4. Links: repository, documentation, changelog, licence.
  5. Who uses it, only if those organisations have agreed to be named.
  6. Sponsor and community links.

Design-engine pages run no scripts, so there's no copy-to-clipboard button on the code block; most developers select the line anyway. Keep code blocks short so they fit a phone screen without sideways scrolling.

Docs pages in the CMS

For a small project, a handful of documentation pages covers most needs: getting started, configuration, a few how-to guides, an FAQ, and an API overview. A docs CMS collection with fields for title, summary, section and body gives each page its own address and lets maintainers edit them from the dashboard. It's a good fit for stable, prose-heavy docs.

Be honest about the limits. The CMS isn't a docs-as-code tool: it doesn't build from Markdown in your repository, version docs per release, generate API references from source, or offer full-text search. For large or fast-moving projects, a static documentation generator in the repository is the better choice, and the Anticode site can be the landing page that links to it. See documentation website for that split.

Repository and community links

Code
The repository, the issue tracker, and the contributing guide.
Talk
The forum, chat server or mailing list, with a line on what each is for.
Releases
A changelog page in the CMS, or a link to release notes in the repository.
Governance
The code of conduct, how decisions are made, and who maintains the project.
Security
How to report a vulnerability privately, with a contact address.

Sponsorship via payment links

Many maintainers use a dedicated sponsorship platform, and linking to it from a "Sponsor" page is often enough. If you also offer fixed packages to companies (a logo on the site, priority issue triage, a support contract), describe each tier and point the button at a payment link from Stripe, PayPal, Lemon Squeezy or another provider. An account has one payment link, so for several tiers, link to a page at your provider that lists them. Say what sponsors' money pays for and how it's accounted for; fiscal hosts and foundations often publish this, which companies like.

For larger support contracts, a custom form tied to a site function can collect the company, the use case and the kind of support wanted, and a connector can send it to the maintainers' Slack, Discord or a HubSpot account.

Design for developers

Technical (IBM Plex Sans) suits most developer projects; Swiss (Inter Tight) works for a cleaner product feel. Dark theme is popular but keep code blocks well contrasted. Skip the purple-blue gradient hero; Anticode's design gate blocks it anyway, along with placeholder text and empty links (it doesn't check that outside URLs work). The site's own sitemap, robots.txt and llms.txt are generated on publish, which helps both search engines and AI assistants describe the project accurately.

Limits

  • No docs built from your repository, versioned docs or site search.
  • No embedded demos, sandboxes or GitHub widgets; link to them.
  • No copy buttons or interactive code on design-engine pages.
  • No sponsorship platform features; payment links only.

Questions people ask

Can Anticode host the documentation for an open source project?

For a small, stable set of pages, yes, as CMS entries. Larger or versioned docs are better built from your repository with a docs generator.

How do I take sponsorship on the site?

Link to your sponsorship platform, or point the sponsor button at your payment link, with the tiers listed at your provider.

Can I keep the site's source in the project repository?

You can export the site as a standard Next.js project and push it to a GitHub repository you pick, or download it as a single HTML file.