More people.
Making more things.
A practical guide to Built.at—and a longer story about making the internet easier to create, together. From your first page to the architecture underneath it.
What is live versus what's next? This handbook describes capabilities that exist today and separately calls out ideas and engineering work still in progress. The connected Built.at service is the source of truth for exact available operations.
Why Built.at exists
The web should be something you can make, not just something you browse.
The distance between an idea and a link
For years, publishing something useful on the internet meant learning the stack, choosing hosting, wiring a database, and navigating deployment. Those are powerful tools, but they are also gates. A teacher with a classroom idea, a parent with a family project, or a neighbor organizing an event shouldn't have to become a developer first. Built.at starts with a different question: what if the idea could come first?
Built by chat
You describe a thing. ChatGPT helps turn it into a real webpage, saves it through Built.at, and gives you a URL. You open it, react, and ask for changes. That loop can be remarkably fast: describe, publish, inspect, improve. The goal isn't to hide how software works forever. It's to make working software reachable before you've learned every part.
A place to make things
Some projects are useful; others are silly, personal, experimental, or unfinished. They all deserve room. Built.at is meant to be a welcoming place for sketches, family pages, portfolios, tools, collections, prototypes, and eventually richer applications. Not every idea needs a business plan. Sometimes having a place to try it is enough.
Free and open to possibilities
A lower barrier changes who gets to participate.
Free as a direction
The ambition is to make ordinary creation available to everyone without a paywall standing between a thought and a published page. Infrastructure does have costs, so sustainable limits and responsible usage matter. Free should be a practical commitment pursued transparently, not a promise of unlimited compute, storage, or custom infrastructure.
Break down walls
A traditional software workflow can divide people into those who know how to build and those who must ask somebody else. Conversational creation softens that divide. The person with the idea can remain the creative director while AI does much of the translation into implementation. Expertise still matters—especially for security, accessibility, and reliability—but it shouldn't be a prerequisite to participate.
Community over gatekeeping
The larger hope is a culture where people share what they discover, learn from each other's creations, and remix good ideas with permission. Collaboration and invitations already exist in bounded forms; broader social discovery and community features are possibilities, not promises of features already shipped. The principle is simple: make it easier to help each other make things.
Your first five minutes
Start small, publish, then change your mind.
Connect once
Open the connection instructions at mcp.built.at and add Built.at to ChatGPT. Once authorized, ChatGPT can inspect the resources your account is allowed to see and apply supported changes. You do not have to paste source code back and forth for routine edits.
Try a real prompt
Ask: “Make a simple page for my neighborhood book exchange, with a welcome note and a section for upcoming swaps.” Open the returned page link. Then ask: “Make it feel warmer, add a small FAQ, and improve the mobile layout.” You can use plain words rather than specifying HTML or CSS.
Keep ownership of the idea
AI can move quickly, but you decide what belongs on the page. Check the text, links, images, and interactive behavior. Publishing is immediate for ordinary page edits, so be deliberate with private information. Start with information meant to be public, and treat sensitive data and account credentials differently.
The making loop
The best prompt is often the next one.
Describe instead of specifying everything
A good first prompt explains the audience, purpose, and feeling. It does not need pixel-perfect instructions. “A quiet, minimal reading list for friends” is enough to start; “move the navigation to the left and reduce the visual noise” is enough to continue. Chat is an iterative design environment, not a single-shot generator.
Inspect before changing
Built.at's MCP interface lets an authorized assistant inspect a page's current content and version before editing. That matters because a useful page accumulates details over time: custom copy, links, layout decisions, and scripts. A careful edit changes the intended part while preserving the rest, with version checks to guard against overwriting newer work.
Iteration is the feature
The first version of a website rarely needs to be the last. Try an idea in public, learn what feels wrong, and refine it. Sometimes you'll separate content from styling. Sometimes a tiny single-file page is better. Built.at supports both approaches so architecture can serve the project instead of becoming another barrier.
Pages and paths
A page is content; a path is how people find it.
The building block
A Built.at Page is a published resource that can carry HTML, CSS, JavaScript, and JSON/data. Many Pages are ordinary self-contained documents. Others use independently editable parts or shared presentation layers. A Page can be simple and static or include browser-side interactions, within the platform's supported security model.
Human addresses
A Page can live at an address such as built.at/nate/reading-list. Paths organize content and may allow the same underlying Page to be reached from more than one path. The useful distinction is that you can change a Page without rebuilding the hosting service each time.
Structure without ceremony
A small page needs only a title and content. A larger site may group Pages into a hierarchy and share navigation or styling. There is no reason to create a database table for every paragraph or a separate page for every visual component. Use the simplest structure that makes future edits safe and natural.
Data, APIs, and actions
Pages show things. Structured resources let them change.
When content becomes a collection
An inbox, schedule, directory, or catalog is often better represented as records rather than one growing block of markup. Built.at has D1-backed configured record APIs, which can describe fields, supported operations, and public views. That makes structured updates possible without repeatedly rewriting the surrounding page.
Behavior, not just content
Configured endpoints and workflows can provide controlled operations behind applications. Think of an action as a supported, permission-checked operation rather than a magic ability to execute any program. Trusted capabilities can be composed in supported ways; adding genuinely new platform powers may still require engineering and deployment.
Choose the right level
Use a static Page for an essay. Use JSON or modular Page parts for content you want to edit independently. Use record APIs for ongoing collections or app data. Keep secrets and privileged actions on the server side, never in public page JavaScript.
Under the hood
A conversational front door, with real infrastructure beneath it.
The request path
ChatGPT connects to Built.at through an MCP server. The human-facing operations are See and Do, implemented through the server's existing inspect and act operations. See discovers authorized workspace resources and current state; Do applies validated changes. That makes natural-language editing a controlled interface over actual resources, not a substitute for authorization.
The storage layers
Cloudflare Workers serve the application. D1 stores structured metadata and record-backed application data. R2 stores uploaded assets such as images and audio. Pages, paths, versions, and resource definitions tie these together. The platform takes care of the delivery layer so a normal edit doesn't mean running a local development pipeline.
Versions and boundaries
Version checks help prevent conflicting Page updates; existing Pages and metadata have recovery histories within documented limits. Accounts and authorized collaborators have different scopes. Authentication, credential handling, and tenant isolation are enforced by the service—not by trusting the words of a prompt. These safeguards are part of making creation accessible.
Routes and custom domains
One piece of content should be able to have more than one front door.
The intended model
Imagine building a site at built.at/nate/nathan-puls and serving the same live Page tree at nathanpulse.com. A child Page would appear at nathanpulse.com/about without maintaining a separate copy. Edit the original Page and the change is reflected at both addresses.
What's available and what's planned
Built.at already uses published account paths and supports configurable application endpoints. A general D1-driven host-and-path route registry and deployment-free custom-domain mapping are part of the current development plan, not capabilities this guide claims are already released. A domain still needs ownership verification, DNS, and appropriate TLS/Cloudflare provisioning.
Why this matters
A person with several existing websites should be able to keep their familiar addresses while managing content through the same conversational workflow. The goal is to deploy when the platform gains a genuinely new power, not when someone publishes a page, changes a route, or connects another verified address.
Building with other people
Make room for other hands without handing away the keys.
A shared canvas
Built.at supports collaboration invitations scoped to a particular Page. An invitation can let another authorized account work on that Page while keeping the rest of a workspace separate. The idea is that working together should be as natural as sending a link, with boundaries that remain clear.
Sharing versus access
A public URL lets someone view published material; it does not automatically give them permission to edit, read private records, or invoke owner-only operations. A collaboration invitation is a different kind of link and should be treated deliberately. Revoking access and maintaining version histories help make experimentation safer.
A future community
Over time, there is room for shareable templates, learning in public, community examples, and small projects that grow because people build on each other's ideas. Those are aspirations, not a claim that Built.at already has a full social network or marketplace. The better future is one where making something useful feels less solitary.
A more human internet
Make the hard parts lighter, without taking away the creative ones.
The magic is the handoff
The exciting part is not that AI can generate a webpage. It's that someone can think aloud, ask for a real thing, open it in a browser, and continue the conversation from what they see. When the mechanics fade into the background, people can spend more energy deciding what matters and who it helps.
A useful boundary
AI should do the heavy lifting, not make every decision invisibly. People need the ability to inspect what's been made, correct it, own their content, and understand limitations. Built.at's long-term direction is more freedom through trustworthy infrastructure, not unlimited powers without safeguards.
An invitation
Build a family page. Make an art experiment. Publish an idea for your neighborhood. Invent the tool you wish existed. Start with the simplest version and make it better. The internet becomes more interesting when more people can contribute to it.
