Ideas

Let the authenticated Built.at platform administrator quickly create, edit, or fix pages belonging to another user (such as @jeff) using ordinary ChatGPT, without account switching or requiring a collaboration invitation.

Why

In a small community, the platform owner can help users with quick changes directly when asked.

Possible implementation

Extend the existing inspect/act operations with an explicit target username and server-verified administrator authorization. Preserve page version history and undo, and keep ordinary users limited to their own or expressly shared pages. No separate dashboard needed. Consider after dynamic API, inbox, and collaboration work.

Let ChatGPT/AI upload an image or other asset directly to Built.at and receive a permanent public URL that can be used in page HTML.

Why

Generated images currently need awkward workarounds such as Base64 or external hosts like Google Drive, which are unreliable for embedding.

Possible implementation

Add an MCP action such as upload asset. Built.at stores the file in Cloudflare R2 (or similar object storage) and returns a stable URL such as https://assets.built.at/nate/abc123.webp.

Allow a page owner to give another person permission to edit a specific Built.at page, so pages can work as shared lists or collaborative mini-apps.

Why

Pages like a household grocery list need multiple people to add, remove, or update items without sharing the owner's whole Built.at account.

Possible implementation

Add page-level collaborators/permissions. Owner can invite specific users or create an edit-enabled share link; collaborators can edit that page only. Keep public view access separate from edit access and maintain basic change history.

On moving the repository: I think doing it early makes sense. Use GitHub’s transfer feature instead of copying the repository so branches, history, pull requests, settings, and redirects are preserved. GitHub says web and Git operations redirect from the former location, while webhooks, repository secrets, and deploy keys remain associated. You should still update local remotes afterward and never reuse the old repository location, because that removes the redirect. GitHub repository-transfer documentation I found no GitHub Actions workflows, repository secrets, variables, webhooks, GitHub Pages site, or hard-coded nathanpuls/SayPage references in this repository. Therefore, the likely follow-up list is short: - Update local Git remotes and saved Codex project references. - Confirm whether Cloudflare has a GitHub App/build connection configured outside GitHub; if so, grant it access to the new organization/repository. - Check any external bookmarks or integrations not stored in the repository. - Leave internal names like the saypage Worker, D1 database, _saypage routes, and existing MCP resource identity unchanged unless you separately decide to migrate them. Built.at is valid as a GitHub repository name—the period is allowed. GitHub repository naming rules My recommendation is to transfer and rename it early, after this branch is merged, because there are currently very few integrations to repoint.

A simple “Leave a note” button on any Page for logged-in users. Type or dictate edits, ideas, questions, or reminders. Save the current Page as context, but allow general notes too; AI infers whether a note concerns that Page or the wider account without a category picker.

Why

Capture thoughts while viewing a Page on mobile without remembering them or switching apps. Collect notes across Pages, then ask ChatGPT to read them and apply changes in one batch. Keep chat as the main interface.

Possible implementation

Use one text area and Save button. Store note text, account owner, current Page ID/URL, timestamp, and processing status. Expose pending notes through the MCP so ChatGPT can retrieve them and mark handled notes. Start with manual “Read/apply my notes” in ChatGPT; automatic push and clickable-element annotations can wait.

Allow Pages to be public or private. Consider an unlisted/link-only state later.

Why

Right now a Page attached to a path is public. Private Pages would let Built.at hold personal or unfinished things without publishing them.

Possible implementation

Add Page visibility behind the scenes and let users change it conversationally through ChatGPT. Keep the UI minimal; owner-only indicators can show status.

Keep the existing side panel as a lightweight drawer. Put search at the top, but also show browsable Pages and folders when no search is active. Search should return both Pages and folders.

Why

Direct retrieval is often faster than asking AI when the user already knows what they want. A side panel keeps the current Page primary and avoids turning Built.at into a dashboard.

Possible implementation

Open panel → browse recent/all Pages and folders. Start typing → instantly filter across Pages and folders. Tap a folder to browse it; tap a Page to open it.

