Information architecture
Website-level tasks, page structure, section order, element settings, and global style choices occupy distinct but connected layers.
SarDev AI Website Lab · Product design + AI-assisted development
One platform for moving from an idea to an editable, publishable website.
How I designed and directed an AI website development, hosting, and publishing platform—and the visual SarDev AI Website Builder customers use to shape their sites.
Product Strategy · UX/UI · Information Architecture · Multi-Tenant SaaS · AI-Assisted Development · Release Governance
Live AI website development platform
Idea → build → edit → publish
Four creation paths, a visual editor, responsive modes, revision history, media and SEO tools, store configuration, AI assistance, domains, hosting, and plan boundaries.
The problem
Website creation is not one task. It is a connected product journey.
The product had to help customers begin in the way that fit their situation, then bring content, structure, responsive layout, media, search settings, store configuration, revision safety, preview, publishing, domains, and plan limits into one understandable system.
The design challenge was not simply generating pages. It was creating a dependable operating model for a website: enough guidance for a first-time creator, enough control for deliberate editing, and explicit boundaries around what AI, the customer, and the platform each control.
- Small-business owners
- Founders
- Independent professionals
- Creators
- Teams needing a managed site
My role
Founder · Product Strategist · Experience Architect · AI-Assisted Development Lead · Release Decision Authority
I defined the product intent, operating boundaries, experience structure, visual direction, technical requirements, acceptance criteria, and release decisions. AI accelerated bounded implementation and analysis inside that human-led process.
- Product authority
- Set the audience, value proposition, priorities, plan boundaries, and criteria for moving work from concept to release.
- Experience design
- Directed the four entry paths, dashboard-to-editor journey, tool organization, responsive controls, and recovery model.
- System direction
- Established how the React editor, Fastify services, PostgreSQL records, background jobs, site runtime, and deployment stack cooperate.
- AI boundaries
- Used AI for scoped research, implementation, testing, and documentation while retaining human review and final decisions.
- Quality control
- Defined test gates, reviewed behavior, isolated defects, directed corrections, and protected tenant and release boundaries.
- Evidence discipline
- Separated current observation, historical test records, implemented capability, plan-limited behavior, and unverified outcomes.
Four creation paths
Different starting points converge on one editable site model.
- 01Start with AI
Describe the business and direction, then review a generated first draft rather than accepting an opaque final result.
- 02Choose a template
Begin from a structured design pattern and adapt content, styling, pages, sections, and site settings.
- 03Start blank
Build directly with sections and elements when the structure and visual direction are already understood.
- 04Upload a template
Bring in a validated portable site document while excluding account data, private integrations, and unsafe local references.
The creation paths change how a site begins—not the ownership, tenant, validation, preview, or publishing boundaries that govern it afterward.
Experience the live Website Builder
The real editor, in a server-enforced portfolio-demo mode.
Explore pages, sections, styles, responsive modes, and safe in-browser editing. The demo is a sanitized representation of one allowlisted site. Changes remain in memory, reset on refresh, and cannot save, publish, upload, use AI credits, submit forms, reach store or account data, or alter the production site.
Sanitized, non-persistent live editorLoading portfolio demo…
The outer frame grants scripts and same-origin access only because the editor's responsive canvas uses its own same-origin frame. Top navigation, downloads, forms, popups, storage access, camera, microphone, geolocation, clipboard, and other capabilities are not granted.
Visual editor and tooling
A persistent canvas, focused tool rail, and contextual controls keep structure visible.
Direct manipulation
Selection, inline text editing, reordering, resizing, duplication, deletion, and contextual inspection support visible cause and effect.
Responsive workflow
Desktop, tablet, and mobile modes let creators review layout intent without losing the shared site document.
Revision model
Autosave, optimistic concurrency, browser undo/redo, recovery drafts, revision history, restore, preview, and rollback serve different recovery moments.
Architecture and deployment model
One validated site document moves through isolated services and explicit release gates.
Client experience
React 19, Vite 8, a validated site-document model, reusable renderer, responsive editor canvas, and keyboard-aware controls.
Platform services
Fastify 5 routes for authentication, tenant-scoped sites, assets, revisions, preview, publishing, forms, domains, billing, stores, support, and administration.
Data and jobs
PostgreSQL 16 records site revisions and tenant data; queued jobs isolate longer-running AI, preview, publishing, domain, and operational work.
Delivery
Separate platform, worker, and site-serving processes run in Docker behind Caddy, with health checks, persisted data volumes, backup procedures, and rollback records.
QA and evidence
Tests support implementation confidence—but their date and scope stay visible.
Historical automated checks
The supplied report records 68 passing Vitest checks across unit and integration coverage at its October 2026 evidence point.
Historical browser checks
The report records 14 passing Playwright tests covering core journeys and public behavior at that same evidence point.
Responsive editing
Desktop, tablet, and mobile controls expose distinct layout review states inside the shared editor.
Portfolio demo
Only one site ID has a sanitized anonymous data path; mutation, tenant, account, commerce, AI, asset, form, history, domain, and publish routes remain protected.
Historical counts are attributed to the supplied report and are not presented as newly run checks. Current deployment verification is documented separately from that report snapshot.
Current boundaries
A credible case study states what the evidence does not establish.
Currently live and directly verified
The platform, authenticated owner editor, sanitized portfolio demo, core public pages, and production health endpoints are checked against their live URLs after release.
Historical project evidence
The 31-page report documents prior design decisions, source inspection, QA records, and the state observed when the report was prepared.
Plan- or configuration-dependent
Publishing, AI credits, custom domains, custom code, store operations, and other capabilities remain governed by account permissions, plan rules, and production configuration.
Not claimed
No user count, adoption, conversion, revenue, ROI, retention, customer-satisfaction, independent accessibility certification, compliance certification, live-payment outcome, or automated domain-fulfillment claim is made.
Known limitations in the report snapshot
Domain work was human-mediated rather than fully automated, production payment behavior was not established, and the historical QA record was not an independent accessibility or security certification. The portfolio demo intentionally removes persistence and every network-backed account feature.
Lessons
A useful AI website platform needs governance as much as generation.
- Offer multiple beginningsAI, templates, blank canvases, and portable uploads solve different starting conditions.
- Keep one source modelCreation, editing, preview, publishing, history, and rollback work better when they share a validated document.
- Make recovery layeredUndo, drafts, revisions, previews, deployments, and rollback address different failure windows.
- Put authority on the serverTenant, session, CSRF, plan, and permission rules cannot depend on a client flag or visible control.
- Label evidence honestlyObserved behavior, historical tests, implementation, plans, and business outcomes are different kinds of claims.
Key insight
AI can accelerate a build. It cannot own the product decision.
A coherent platform still requires a person to understand the customer, define the system, set security and evidence boundaries, review generated work, reject weak assumptions, protect working behavior, and decide what is ready to release.
I supplied that product authority. AI supported bounded execution.Explore the evidence
Try the safe live demo or read the complete design and development report.
The report is published exactly as supplied. The live demo is intentionally narrower than an authenticated owner editor and cannot change the source site.