Why I built Quicky.Page

There's a category of content that wants to be a URL but isn't a website. A note. A thread. An AI output. A launch announcement. A bio. A link. Today you either screenshot it, paste it into a Gist, or build a "site" for one page.

All three are the wrong shape for the content.

The loop

Open the page. Type or paste. Click Publish. Get a URL like quicky.page/abc123.

The same loop is exposed as an HTTP API (and an MCP server), so a script or any programmatic publisher can land a page in one call. Same publishing primitive, different interface.

Why the constraints are the product

Every constraint exists because constraint is what makes the publish loop instant. A website builder's flexibility costs you a decision at every step. Quicky.Page removes the decisions so "publish this" is the only thing you have to think about.

The same constraints make it safe to expose the publish endpoint to a programmatic caller. The block schema is small enough to teach in two sentences and narrow enough that bad output is structurally impossible — no script tags, no event handlers, no arbitrary iframes, no JavaScript runtime.

This page was made on Quicky.Page. You can make one too at quicky.page.