Websites and documentation
Make the product make sense.
A capable product still needs a clear way in. We build websites and documentation that explain the offer, show the work and help the next person take a useful step.
See keen’s documentation- 8.7 → 1.6 MBRecorded image-weight reduction
An earlier company-site image pass, documented in May 2026.
- 29Public documentation source pages
MemIndex’s public documentation guide set.
- One sourcekeen guides and command reference
Documentation and generated command data feed the website.
- UnderstandStart with the buyer’s problem and next decision.
- SourceUse product facts, guides and command data.
- PublishGive each route real text and its own metadata.
- CheckInspect content, navigation, indexing and error states.
The problem
A product line can turn into a collection of repositories wearing a shared logo. Features appear in the order they were built, navigation grows around old releases and the homepage tries to explain every technical detail before a visitor understands the offer.
Documentation has a related problem. A guide maintained separately from the product drifts. A command reference written by hand misses changes. A page can look complete in a browser while offering little useful text to a reader who arrives through search, a preview or an AI assistant.
Who it’s for
Software companies with complicated products, growing documentation or websites that are harder to understand than the product itself.
What we built
Our web work includes eight.ly, homelabarr.com, memindex.ai, NeuroHelper’s product site, the Eight.ly wiki and keen’s documentation. These are different products with different buying decisions. Their websites give each one an appropriate explanation instead of forcing the same product pitch into every page.
For keen, the website draws guides from the product’s documentation and generates command pages from its command list and the official API specifications. Every page is built as its own HTML file. Checks reject missing titles, thin content, unlinked pages and routes missing from the sitemap.
For MemIndex, marketing and documentation share one static build and domain. Route manifests feed page generation and the sitemap. The documentation includes a searchable public guide set, stable heading links and agent-specific setup instructions. The product’s architecture diagrams have text equivalents and respect motion preferences.
How it works
We begin with the reader’s question and place the useful answer before the product’s internal structure. Deep explanations belong on dedicated pages. A homepage should establish the offer and guide someone toward the evidence relevant to their problem.
Shared content and metadata keep the route, title, description, navigation and sitemap connected. Where the product already owns the facts, the site reads those facts rather than creating another handwritten source. Documentation can then follow a changed command without a second editorial migration.
The finishing work includes page-specific social previews, structured metadata, semantic sections, deliberate image loading and real error pages. In an earlier company-site performance pass, recorded image weight fell from 8.7 MB to 1.6 MB. The pass also added explicit image dimensions and deliberate loading priorities to keep the page stable as it loads.
What was hard
The difficult part is deciding what to leave off the first page. Technical range is valuable proof, but asking a new visitor to absorb it all at once weakens the offer. Our earlier site work reduced homepage headings and moved individual product explanations onto their own pages.
Keeping a website true matters just as much as making it attractive. Old offer language, unsupported integration claims and stale instructions can survive a visual redesign. We use the product source to check those details and distinguish a working capability from a future plan. A readable page and an accurate page have to be the same page.