A project's page — one row of tabs: Overview, Edit, Feedback, Versions, Questions, Requests, Kit, Graphics, Brand voice, Plan & brief, Hosting, Settings

Each project card on Projects (aikit.ai/home/projects) shows where its site stands. Live means real visitors reach it: the address is on the client's own domain, that domain points at aiKit, and the last address check got an answer. Not live yet means it has an address that is not the real public site: a temporary aiKit address, a domain that still points at another host, or an address that has not been checked yet (the Hosting tab checks it). Site is down means the last check got no answer or a server error. Draft means it has no address yet. Hover the label to see which one applies.

Under that, a status line says exactly what the project is waiting for, picked from its real records, most important first: the build didn't finish; new requests from the website; Waiting for you to review a change request; Waiting for your reply to a client message; Waiting for you to review answers; Waiting on the build; Waiting for answers to 4 questions (sent Oct 2); draft questions not sent yet; Waiting for you to start the build; Waiting for the client to check a fix; the site is not answering; Waiting on domain setup. Only one line shows, so a project never lists five things at once. The line is a link to the records it counts: questions open the Questions tab, change requests and fixes open Feedback, requests open Requests, a client message opens the editor's chat, and domain lines open Hosting. Each of those is a normal address, so it can be bookmarked or shared with a teammate who has access.

The status menu and the chips above the list group projects as Needs you, Waiting (on the client or on setup), and Working, and the menu also filters by Live, Not live yet, Site is down, and Draft. Search matches the status line too, so typing questions finds every project waiting on answers.

At the top: a picture of the site's home page (click it to open the live site), what kind of project it is and whose it is, its name, where the site stands (Live, Not live yet, Site is down, or Draft; hover it for the reason), its address, and a status line saying exactly what the project is waiting for, which opens the tab that holds those records. Two buttons: Open the editor (the editor window, a chat that changes the site, open beside any tab; see below) and View live site (View the site while it is only on a temporary address). Everything else that changes the site by pointing at it (Pin a spot, Draw, Edit on the live site, Quick edit, Redesign) is on the Edit tab, so it all stays on that tab. On every tab but Overview the header shrinks so the tab's own content starts near the top. Projects in the top bar's breadcrumb goes back to the list.

Under the header is one row of tabs, and it is the only map of the page: every control the project has lives under exactly one tab, with the same name everywhere it appears. Each tab has its own address (?tab=feedback and so on), so a tab can be bookmarked or sent to a teammate. A number on Feedback, Questions, or Requests counts what is waiting. On a phone the row scrolls sideways.

• Overview: where the project stands (build progress, Retry build, Continue to planner, Go live), Needs you for this project, three numbers Needs you doesn't already show (questions out, tools on the site, changes shipped; each opens its tab), Parts of this project, Next steps, and About this project: the goal, Technical details, and other projects for the same client.
• Edit: change the site by pointing at it: the live site in a frame with Desktop, Tablet, and Phone widths, Pin a spot, and Draw; Edit on the live site; Quick edit for a one-line change; and Redesign this site.
• Feedback: every request (pins from the live site, Quick edits, notes from your client) with its full status, from Open to Confirmed. Add feedback in words opens the editor window on its Feedback view.
• Versions: every saved version of the site with Restore, then What shipped, the list of changes that went out, with Copy proof link.
• Questions: discovery questions for your client, drafted, reviewed, sent, and answered.
• Requests: quote requests, messages, bookings, sign-ups, and files that visitors sent through the site's own forms.
• Kit: the tools on the site with this site's numbers and Check it works, what is on the plan but not built yet, Add a tool to this site (opens the Kit Explorer), business tools, and Parts of this project (Add a part opens the parts card on Overview).
• Graphics: the pictures and files this project uses, from the Graphics library. Add from library opens a searchable picker, Upload puts new files straight into this project, and Remove only unlinks a graphic (it stays in the library).
• Brand voice: a summary of the voice this website writes in (its tone mix, reading level, point of view, which voices it is built from, how many writing samples, topics, and rules), with Open in Brand Voice to change it and Write posts and product copy to open Content Kit for this site. With no voice yet, it explains what a voice is and offers Set up a brand voice.
• Plan & brief: the site plan (with Open the plan editor for the full Site plan screen), Brief & rules, and Starting answers (what was filled in when the project was created) with Copy answers.
• Brand voice: how this site's words should sound — tone, audience, words to use and avoid, writing samples, and strategy rules. This website or All of the client's websites chooses where it applies. The Assistant and Content Kit write in this voice.
• Plan & brief: the site plan document (build steps with a Make it button on each, overview and goals, audience, strategy, sitemap, every tool explained, content plan, timeline, decisions, open questions) with Write the plan / Update the plan and Open the plan editor, then Brief & rules, then two folded panels: The original brief (what was filled in when the project was created, with Copy answers) and Build details (the kit checklist, PLAN.md and every file).
• Hosting: Address, Status with Check again, Free preview days left, Versions and backups; then Go live (before launch) or Redeploy (after), and the step-by-step guide to connecting a domain.
• Settings: who can work on it (Owner, Builder, Reviewer), your client's links, How changes go live, Project details (client, what this project is, parent project, category, display name, client email, and what happens when a client submits a request), and Clone this project.

At the bottom of Overview, the project's goal in one line (from the brief), then Technical details: Client (with the category, each a link), Last activity, Hosted at (aiKit hosting on a temporary aiKit address, aiKit hosting on a custom domain, or hosted elsewhere), Domain check (opens the Hosting tab), Started, Free preview (the 90-day window from the project's start, with the end date and days left; after that, hosting moves to a paid yearly plan (coming soon; sites stay live until then), AI edits use your tokens), Last build or deploy, How it started (with the source address where one applies), Build tier (Standard or Premium), Client edit link (whether the access code that powers Edit on the live site and the feedback link exists yet), Feedback mode, and Client link AI (how many of the client's monthly link tokens are left, with Change, which opens the client's page where the owner sets the amount; your own team's edits use your account's tokens and never count here). Last, Linked projects: the parent project, the projects that are part of this one, other projects for the same client, and a link to that client's page.

For a project still on its very first build, a banner sits at the top of Overview showing which stage it's in — Build queued, Importing their current site, or Building the first version — with a spinner, and a note that this runs in the background so it's fine to leave the page; nothing goes live until someone clicks Go live regardless of how far the build has gotten.

If the first build fails instead, the banner switches to "The first build didn't finish," explains that nothing is lost (the brief stays saved below), and offers a "Retry build" button. Either way, a collapsible "Progress log" underneath shows the real build output — open by default when it's failed, so the reason is visible immediately.

The Edit tab shows the live site in a frame. Its toolbar has Desktop, Tablet, and Phone widths, Pin a spot, Draw, a reload button, and Open (a new tab with a fresh, uncached address). Edit on the live site, at the top of the tab, opens the real site full size with editing turned on.

