Home / The Genesis of Qwiki

The Genesis of Qwiki: Why We Built the Zero-Database Engine We Couldn't Find

"Every great tool starts with a quiet frustration: looking at a landscape of dozens of options and realizing not a single one does the simple thing you actually need."

The Dilemma at Xentara

The story of Qwiki didn't start in a vacuum; it began in the trenches of building the Xentara Platform and Xentara Studio—an AI-assisted curation and knowledge discovery engine.

At Xentara, human curators work alongside automated discovery pipelines to sift through vast streams of information. Every day, they uncover valuable insights, write internal communiqués, draft briefings, and curate essential articles. We needed a publishing surface that got out of the way.

Our criteria were straightforward:

  • Effortless publishing: Curators needed to format and publish articles on the fly as they discovered important material.
  • Bi-directional AI ingestion: The discovery pipeline required a clean, lightweight RSS/syndication feed to ingest articles, while AI agents needed a direct, headless API to push fresh Markdown straight into the content store.
  • Zero maintenance friction: It had to be a lightweight folder drop-in on standard PHP hosting—no complex databases, no server daemons, and no build queues.

It sounded like a standard requirement. But when we went looking, the landscape was surprisingly broken.

The Landscape: Heavy, Clunky, or Locked Down

We surveyed the existing options, hoping an off-the-shelf solution would suffice. Instead, we ran into the same wall over and over:

🐘 WordPress & Ghost

Massive overkill. Required MySQL databases, database migrations, plugin bloat, continuous patching, and immense maintenance overhead for simple article publishing.

📄 Bludit & DokuWiki

Flat-file alternatives, but with dated architectures. DokuWiki relies on proprietary wikitext and clunky hierarchies; Bludit lacked a smooth headless ingestion API and flexible multi-format rendering.

🧱 Google Sites & Notion

Walled gardens. No autonomous programmatic control, no self-hosting independence, and no clean webhook/feed pipeline for AI discovery engines to tap into.

⚙️ MkDocs, Hugo & Astro

Great for static code docs, but poor for non-technical curators. Every edit requires a Git commit and CI/CD rebuild, preventing instantaneous live editing and dynamic API injection. Everything was either overkill, too complex, or technically outdated. We didn't want to spin up a Docker cluster, manage database connection pools, or force our curators to learn terminal Git commands just to publish a briefing.

The Vision: A True "Drop-In" Engine

We decided to distill the wish list down to its absolute essentials:

  1. Zero Database (0 DB Queries): Store everything in clean, human-readable JSON (qwiki.json) and standard Markdown/HTML files. Backups should be as simple as zip or rsync.
  2. True Subfolder Mobility: Drop the folder anywhere—into domain root, /docs, /blog, or /kb—and have it work immediately without URL re-write head-scratching or hardcoded base paths.
  3. 100% Open Source: Built strictly on battle-tested open-source primitives (vanilla PHP, Parsedown, Toast UI, SunEditor) with zero licensing traps.
  4. Polyglot Content Engine: Seamlessly mix and display native Markdown (.md), rich sandboxed HTML (.html), embedded PDFs, and Google Docs under a unified navigation tree.
  5. Machine & Human Friendly: A browser-based visual WYSIWYG editor for human curators, paired with an API endpoint (publishApiKey) and RSS feeds for autonomous AI discovery pipelines.

It was an ambitious vision, but Franco had built foundational architectures like this in previous years and knew the core primitives were sound.

The Turning Point: Pairing with Antigravity & Gemini

Instead of spending weeks setting up boilerplate, drafting scaffolding, and fighting edge cases, Franco decided to harness Google Antigravity and Gemini.

Treating the AI not as an autocomplete tool, but as a deep pair-programming partner, we moved at an unprecedented velocity. The architecture was sketched, challenged, and implemented in real time:

  • In one afternoon, the foundational core was alive: zero-database JSON indexing, dynamic Parsedown compilation, responsive sidebar navigation, and the headless ingestion API.
  • What followed was a series of intense, disciplined iterations:
    • Adding collaborative soft-locking with live heartbeat leases so multi-tab and multi-user edits never overwrite each other.
    • Engineering zero-flicker theming using synchronous server-cookie negotiation to kill FOUC entirely.
    • Adding intuitive drag-and-drop hierarchy reordering that writes back straight to qwiki.json.
    • Baking in an agentic SVG chart & badge generator for instant technical illustrations.
    • Perfecting single-line video auto-embedding with native privacy wrappers.

What started as an afternoon prototype matured into a battle-hardened, production-ready documentation portal.

Eating Our Own Dogfood

Today, Qwiki doesn't just power our internal Xentara curation feeds—we "eat our own dogfood" every day:

  • qwiki.wiki: The official product landing page is served live by Standalone Qwiki.
  • qwiki.wiki/docs: The entire documentation manual runs as an independent Qwiki subfolder deployment right alongside it.

It is blazingly fast, runs on any PHP host (from a $3/mo shared hosting plan to a Raspberry Pi or an enterprise cluster), requires no database migrations, and handles human and machine-generated content with equal grace.

After countless real-world iterations, we are proud to release Standalone Qwiki to the open-source community under the MIT license.

"Incredibly powerful, stupidly simple."