Add an owner-only Settings area, but not a traditional settings dashboard. Most actual changes—such as username or organization—should still be made conversationally through ChatGPT.

Why

Gives account-level information a home without duplicating AI controls or adding visual complexity for public visitors.

Possible implementation

Only show Settings to an authenticated owner. It can display account/connection/storage/export information, with very few or no direct controls.

In Settings, provide one intentionally editable area where the owner can write persistent standing instructions/preferences for AI. This is distinct from the existing AI-created notes feature.

Why

Lets the user directly tell Built.at/AI enduring preferences without repeating them in every conversation.

Possible implementation

Use the existing private account-level notes infrastructure underneath, but expose a simple user-facing text area such as “Notes for AI.”

Keep frequently used actions such as Copy near the bottom of the side panel rather than burying them in Settings.

Why

Frequency should matter more than strict taxonomy; common actions should remain one tap away.

Possible implementation

Use the panel for fast navigation and frequent actions; reserve Settings for infrequent account-level information.

Treat ChatGPT itself as the place to prototype, preview, and iterate on Pages before publishing to Built.at rather than rushing to build a separate preview mode.

Why

The current workflow already allows visual experimentation without filling Built.at with unfinished Pages.

Possible implementation

Keep this as a product principle for now: ChatGPT is the workshop; Built.at is where the result gets published. Revisit a native preview mode only if a clear need appears.

Make Settings primarily a simple, owner-only, read-only view of the account’s current configuration and persistent AI context. Changes happen conversationally through AI rather than through traditional toggles, forms, or controls. Users can say things like “Add context: keep my pages minimal,” “What context do you have?”, “Remove that preference,” or “Make my pages private by default.” Built.at stores the resulting settings/context as the durable source of truth and automatically supplies relevant context to AI. Keep a minimal Settings/Context view so the owner can inspect what Built.at currently knows.

Why

Keeps Built.at near-zero UI while making settings explicit, persistent, and reviewable. ChatGPT memory can help, but Built.at should own account-specific preferences so they work reliably across conversations and potentially across different AI clients. Conversation becomes the universal settings editor, avoiding a new UI control for every future capability.

Allow designated Built.at admins to query and manage platform-wide data through the normal MCP interface, including users/usernames, pages, assets, activity, and aggregate statistics. Admins can also view, edit, and troubleshoot other users’ Pages. Users, Pages, assets, and audit/activity records remain different data types in the same database but are exposed as one unified queryable system rather than separate tools.

Why

Lets an admin simply “ask Built.at anything”: find a user, inspect their Pages, fix a Page, see signups or totals, or ask what changed and when. The admin should not have to think about separate user-search, page-edit, or audit-log interfaces.

Possible implementation

Extend the MCP’s general data model/query capability across the platform database. Enforce access by authenticated role: admin sessions can query and edit across accounts, while normal users remain scoped to their own data. Record admin changes as activity/audit records in the same database, including admin, affected user/Page, action/change, and timestamp, so the history is also queryable naturally through the MCP.

Let Built.at’s owner manage Built.at’s own bugs, feature requests, ideas, and development notes directly through conversation or voice. Commands like “add this as a feature,” “that’s a bug,” “put this on the someday list,” “what features are planned?”, or “mark that fixed” should read and update the project data without opening a spreadsheet, Work, or a separate admin UI.

Why

Makes talking to Built.at the actual development-management interface. Ideas can be captured the moment they occur, with almost no UI, typing, or context switching.

Possible implementation

Store project-management records as queryable Built.at data exposed through the MCP, with types/status such as feature, bug, idea, someday, planned, and done. Allow natural-language create/read/update operations and voice input. The current Google Sheet can remain as a temporary backend or sync target, but should not be required as the user-facing workflow.

Make the Built.at MCP a stable, general-purpose control layer where front-end content and behind-the-scenes/admin data are manipulated through the same conversational model. Pages, folders, users, permissions, settings, project data, statuses, relationships, and future data types should be creatable and editable as data whenever possible, without adding a new hard-coded MCP action for every change.