Quick edit, under the preview, is a plain-language box: type a change ("make the phone number bigger"), optionally dictate it or attach a screenshot, and Request change logs it as a real feedback item and immediately asks the AI to make that exact edit to the real code. On a live site the edit is saved as a draft (the live site doesn't change until someone presses Publish on the review screen, unless the owner set the site to publish automatically); on a site that isn't live yet it's simply saved. A status bar tracks progress (working, then done or failed), and This isn't actually fixed reopens it if the fix didn't land. Before launch, Go live is on the Overview tab (and on Hosting); after launch, Redeploy is on the Hosting tab, for a change made by hand in the code, and it refuses while a draft is waiting (publish or discard the draft first).

Clone this project, at the bottom of the Settings tab, copies this project's real files into a brand-new project, for a new client who wants to start from the same foundation. You name the new project and can add any number of distinct "what should be different" change requests one at a time (each its own item, removable individually), plus an optional reference screenshot. Every change you list is applied to the new copy's real code as part of cloning, though the clone isn't public until someone presses Go live on its own page. When it finishes, open it goes straight to the copy's page.

Your client's links, on the Settings tab, lists every link a client uses, each with one copy button, and none of them needs a login. Feedback on the live site (shown once the site is live, and the one to send by default) copies the live address with the feedback and edit overlay turned on, making the project's access code first if it doesn't have one yet. Live site copies the plain address with nothing turned on. Questions page copies the link where your client answers your discovery questions. Updates page copies a link to this project's recent changes, as proof of what shipped. Access code copies the code itself. The card's heading shows the client's email when one is on file.

This is what the Browse-by-client sidebar on the list is actually built from: Client (a dropdown of every client, plus an inline "Or add a new client" name field with its own Add button so you never have to leave this page to create one), What this project is (one kind: Website, Landing page, Online store, App, Admin system, Dashboard, Client portal, Blog / content site, Marketing automation, or Other; the line under the choices says what the picked kind means, with an Add it as a part link for a second product), and whether this project is "Part of a bigger project" — that picker only offers other projects belonging to the same client. Until 2026-10-04 Kind was a multi-select; a project saved with several kinds keeps the first as what it is, and the others show as planned parts on Overview (see Parts of a project, below). A Category and Subcategory pair (free text) is the alternative way to browse the same list. A Display name field overrides what shows on the card when it should differ from the client's own name, and a Client email field makes the project findable by that address later.

For a project that came from an import or transfer, a "Their current site" URL field also appears here — the same source address shown under Technical details.

"When a client submits a request" is a two-way choice. "Straight to work" (the default): the AI starts on your client's request the moment they send it (in the live-site editor, "Ask AI to do it"), the client sees the pin marked Working on it, and nobody on your team approves it first. "I review first": the request waits on the Feedback tab as Open, and nothing changes until a signed-in owner or builder presses "Approve to work"; that approval is what starts the AI. The client's "Ask AI to do it" then saves the pin and tells them "The team reviews each request first, and work starts once they approve it." (Before 2026-10-04 a client's Ask AI started the work even on an I review first project; it no longer does.) Either way, on a live site the finished change waits as a draft for Publish unless How changes go live is set to Publish automatically, and a Reviewer's pins always wait for the team. "Save details" writes everything on this card; a brief "Saved ✓" confirms it went through.

The ? buttons (2026-10-04). Hard fields across the project page, the planner, and Detailed setup carry a small ? button: When a client submits a request, How changes go live, What this project is, Part of a bigger project, Display name, Category and subcategory, Client email, Their current site, Who can work on it, Your client's links, the four Hosting tiles, the Questions settings, the Requests list and its client link, Parts of this project, and the planner's Planning, First build, Voice, Pick a look, Their current site, and Kind. Click or tap it (or Tab to it and press Enter) to read a short plain answer, with Learn more pointing at the matching part of this Help Center where there is one. Esc, the ? again, or a click anywhere else closes it.

Any project can grow after it exists. On the Kit tab, Add a tool to this site opens the Kit Explorer for tools that go on the site (pages, forms, galleries, store, booking, SEO), and the Business tools kit card's Add a business tool opens the kit browser limited to the business-tools categories (marketing automation, invoicing and billing, customer records, quotes and proposals, staff tools, reporting, integrations, loyalty, support). Picking a business tool does two things at once: it is added to this project's plan (it appears in the list on that card and in the Project brief on the Plan & brief tab), and a work item is filed in the Feedback tab as "Our team", so it shows as Waiting on us, appears on the Feedback page across projects, and can be run with "Fix with AI" or discussed like any other request. Picking the same module twice is refused with a note that it's already on the project.

The "Parts of this project" card on the Kit tab lists this project's parts with links and has an Add a part button that opens the parts card on Overview (see below).

One client project often needs more than one product: a website plus an online store, or a website plus a client portal where customers log in. Each of those is a part. A part is a full project of its own, with its own plan, first build, address, versions, requests, and status, linked under the main project. The parts share the client, and the client's Brief & rules, so nothing gets asked twice.

The Parts of this project card sits on Overview, under Needs you, on the main project and on every part. It lists the main part first, then each part: its kind, its name (a link to its own page), Main part or Part, "you are here" on the one you're looking at, its address once it's live, and where it stands, colored by meaning: Live (green), Being built (blue), Build failed (red), Questions first (amber), or Not live yet. The ? beside the heading explains parts in two sentences.

"+ Add a part" folds open "What should the new part be?": one card per kind, each with an icon and a one-line description, leaving out kinds this project already has or has planned. Picking one opens the planner with the client and the main project already filled in and the kind set; the heading reads, for example, "Add an online store to Main website". The planner is told it is planning only that part, so the plan covers the new store's pages and tools without re-planning the website. Build this project creates the part under the main project; Save & ask questions first creates it on hold, the same as any new project.

A project saved before 2026-10-04 with several kinds ticked keeps the first one as what it is. Each other kind with no part yet shows as a dashed row ("Not started yet, Planned for this project") with Plan this part (opens the planner for that kind) and Not needed (removes it from the project's saved kinds; only on the main project).

Only the main project's owner, its builders, or an aiKit admin can add a part; a reviewer can open the parts but not add one. A part can also be moved under a project, or back to the top level, with Part of a bigger project in Settings. Parts are one level deep: that list offers only main projects, a project that already has parts stays a main project (the picker is turned off with a note saying so), and the planner's Detailed setup link keeps the part's main project, kind, and client.

Any project can grow after it exists. On the Kit tab, Add a tool to this site opens the Kit Explorer for tools that go on the site (pages, forms, galleries, store, booking, SEO), and the Business tools kit card's Add a business tool opens the kit browser limited to the business-tools categories (marketing automation, invoicing and billing, customer records, quotes and proposals, staff tools, reporting, integrations, loyalty, support). Picking a tool does two things at once: it is added to this project's plan (it appears on the Kit tab as a Planned card with View in the Kit, In the plan and Work item links, in the site plan document's Modules and tools section with what it does for this business, and in The original brief with a Planned badge), and a work item is filed in the Feedback tab as "Our team", so it shows as Waiting on us, appears on the Feedback page across projects, and can be run with "Fix with AI" or discussed like any other request. Picking the same module twice is refused with a note that it's already on the project.

"Side projects" is for a separate project for the same client that belongs under this one — an app, an admin system, marketing automation, another site. The buttons are one per kind (the current project's own kind is left out). Each opens the New project wizard with the client, the parent project, and the kind already filled in, so the wizard starts at the project name. Existing side projects are listed above the buttons with links to their own pages; they also show as sub-projects in the Browse-by-client sidebar.

Folded under Brief & rules. For any project created through the wizard (or otherwise carrying a saved brief), this card shows every answer given during Create-a-project: the goal, audience, what to keep, brand assets and attachments, current domain, deadline, and any other notes — each rendered under its real question label, with attachments shown inline (an image thumbnail, or a download link for anything else). Beneath the answers, the Site kit and Business tools kit picks each list their module name, a Built or Planned badge, a View in the Kit link to that tool's page in the Kit Explorer, and the note on what should be different about it, and a final line states the hosting choice made in the wizard ("On aiKit (default)" or "Client hosts it themselves").

"Copy answers" copies the whole thing as plain text — the exact same format the wizard's own "Copy plan" produces — ready to paste anywhere.

The Plan & brief tab opens on the project's site plan, written the way a good agency hands a client their plan. Under the cover (the business name, a two-line overview, and four facts: pages built and planned, tools live and planned, open questions, and whether the site is live) a Contents list jumps to the numbered sections: Build steps first (staff only), then the nine plan sections. On a phone the Contents become a row of buttons you swipe sideways.

Build steps turn the plan into the things to make, in order, each with a Make it button that opens the right aiKit tool already filled in from the plan. A Site Plan covers websites, admin systems, modules and the builds that go with them; content and marketing planning will come as their own tools. The steps: Build the website (or app, store, admin system) when nothing is built yet, which opens the planner with the plan in its box; Add the <name> page for every page on the plan; Add to the site: <tool> for every tool on the site, plus anything the brief asked for that isn't in the Kit (each opens the project's Assistant with the request written out, so you read it and press Send); Build an admin system, a client portal, or a dashboard when the plan has business tools that belong in one, or the project lists that kind as a part (it opens the planner for a new part linked to this project, with the tools it needs written in); Set the brand voice (opens Brand Voice with this project picked); Write the first blog posts when the plan has a blog page (opens Content Kit writing for this project); and Go live (opens the Hosting tab). Page and tool steps wait with "Made in the first build" until the site has files.

Each step checks itself off when aiKit can see the result: the page or tool measured on the site, the first build finished, the part created, a voice saved for the project or its client, a post written for the project, or the site live. Those show "Done. aiKit saw it in the project." and a link to the result (the page's details, the part, the voice, or the live site). Steps aiKit can't see, such as a custom feature, have a box you press to check them off, and press again to put back; it shows who checked it and when. The bar at the top counts what's done, Next jumps to the first step you can make, and once more than four are done they fold under Show the done steps. Business tools that aren't built yet (marketing ones, for now) sit at the end marked Coming next, with Request this tool, which sends the request to the aiKit team. Every step has its own link (#step-…), and the list reads itself again when you come back to the tab.

01 Overview and goals: each goal with how it will be measured. 02 Audience: who the site is for and what each group needs to find fast. 03 Strategy: the positioning line, how the site earns search traffic with the search phrases it targets, and how visitors become customers. 04 Sitemap: every main page with its address, its job, an In menu tag, and a Built or Planned pill; groups of pages (for example twenty town pages under a service-area page) fold under their parent as "20 pages under it". 05 Modules and tools: one card per tool on the plan, split into tools on the site and business tools alongside it, each with its status (Planned, Built or Live, plus an Under review tag with the reason when the plan judges a planned tool a poor fit for this business), the catalog's description, What it does for this business, How it's set up, the pages it lives on, when it was added and by whom, and View in the Kit, which opens that tool's page in the Kit Explorer. A business tool that isn't set up yet says "Not set up yet" rather than talking about the site. 06 Content plan: content to produce, the questions the FAQ answers, photos to gather, the Content guidelines from Brief & rules, and the brand voice. 07 Timeline: three to five phases with a time window and Done, In progress or Up next; only the first unfinished phase is In progress. 08 Decisions: what's settled, mostly turned from the client's own answers into plain decisions instead of a list of questions and answers. 09 Open questions: only what's still unanswered, with a link to the Questions tab.

Where it comes from: the measured site decides what exists (which pages and tools are really built), the brief and its kit picks decide what's planned, and the client's answers and Brief & rules fill in decisions and guidelines. The strategy writing (overview, goals, positioning, search, conversion, what each tool does, phases, decisions) is written when you press Write the plan, in about 30 seconds; opening the tab never starts it, so viewing the plan never uses AI or your daily limit. Until then the plan shows what is measured on the site, the brief and the kit picks, with a note that the written plan is not made yet. Build steps list a page as to add only when no page on the site is that page: the home page written as "/ (index.html)" in the plan, or "Request a Repair" for the request form's page at /request-service/, count as built. When the brief, the kit picks, the site or the client's answers change, a note reads "The brief or the site changed since this was written" and Update the plan turns blue; press it to rewrite. A tool you add is in the document right away, before any rewrite.

Open the plan editor opens the full Site plan screen (health, page drawer, history, editing). Build details, folded at the bottom of the tab, keeps the build's kit checklist ("N of M built" with the file each module lives in), the raw PLAN.md, and the project's real file list with a read-only viewer.

When a project's Site kit includes the "Quote or Estimate Request Form," the build doesn't ask the AI to invent a form: aiKit's own tested module renders the Get a quote page (its fields, urgency choices, and whether it asks for an address or photos are filled from the brief; contact details are only ever real ones from the brief or the mirrored site, never invented), and the AI is only told to link to it from the navigation. After the build, the engine re-generates that page with the site's real header, footer, and stylesheet so the form itself can't have been broken.

On the live site, pressing Send stores the request on aiKit immediately — it works as a plain form with no JavaScript, on any host, with no email setup. The project's owner and staff hear about it at once on the bell (and by email, by each person's choice in Settings → Notifications), with a link straight to that one request; see the Notifications guide. The Requests tab lists each one newest first: name, phone (tap to call) and email, the service and how soon, the address if asked, the message, and which page it came from. A status dropdown (New, Contacted, Won, Closed) and a private note box per request keep the team in step; the tab badge and the list row's "N new requests" link both count what's still New. Photos are stored with the request (the form shrinks phone photos before sending, up to four per request) and show as thumbnails on the row — click one to open it full size. Two more tested modules land on the same tab: the Contact Form That Routes Right (tagged "Message" with the topic the visitor chose) and the Book online (tagged "Booking" with the requested day and time, shown in the business's own time zone). The booking page offers times in the business's time zone, which the build reads from the address or city in your brief; a visitor in another time zone also sees their own local time under each slot. A booking holds its whole length (the service's minutes, plus any buffer the business keeps between jobs) on the live site until it's marked Closed, so nothing can be booked on top of it, and the booking page refuses a slot someone else just took, even when two people send at the same moment. The time zone, hours, and buffer come from your brief; mention them there (for example "we're in Denver, keep 15 minutes between jobs") before the site is built. A new request of any kind flips the project to "Waiting on us" on the list. The client can see the same leads themselves: "Copy client link" at the top of the tab gives a page (aikit.ai/p/<project>/requests, also linked from their Recent updates page) that asks for the project's access code — the same code they use to leave feedback — and then shows every request with contact details, photos, and a status they can change, but never your private team notes. Every new project gets its access code when it's created; an older project without one keeps that page closed to everyone but its team until a code exists (copying any client link makes one).

Three more modules post to the same tab (added 2026-10-02): Lead capture (tagged "Lead": a first name, an email, an optional mobile, the free offer they signed up for if the page has one, and "Consent to be contacted: yes", because the form refuses a sign-up without the consent box ticked), Send us your file (tagged "File": up to 3 files, 4 MB together, as PDF, AI, EPS, SVG, PNG, JPG, TIFF or PSD, with what the file is and what it's for; the row shows "File received" with each file's name and size, and the owner, staff, and admins can download it; a reviewer sees that a file arrived but can't open it; files always download rather than open in the browser, and they belong to that one project only), and the Quote builder (tagged "Quote builder": the product, quantity, each option, the turnaround, and the estimated range the visitor saw, or "No estimate shown" when the owner hasn't entered prices, since the page never shows a price the owner didn't set).

Print file check on upload (added 2026-10-12): every print file that comes in through Send us your file (PDF, AI saved with PDF content, EPS, PNG, JPG, TIFF, PSD) is checked automatically right after the customer presses Send. The customer gets their "File received" answer at once and never waits for the check, and never sees its result: it is only for the owner and staff. Under each file on the Requests row, "Checking this file for print…" shows for a few seconds, then the result: a badge (Looks print-ready, Worth a look, or Must fix) with up to five plain lines. Size: the finished size and page size for a PDF (from its own trim box or crop marks, or the page when no trim is marked), or the pixel size for a picture. Bleed: whether color runs past the trim by enough (1/8 in is the usual), "Nothing runs to the page edge, so no bleed is needed," or, when no trim is marked, whether the page size already includes bleed or what to confirm with the customer. Resolution: the lowest photo resolution at its printed size (under 150 ppi is a must-fix, under 250 worth a look), or for a picture how big it prints sharp at 300 ppi. Fonts: whether every font is embedded, naming any that aren't. Colors: CMYK, grayscale, spot colors, or RGB (worth a look, since bright blues and greens can print duller). The check is code, not AI: it measures the file and costs nothing. SVG files aren't checked, and a file that can't be read (for example an Illustrator file saved without PDF content) gets a must-fix line saying why. Fix it in Printer’s Helper (Open in Printer’s Helper when it looks print-ready) opens Printer’s Helper with the customer's file already added and a starting request ("Check this customer's file for print and fix what it needs.") you can change; nothing runs and no job is used until you press Start. Check again runs the check once more, for example if it shows "The check didn't finish"; files sent before this was added show "Not checked for print yet" with Check this file. Reviewers see that a file arrived but not these buttons.

Check it works: on each tool's card on the project's Kit tab, the owner or staff can press "Check it works". aiKit sends one test entry through that module's real form on the site, exactly as a visitor's browser would, and shows "Tested — working" with the time, or a plain sentence saying what failed (for example, the form isn't on the page any more, or the inbox refused it). The last result stays on the card for everyone on the team; reviewers see it but can't run a check. A test entry uses an example.com address that never receives mail, is saved on the Requests tab marked "Test", stays hidden unless you press "Show test entries", is never counted in New, Needs you, or the project list, never holds a booking slot, never appears on the client's leads page, and never sends any email or notification.

Tools → Bookings (aikit.ai/tools/bookings, or Open the Bookings calendar on a project's Kit tab) is where you run appointments from a site's Book online page. Pick the website at the top if you have more than one. The website picker, Block time and New booking sit on the title row, on the right. Six tiles count Today, Next 7 days, Needs confirming, Waitlist, No-shows and Canceled; press any tile to see exactly those bookings. Until the first booking ever arrives, one quiet line stands in for the tiles so the setup banner and the calendar come first. When every tile would read 0 (nothing today, this week, or waiting on you), the tiles fold into one All clear line with a See all bookings button, so the calendar stays on top. Every view, filter and open booking is in the address, so you can bookmark or share it with your team.

Calendar shows Day, Week or Month in the business's time zone. Each booking is a colored block with the customer's name and service (blue Confirmed, striped amber Needs confirming, green Completed, red No-show); press it to open it. Open hours are white, closed days and blocked time are striped. In Day view each team member gets a column. Press an empty hour to add a booking at that time, and press a blocked stretch to open that time again.

Bookings is the list: search by name, email, phone or service, and filter by Upcoming, Today, Next 7 days, Needs confirming, Waitlist, Past, No-shows, Canceled or Everything (each with its count). Customers lists each person once with their next visit, completed visits, money from completed visits and no-shows; press a name anywhere to see their whole history.

Opening a booking shows the customer's phone and email (tap to call or write), who it's with, extras, price, their answers to your questions and their note. Buttons set Confirm (or Confirmed), Completed and No-show. Move to another time lists the open times; Cancel this booking asks for an optional reason the customer sees. Email the customer about changes is on by default. A deposit shows as a checkbox you tick when it's paid; nothing is charged online. You can copy the customer's change-or-cancel link or email the confirmation again.

New booking adds one by hand: the customer, service, who it's with, extras, spots for a class, a day and an open time (or a time outside the open times on purpose), Repeat weekly or every 2 or 4 weeks, and Confirmed or Needs confirming. Block time keeps whole days or part of a day off the booking page, for everyone or one person, with a private note.

Settings is what the booking page follows, saved with one button and used by the page at once: confirm right away or confirm each one; services with length, price (or "from" a price), description (Suggest a description writes one from the service name, and you edit it), a buffer before and after, people per time for classes, who does it, extras with added minutes and price, and questions to ask (short answer, longer answer, pick one, yes or no; required or not); your team and the days each person works; weekly hours with breaks; closed days; start times every 10 to 60 minutes, least notice, furthest ahead and the most bookings in a day; a waitlist for full days; how late customers can change or cancel online, a cancellation and missed-appointment policy, and the reminder email; deposits (a set amount or a share of the price, paid by card on the customer's booking page or however you tell customers; see below); After the visit (the review ask); and Common questions, which Write answers for me drafts only from these settings. Until you save once, the screen starts from what your booking page already shows, and the page keeps working as it was built.

Share & sync has your booking link, a QR code to download as an SVG for print, embed code that puts the booking card on any other page, and a calendar address to subscribe to in Google Calendar, Apple Calendar or Outlook (it lists every booking and updates about every 15 minutes; keep it private, and make a new address if it gets shared). Two-way sync, where your own Google or Outlook appointments close times on the booking page, is the next step and isn't switched on yet; use Block time for those until then.

Your look (in Settings) puts your logo, a wide cover picture, your main color (the band at the top) and your button color on the booking page and on each customer's own booking page; a small sample shows how it will look, and a light button color is darkened where it's used as text so it stays readable. Each team member and each service can have a photo too. Pictures are shrunk in your browser before they upload (JPG, PNG or WebP; up to 1.5 MB each after shrinking; SVG files aren't accepted), and pictures no saved setting uses are removed after a day. Leave a color empty to keep your website's own.

Deposits by card: choose By card, right after booking and the customer gets a Pay the deposit button on the thank-you screen and on their own booking page, which opens a short card form right on that page (card number, expiry, CVV, ZIP). The card goes straight to Authorize.net through its secure form; aiKit never sees the number. The booking then shows "paid by card". This runs in TEST mode only (no real money moves) and needs card deposits switched on by your aiKit admin; until then Settings says so and you can still choose I'll tell them how and tick Paid yourself. Giving a card deposit back after a no-show voids it the same day, or refunds it to the card after it settles. When you mark a booking No-show (only possible once the visit has started) and its deposit was paid, aiKit offers Keep the deposit (your policy, if Keep the deposit when someone doesn't show is on) or give it back (a card deposit is refunded; one paid another way is marked as given back).

After the visit: with Ask for a review after a Completed visit on, marking a visit Completed adds the customer to your Reviews tool, and the review email goes out after the delay you pick (2 hours unless you change it). Everyone gets the same ask, page and Google link; nothing depends on how the visit went, and a customer is only asked once. The Reviews tool must be set up first (your wording and Google link), and the email needs email set up for your account.

Text reminders: turn on Text reminders too (Policy & reminders) and customers see a "Text me a reminder before my visit. Message and data rates may apply. Reply STOP to opt out." box when they book; only those who tick it get a text, 2 to 48 hours before. Replying STOP stops texts from every business on aiKit; START turns them back on. Each text and its cost is logged. Texting needs a texting account (Twilio) connected by your aiKit admin; until then the box doesn't appear and no texts go out.

What customers get: on the booking page they pick a service (with price, description and extras), who they'd like if you have a team, a day on a month calendar and a time grouped into morning, afternoon and evening (their own time shows too when they're in another time zone), then their details and your questions. Full days offer a waitlist, and services you allow can repeat. After booking they see Add to Google Calendar and an Apple or Outlook file. Their email has the details, calendar links and their own page (aikit.ai/b/…) to change the time or cancel up to your cut-off, and a reminder arrives before the visit. Every rule is checked again on aiKit when they press the button, so two people can never take the same time. Booking emails go out once email is set up for your account.

Who can work on it, on the Settings tab, is a separate list of real aiKit accounts with access to this specific project — distinct from the shared access code clients use on the live feedback overlay. The owner can't be removed; anyone else can. Adding someone takes their email — they need their own free aiKit account first (created the same way as any /start/classic account) before they can be added here.

Next to the email box, pick what they can do. "Builder: edit and publish" is a full teammate: chat edits, fixes, builds, going live, settings. "Reviewer: view, comment, approve" can open the project and see everything on it, leave pins and replies, and approve a finished fix (Confirm) or send it back (Reopen), but can never start an AI edit, build, restore a version, change settings, or publish. A reviewer never sees the project's client access code either. Each person's role shows as a tag on their row. To give someone every site for one client at once, use People with access on that client's page (see the Clients guide).

Every item — a pin dropped on the live site, or a Quick edit request — carries the same lifecycle: Open → In progress → Fixed, awaiting client review → Confirmed, with a separate Reopened state if a "fixed" item turns out not to be. "Waiting on us" means Open or In progress; "Waiting on client" means it's marked fixed and they haven't confirmed yet. A "?" button expands a full explanation of every action inline, right on the tab.

Each item shows the message, what it's about (the element it was pinned to, if any), an attached screenshot if there is one, a status pill, and a role tag — "Client" or "Our team" — making clear who actually filed each request. Available actions depend on its current status: in review-first mode, an open item shows "Approve to work" first; from Open/Reopened/Approved/In progress, "Fix with AI" sends it straight to the AI editor, which edits the real code, redeploys, and marks it fixed with the live link as proof — the normal path. "Start work by hand" marks it in progress without the AI, for a change made directly in code (pair with Redeploy on the Hosting tab once it's live, then Mark fixed). "Mark fixed" asks for a note or URL proving it's done. A fixed item can be "Confirmed on client's behalf," and anything can be "Reopened" if it isn't actually right.

Under each item, a "Work done" list shows every shipped change tied to it (with a link to view the live page and a link to the Versions tab) plus its verification note or URL if one was given. A "Discuss" toggle opens a threaded reply conversation on that one item — the client sees the exact same thread from their own link.

Opening this tab from a link on the cross-project Feedback page (or anywhere else with a #fb-<id> link) scrolls straight to that item and briefly highlights it, so following a link from elsewhere never leaves you hunting through a long list.

Edit on the live site, at the top of the Edit tab, opens the real site in a new tab with the editor turned on (the project's access code rides in the link once and is remembered for that tab): an "Edit with aiKit" button in the corner opens the editor beside the page with Chat, Feedback, and What changed (the list of changes; restoring is staff-only, on the Versions tab), pins land on the exact element you click, Draw a line marks any area, and a landed change reloads the page. Public visitors never see it.

The Edit tab shows the live site in a frame once the project is live (before that it says so, and Quick edit and the editor already work on the files). Above it: Desktop / Tablet / Phone widths (the frame narrows to 768px or 390px), Pin a spot for AI feedback on an exact place, Draw for an area, a reload button, and Open in a new tab with a fresh, uncached address. When the editor window is expanded to a split screen, this same preview moves beside the chat. The first time a built project is opened, a note on the Overview tab says the first build is a starting point, not the finished site, with a Start improving it button that opens the editor; Got it hides it.

Open the editor, in the project page's header, opens the editor window (a row's "Edit" quick tool on the classic list, or any link ending in ?assistant=chat, opens it directly). Its views are Chat, Feedback, Versions, Brief & rules, and Kit; the same things also have their own tabs on the project page, at full width, and the window is for using them beside the chat. It opens a panel docked to the right (drag its left edge to resize it) or, with the expand button in its header, a split screen with the live site on the left and the panel on the right. Esc or the × closes it and focus returns to where you were.

Chat is a plain conversation about the whole site. Type or dictate, attach files with the paperclip, press Enter. Attach pictures and screenshots, or documents (PDF, Word .doc or .docx, Excel .xls or .xlsx, CSV, or plain text). Signed in as a member of the project, you can attach up to 10 files to a message, 50 MB each and 150 MB together: each file uploads straight to aiKit's editing server the moment you pick it, its chip shows a progress bar ("Uploading 40%"), and Send reads "Uploading…" until every file is done. A client using the site's access code without signing in can attach up to 4 files, 4.5 MB each and about 3 MB together. Each file shows as a chip with its name, type (Picture, PDF, Word, Excel, CSV, Text) and size, with an × to remove it (or stop its upload) before sending; a file that didn't upload says why on its chip. A file you attach but never send is deleted after 24 hours; files you send are kept 30 days. The ? beside the paperclip sums this up. A document is how to hand over a menu, price list, or brochure: "Put this menu on the Menu page" works. The AI reads the document's words (Word and Excel files are converted to PDF on aiKit's server first) and looks at pictures of the first pages of a PDF or Word file for layout and photos; it copies names and prices exactly as written and never invents items. It reads the file; it can't yet save a copy of the file itself onto the site, so a request like "add this PDF as a download button" can't be done from chat today. Every file is checked by what it really contains, not just its name: programs, Office files with macros, and a file whose contents don't match its name are refused with the reason, and nothing is sent. The conversation shows the file names under your message. Signed-in staff also get commands: the ∞ button beside the microphone opens "Your rules and commands", where Standing rules (a few lines that load into every project you chat with, on every request; the Brief & rules wins if they disagree), the ∞ command (what runs when a message ends with ∞; a built-in version checks the whole site for consistency and reports what changed until you write your own), and Slash commands (a short name and what it does, up to 40) are kept. Type / in the box to see your commands; pick one, or press Enter on the top match, and it expands into the box so you can add to it before sending. "+ ∞" adds the symbol to the end of what you typed. The client's own chat on the live site has no commands. A question gets an answer; a request for a change is made in the real code by the same edit loop the rest of aiKit uses, and while it works the panel shows a working card instead of a spinner: a clock, a plain-language stage ("Small changes usually land in under a minute"), the steps already done ("Searched the site for (555)", "Edited contact/index.html"), and the current step. For a change that appears on several pages (a phone number, hours, an address) the assistant searches the site and edits each spot in place rather than rewriting whole pages, so most changes land in under a minute. Sending stops the microphone if it was on. Only one request runs at a time per project; a second send while one is running is told to wait. If the project is live, the change deploys and the preview above reloads; if not, it is saved to the code until Go live. Every change becomes a version (see Versions). The assistant reads the project's Brief & rules before every reply and follows what it says. The chip in the panel's header shows the account's tokens left today (or this month when the plan has no daily amount), read from the same check every edit goes through; when that check would refuse an edit it reads tokens used up for today (or this month) and a card in the chat explains it and stays on screen. Hover the chip for the plan and this project's edit count. Every change and answer uses your account's tokens. Changes a client asks for from their own link (the access code) also stop at that client's monthly token amount, set on the client's page (2,000 to start); when it's used, the client's chat says so and offers "Ask the owner for more", which sends you a request. Your own team's edits never count against it. Paid edits are not rationed by day.

The Feedback view (it was called Pins until 2026-10-02) is AI feedback on an exact spot, and Draw is the same for an area: press "Draw" above the preview (or "Draw a line" on the Feedback view, or in the panel on the live site) and drag a straight line across anything with the mouse or a finger; the line pauses so you can Undo and redraw it if it's not quite right, or "Use this area →" to confirm it. The line's (padded) bounding box becomes the pin's target area, the AI is told which element sits under it and how big the area is, and on the live site an orange line stays where you drew. "Ask AI to do it" really runs the change (2026-09-11): the pin turns to Working on it, the AI edits the real code and redeploys, and the pin turns to Fixed with a View fix link to the live page; if it could not be done, the pin goes back to open with the reason in its history (the engine itself writes that, so a long edit can never leave a pin on Working on it; after 15 minutes without a result the list shows Taking longer than expected with an Ask AI again button). Click "Pin a spot" above the live preview, click the place on the site, describe the change, and choose "Ask AI to do it" (the change is made and the request is marked Fixed, awaiting review, with a link to the live result) or "Save for later" (a normal open request). Open requests from the client show here too, each with its own "Ask AI to do it". Feedback in words (2026-09-11): paste what the client said (an email, call notes, a transcript), choose From the client or My own notes, and press Turn into requests: the AI splits the text into one open request per change, each aimed at the page it belongs to, and the original text is kept under Notes in Brief & rules. Nothing on the site changes at that point; each request still runs through Ask AI, turns to Working on it, and ends as Fixed with a View fix link, so you see every change start and finish. Save as a note skips the split and keeps the text as background only. Splitting costs tokens (it shows as "split" on the Usage page) but never an edit.

Redesign this site (2026-09-12, staff only) is a whole-site visual redesign, not a feature request: press "Draft a direction" under Redesign this site at the bottom of the project's Edit tab (or on the editor window's Feedback view) and the AI picks a small set of your approved reference sites — real pages you starred as design references, matched to this project's industry — reads their look and feel, and writes one concrete art-direction brief: a named color palette with real hex values, a type pairing, the section rhythm, several named signature sections, and rules for motion and icons/illustration. "Choose references" opens the same reference-gallery picker the planner uses: search or filter by industry, pick up to 6 sites yourself instead of the automatic match, or leave none picked to keep the auto-match. Read the brief, edit any line, or press "Try different references" to redraft. "Run redesign" sends that brief through the same edit loop as any other change — every page, not just the home page — and costs more than a single edit and usually takes 7-11 minutes, both stated up front on the button. While it runs the card shows a live elapsed clock with an honest, plain-language description of what's happening at that point, not just a spinner; a past run is listed underneath with the brief it used, the reference sites it was grounded in, and a before/after screenshot of the homepage once it lands, so you can see the actual difference rather than take the AI's word for it.

Versions lists the site's versions, newest first: the Original (recorded before the first change), the first build, each chat edit, each pin fix, and each restore, with who made it, when, and which files changed. aiKit keeps the Original and the newest 10; when a new change arrives and there are already 10, the oldest one after the Original is removed for good, unless it is starred, live, or a waiting draft. "Star" on a version keeps it however old (up to 20 starred per project); "Unstar" lets the usual rule tidy it away on a later change. "Restore" on any older version asks once, saves the current state as "Before restoring", puts the older files back, and records the restore as a new version, so a restore is itself undoable. On a live site that waits for Publish, Restore offers two choices: "Restore as a draft" (the older files come back as a draft you review and publish like any change) and "Restore and publish" (the one-click rollback: the older version goes live at once and the publish is recorded with your name). On a site that publishes automatically, or one that isn't live yet, a restore works as before and redeploys if the site is live. Each version carries a pill: "Live now" is what visitors see, "Draft" is waiting for review, "Was live" was published before, "Went out in a publish" was part of a later publish, and "Discarded" was thrown away. Every version except the live one and the newest draft has Restore, including earlier drafts and the automatic "Before restoring" backups, so you can undo a restore. The live version, a waiting draft, and starred versions are never removed by the automatic clean-up.

Brief & rules is the living document the AI reads on every build and edit. Sections: Business facts, Brand, Rules & instructions, Content guidelines, Approved styles, Decisions, Notes, Learned. Notes holds plain notes from calls, meetings, and emails, plus feedback pasted on the Feedback view; the AI reads them as background and nothing under Notes changes the site by itself. Add an entry in plain words: choose the section, choose whether it applies to every project for this client or only this one, type or dictate, Add. When the assistant learns something durable in conversation it files it under Learned as unconfirmed; the panel asks you to Confirm or Remove each one, and only confirmed entries count as the owner's own statement.

Kit is the catalog of self-contained modules. "Built" shows the tested modules the engine renders as real pages (Get a Quote / Request Service is the headline; Contact form; Book online), each with a plain summary, features, why it matters, how it customizes, a Preview that renders the real template with sample data, and a customization-notes box. "Whole catalog" adds the planned modules that become work items. "Add to this project" records the pick on the project's plan and files a work item, the same as the Kit tab's add buttons. The same catalog also has its own full-page Kit Explorer (at /projects/&lt;id&gt;/kit, or browse-only at /projects/kit with no project yet — see "The Kit: browsing, previews, and adding a module") for a deeper, illustrated browse: categories, a full detailed preview of every module, and a fuller add panel with suggested customizations, your own notes and attachments, and "Add to plan" vs "Add and build now."

Questions (2026-09-14) is for the discovery questions a new OR existing client should answer, separate from Feedback (requests about something already built). It is a tab of the project page at full width (since 2026-10-02; the old /projects/<project>/questions address opens it), reached from the tab row, Needs you, Next steps, or a row's More ▾ menu on the classic projects list, since drafting and reviewing a real batch of questions needs more room than a side panel gives it.

Notes for the questions (it was called The brief) is a running, saved thread, not a single box you type into and lose: add one note at a time (type or Dictate, then "+ Add note"), each lands as its own entry with a timestamp and a remove button, and it's all there again next time you open the page — nothing lives only in the browser tab. Come back tomorrow, or in a week, and add more; it all counts.

When there's enough, press "Draft questions from everything above": the AI reads the whole thread, plus anything already confirmed in Brief & rules so it never re-asks what's on file, and proposes a set of specific questions — usually around 15, more than a short marketing-site questionnaire would need, because the goal is real detail, not a token gesture. Each question is either a fill-in question or, when the real answers genuinely form a short closed set (a budget band, a yes/no/maybe, picking between a few named directions), a multiple-choice question with 3-6 AI-drafted options; a multiple-choice question also gets "allow more than one" when more than one option can genuinely apply at once (which of these features do you want, which services do you offer), so the client checks boxes instead of being forced to a single pick. If the project sounds like more than a marketing site — a system, app, or anything meant to help run the business day to day — the AI leans into specific, creative multiple-choice questions about real operational features (automated review requests, digital invoicing, instant quotes, scheduling, follow-ups, reporting) grounded in what you actually wrote, not a generic checklist. It never names or alludes to any of your OTHER clients or projects, even as an example — every question stands on its own as if this were the only client you'd ever worked with.

Nothing is saved yet — each proposed question shows with a checkbox, its own editable text, and a Fill in / Multiple choice switch; a multiple-choice question's options are each their own editable line with a remove button, "+ Add option", and an "allow more than one" checkbox. "+ Add my own question" adds a blank fill-in one for you to type yourself — write it (or switch it to Multiple choice) and press "✨ Suggest options" (or "↻ Re-suggest options" to try again) to have the AI propose 3-6 realistic options for that exact question, so you're never stuck typing "Option 1, Option 2" by hand. Uncheck, edit, retype an option, switch types, or delete anything before sending.

"Send N to the client" is the only thing that actually creates the questions — it mints the project's access code if it doesn't have one yet and gives you one link ("Copy link", or "Email it", which opens your own email app with the client's address and the link already filled in; aiKit itself never sends the email). Sending clears the review list and shows a confirmation card with a summary of what went out — the page scrolls down to "Sent so far" so it's clear the questions are saved, not lost, since that same list is where they now live. The client opens that link with no account of their own, picks an option (or checks several, for an "allow more than one" question), or types an answer, and can leave the rest for later. Once they submit, each answer is filed into Brief & rules under Decisions as its own entry (the question's point, then the answer; unanswered questions are left out) so the AI has them on every future edit and the site plan turns them into its Decisions section, and the AI privately checks whether a genuine follow-up is worth asking — most rounds get none, but if an answer is vague or two answers conflict, one to three sharp follow-up questions appear on that same link automatically, no new link needed, capped after a couple of rounds so it can't turn into an endless back-and-forth.

Come back to this page any time — before the client has answered everything, or long after — and send another round with the same Draft-then-review flow; it just joins the list on the same link, nothing new to send. The Sent so far list shows every round, each question with its real answer (and its options, for a multiple-choice one, plus a note when more than one was allowed) or a "Waiting for an answer" pill, refreshing on its own while anything in the newest round is still open. "Export answers" downloads every round's questions and answers as one plain-text file — meant to paste straight into a fresh Claude or Claude Code session to start building, not to open in another tool; the same Q&A also stays on the project's own Brief & rules permanently, so the export is a convenience copy, not the only record. The export also lists every photo the client uploaded, with its note, tag, and link.

Drafts (2026-09-30). A questionnaire can also be loaded as drafts, questions saved on the project but not sent. They appear in their own "Drafts, not sent yet" card with a count, numbered in the order the client will see them. Each draft shows its section heading (if it starts a new section), the question, its translation, its tip, and for a multiple-choice one whether the client picks one or any, plus the choices. Edit opens it in place: the question, the tip under it, and the section heading above it, each in both languages side by side (stacked on a phone); Fill in or Multiple choice; each option in both languages with a remove button, "+ Add option", and "Client can select more than one". The ↑ and ↓ buttons move a draft up or down, the × deletes it (it asks "Delete N?" right in the row, with Delete and Keep), and "+ Add a draft question" adds a new one at the end with the same editor. The client sees none of this. Sending drafts is three steps, so a client link never goes out showing nothing. 1 Review: while drafts are unsent, the top of the Questions page says so in a large orange box ("33 questions not sent yet. David sees nothing until you preview and send.") with one button, "Preview what David will see"; the bottom of the drafts card has "Next: preview". There is no copy-link or email control at this step. 2 Preview: opens the client's own link in the same tab. Because you're signed in to the project, you see the full page exactly as the client will get it (intro, language switch, every question, tips, choices, and the photos and files section) under a bar with only "← Back to edit" and "Looks good, send it". Answers and uploads don't save in preview. Anyone who isn't signed in to the project and opens the link before sending sees only the intro and "Your questions will appear here very soon". 3 Send: "Looks good, send it" publishes every draft at once, in order, and returns you to the Questions page opened at a green panel with the one real survey link, "Copy link", and "Email it to" the client, with the client's email in an editable box (saved to the project) that opens your own email app with a short note and the link filled in; aiKit doesn't send the email itself. That panel stays at the top of the Questions page from then on. Drafts don't count in "Sent so far" until they're sent. No step uses a browser pop-up; every confirmation is inline.

Two languages (2026-09-30). A questionnaire can be written in English and Spanish. The project's primary language is what the client sees first, and each question can carry its translation, including its options, tip, and section heading. When translations exist, the client's page opens in the primary language with an English / Español switch at the top that changes everything on the page at once: every question, choice, tip, section heading, the intro, and all the buttons and messages. The microphone listens in whichever language is showing, so a Spanish speaker can dictate in Spanish. Answers are stored as typed. A multiple-choice answer is always stored in the primary language's wording, whichever language the client was reading, so the Sent so far list and Brief & rules read consistently. A questionnaire with its own intro, its own language, or photos is shown as the business's own page: the header names the project and the aiKit ∞ mark is left off. The intro supports bold text and paragraphs.

Saving answers as they go (2026-09-30). On the client's page every question has its own Save answer button. A saved answer shows a check and the time it was saved, and the client can change it and save again until they finish; anything typed but not saved is kept in their browser, so a refresh doesn't lose it. The progress bar counts saved answers. "I'm done, send everything" at the bottom saves anything still unsaved and hands the answers over: filed into Brief & rules as the client's answers, waiting for you to confirm them (or held for you under "I review first"), and checked for a follow-up even if some questions were left blank. Until you press Confirm on an answer in Brief & rules (the card at the top reads "The client answered N questions"), the AI reads it as the client's information, never as an instruction; answers you approve with "I review first" are filed already confirmed. A round also hands itself over once every question in it has a saved answer. In the Sent so far list, a saved-but-not-finished answer carries a "Saved by the client, not sent yet" pill. A multiple-choice question can also offer "Other" (Add an "Other" choice with a text box, in the draft editor): the client ticks Other and types or dictates their own answer, stored after the picked choices as "Other: …". Follow-up questions on a two-language questionnaire are written by the AI in the primary language with the translation alongside (and a short tip where it helps), based on the client's actual answers and the notes on their photos, at most 8 per round, one follow-up round per round.

Loading a written questionnaire. A questionnaire written as a file (questions in both languages, sections, tips, choices, intro, photo tags) can be loaded as drafts with scripts/import-client-questions.mjs from the aiKit codebase, or through the app at POST /api/hosted-projects/<id>/questions/import (signed-in staff, or a full-access aiKit API key). Either one replaces the project's drafts and refuses if the project already has sent questions; nothing is sent.

Client photos (2026-09-30). The "Client photos" card has a switch, "Ask the client for photos at the end of their questions page." When it's on and questions have been sent, the client's page ends with a Photos section: they pick many photos at once (40 or more is fine), watch each one upload with its own progress bar (three at a time, with Try again on any that fail), then add a note to each (typed or dictated) and tap a tag such as Before, After, Finished job, or Me / my team. Notes and tags save on their own as they type; there's no Send button for photos, uploading doesn't require answering any question, and everything is still there when they come back to the same link. They can remove their own photos. On this page, the card shows every photo with its tag, note, file name, and size, and a Download button. Where aiKit's file storage is turned on, photos upload as the original file (up to 25 MB; short MP4 or MOV videos up to 100 MB also work); without one, each photo is shrunk to 2400 pixels on its long side in the client's browser before it uploads, and videos aren't accepted. The section is called "Photos and files": besides phone photos and screenshots (JPEG, PNG, HEIC, WebP), the client can upload GIFs, PDFs, and other files such as a logo, business cards, or flyers (AI, EPS, SVG, Word, Excel, PowerPoint, text, ZIP). Those upload untouched and show as a file card with a Download button; without a Blob store each file can be up to 4 MB. In the staff preview (step 2 above) the section appears exactly as the client gets it, but choosing files only shows a note that nothing is uploaded in preview.

The Versions tab (it replaces the old Changelog tab; ?tab=changelog links open it) has two parts. First, every saved version of the site, newest first, with Restore on any older one (see Versions in the editor window above: a restore is itself saved as a version, so it can be undone). Second, What shipped: every change that actually went out, newest first, each with a kind pill (fix or change), the page it touched, and when, and Copy proof link, which copies the same login-free updates link as the Updates page row on the Settings tab, meant to send a client as proof of what shipped.

Above the versions, Proofs sent to your client lists every website proof of this project (Send proof at the top of the tab, in the project's header, and on the review screen sends one): which copy of the site and how many pages it shows, Sent, Opened, Viewed, then Approved or Changes, who got furthest and when, and how many changes it put on the Feedback tab. An approval shows as Approved by (name) with the time and the site version, and that version gets an Approved by pill in the list below. Nothing is published by an approval: press Publish on the review screen when you're ready. The project's header also shows the newest proof's status (Proof: Waiting on your client, Changes requested, or Approved), which opens this list.

At the top, four tiles: Address (the live address, or that it isn't on the web yet), Status (the plain-language verdict, when it was last checked, and Check again), Free preview (days left of the 90-day window, with a bar), and Versions and backups (how many are saved, with Open Versions). Under them, one card: Go live before launch (a temporary aiKit address in about a minute; it waits until the first build has finished) or Redeploy after launch (publishes the project's current files to the same address, for a change made directly in the code; changes made with the editor, Quick edit, or feedback go live on their own).

Then the full plain-language tutorial on domains and where a site lives, written for a non-technical business owner, not a developer: what a web address (domain) actually is, explained with a shop-and-street-sign analogy; the difference between the temporary aiKit address every project starts on and the client's own domain; step-by-step instructions for connecting a real domain — the two DNS records to add (an A record to 76.76.21.21 and a CNAME for "www" to cname.vercel-dns.com), plus expandable per-registrar walkthroughs for GoDaddy, Namecheap, Cloudflare, Squarespace/Google Domains, Wix, and Bluehost/HostGator; exactly what changes once the domain is connected (search engines re-index under the real name, an old site on that domain gets replaced, email is untouched as long as MX records are left alone, and the temporary address keeps working); what to check, in order, if the site shows as down; when you'd ever actually need to touch any of this versus everyday changes; and, collapsed by default, the raw technical DNS/HTTP snapshot for a developer or a registrar's own support team.

The plain-language status labels used here — "On their own domain," "On a temporary aiKit address," "Site is down," and the rest — are defined once and reused by this tab, Technical details on Overview, and the list row's badge, so they can never say something different about the same project.