Why

Lets Built.at evolve by talking to it. Most product and admin changes can become database changes instead of requiring Nathan to modify MCP code, redeploy tools, or build separate interfaces.

Possible implementation

Design the MCP around generic authenticated read/create/update/move/relate/delete operations over typed database entities, with role-based scope and schema/metadata that tells AI what entities and fields exist. Add new MCP/backend code only when a genuinely new capability or external system is required; prefer data/configuration for new types, settings, statuses, relationships, and workflows.

Once Built.at has fundamental capabilities such as text rendering, image/file storage, code execution, scheduling, or external-service access, let the owner create new product features conversationally by recombining those existing capabilities. Example: if image storage already exists, saying “Pages can have image galleries now” should be enough for AI to create the necessary data model/configuration and behavior without rewriting the MCP.

Why

Shortens the normal idea → developer → code → deploy → feature loop into idea → say it → AI recombines existing capabilities → feature exists. Makes Built.at itself substantially reconfigurable through conversation rather than requiring a new interface or deployment for every feature.

Possible implementation

Think in three layers: primitives (generic operations such as create/query/update/relate), capabilities (things the system fundamentally knows how to do, such as store images or execute code), and spoken features assembled from those capabilities. Only add backend/code machinery when a genuinely new capability is required; otherwise let AI express the feature through data, schema, relationships, configuration, and existing capabilities.

Do not show the Built.at top-center Page-name/copy label by default on newly created Pages. Users usually put their own title or heading in the Page content, so the system label often duplicates it. Keep the capability available when explicitly wanted.

Why

Avoids duplicate titles and keeps Pages visually clean and fully controlled by the Page author.

Possible implementation

Change the default/new-Page behavior so the global top-center Page-name element is hidden unless a Page or account explicitly opts in. Existing Pages can keep their current behavior unless changed.

Create a visual Showcase of polished Built Pages across different uses—blog, notes, podcast, portfolio, photo gallery, live list, tiny app, documentation, experimental pages, etc. Each example includes a simple action such as “Make something like this” that acts as a prewritten prompt rather than a rigid template.

Why

Shows people the range of what Built can become and removes the blank-page problem. The examples teach users what they can ask AI to make without locking them into templates.

Possible implementation

Build a browsable gallery of real example Pages. Each card can open the example and offer a prompt starter that carries the example Page as context into ChatGPT/Built, e.g. “I like this Page. Help me make something like it for my podcast.” Treat examples as visual inspiration/context, not templates that must be copied exactly.

Allow JavaScript running on a Built Page to securely query and interact with permitted Built data. A user could say things like “add a search bar that searches all my notes,” and AI could create a real working interface rather than only searching content embedded in that Page.

Why

Turns Pages from static webpages into lightweight applications that can work with live Built data. Unlocks account-wide search, live lists, dashboards, comments, dynamic galleries, shared data, and many other conversationally created features.

Possible implementation

Expose a secure Page-facing data API backed by Built’s shared data model and permission system. Page JavaScript can make scoped authenticated queries/actions against data the viewer or Page is allowed to access. Keep credentials and privileged operations server-side, enforce permissions in the backend, and let AI generate the Page UI and JavaScript that use the API.

Automatically back up Built’s live production data independently from the GitHub repository and local development machine, including user Pages, assets, settings, relationships, and other database content.

Why

GitHub protects code history but does not by itself protect live user data. An independent backup reduces the risk of losing production content because of accidental deletion, database corruption, account problems, or deployment mistakes.

Possible implementation

Create scheduled database backups/snapshots and asset backups to storage independent of the primary production system and GitHub. Keep multiple dated versions, define a retention policy, and periodically verify that a backup can actually be restored. Prefer an automated process that requires no manual downloading.

Let users optionally connect their own Cloudflare account through OAuth so Built.at can provision and use resources such as R2 storage and Workers inside the user's Cloudflare account. Keep Built.at-hosted infrastructure as the simple default.

Why

Gives power users much more per-user storage and infrastructure capacity while letting storage, usage, and billing live on their own Cloudflare account. Reduces pressure on Built.at's shared quotas/costs and enables more powerful apps without exposing Cloudflare complexity.

Possible implementation

Add a seamless Connect Cloudflare flow using Cloudflare OAuth with narrowly scoped permissions. After authorization, Built.at can create/use approved resources such as R2 buckets and Workers in that account while keeping credentials and provisioning behind the scenes.

Let Built.at users follow other users and have a personal news feed showing new or updated public Pages from the people they follow.

Why

Makes Built.at feel alive and social instead of just being a collection of isolated Pages. It gives users a reason to come back, discover what friends or creators are making, and see new things without needing direct links.

Possible implementation

Add follow relationships between users. Create a simple chronological feed of public Page activity from followed accounts, such as newly published Pages or meaningful updates. Keep it lightweight at first—no algorithmic ranking required. Later this could expand to likes, comments, reposts, or discovery.

After creating or modifying a public Page, Built.at should return the exact URL of the Page/path that was changed. If multiple Pages were changed, return each relevant URL.

Why

The finished result is immediately accessible without the user having to navigate through their account or ask where it is.

Possible implementation

Have the MCP/server return the exact public URL(s) for successfully created or modified Pages. If a Page has multiple paths, prefer the path the user was actively working on.

The hello@built.at email address does not currently work.

Why

A broken public contact address can cause messages to bounce or disappear and makes Built.at harder to contact reliably.

Possible implementation

Configure or repair mail routing for hello@built.at, verify inbound delivery end-to-end, and add basic monitoring so failures are noticed quickly.

Allow a user to add or attach a file to a Built.at Page, not just images—such as a PDF, document, audio file, or other downloadable asset.

Why

Pages could become more useful for sharing supporting material, downloads, documents, audio, and other content without needing a separate hosting workflow.

Possible implementation

Extend Built.at assets/file storage so ChatGPT can upload a file, associate it with a Page, and place a link, download button, embed, or other appropriate representation on the Page using a stable Built.at URL.

Zip files

Image cleanup / inpainting — Add an inexpensive or free Built.at capability that can remove baked-in text or objects from an image while preserving the rest as faithfully as possible. Useful for turning AI-generated webpage mockups into real pages: clean the text areas, keep the original artwork, then overlay real HTML text/buttons. Could use a Cloudflare/LaMa-style inpainting service and expose it through the existing Built.at MCP.

Showcase prompts — Alongside showcased Built.at Pages, show the prompt that created the result (or a cleaned-up version of it) so people can see how it was made and use that prompt as a starting point to create something similar. This makes examples teach users what to ask for, not just what is possible.

Viral storytelling formula — For Built.at marketing/demos, make even mundane features compelling by wrapping them in a tiny story. Formula: hook immediately → establish a clear goal → create tension/curiosity → introduce a twist or personal reason → deliver the promised payoff quickly. Every second should have a purpose. Core principle: the underlying subject doesn’t need to be inherently exciting; the presentation gives it meaning. Example: instead of “I made a webpage by talking to ChatGPT,” use “I wanted to see if I could build an entire website without touching a keyboard.”

When someone shares a Built.at Page, show a preview image of that specific Page instead of a generic website icon. Generate an actual screenshot for each Page automatically, including new Pages, without requiring a separate ChatGPT instruction.

Why

Sharing a Pun Run game should show Pun Run; sharing a Schedule should show that Schedule. The preview immediately communicates what the link contains and makes sharing more inviting.

Possible implementation

Use a browser-rendering service to capture a 1200 × 630 social preview when a Page is published or changes. Store and cache images in the existing R2 bucket, expose them in server-rendered Open Graph and Twitter card metadata, and regenerate only on meaningful updates. Handle redirects and dynamic/interactive Pages sensibly. Test the iPhone share sheet, Messages, and other link previews; the receiving app ultimately controls presentation.

Status: Future idea, not implemented.