AI site operator for small teams
- Build locally with WaastWeb and your coding agent.
- Push source changes into Waastly for review, preview, and safe publishing.
- Use Site Health to keep broken links, metadata, performance, and content drift visible.
Waastly gives technical teams a safer operating loop for their website:
- Local WaastWeb projects you can own and export
- CLI push into a managed review and publish path
- CMS, file library, redirects, and hosting in one control room
- Site Health findings that turn into reviewed fixes
- Rollback-friendly static deployments
Context first. Website as the foundation. Marketing work builds from there.
Waastly starts with the website because that is where brand, content, traffic, conversion, and proof meet. Brand HQ and analytics context give the operator the business memory it needs before it proposes reviewable changes.
Can you make the homepage clearer and keep it on brand?|
Let me inspect Brand HQ, analytics context, and the local WaastWeb project before changing copy...
Brand HQ→ICP, voice, proof, offersAnalytics Context→Traffic sources, goals, outcomessrc/pages/page.tsx→Homepage source loadedwaastly status→No local or server divergenceThe website is the digital foundation, so the copy can explain the broader system without pretending every layer is already a separate product.
Here's my plan:
- Rewrite context-led copy
- Keep website loop as foundation
- Build locally
- Prepare a review candidate
Homepage Messaging→Context-first positioningWorkflow Section→Brand HQ informs the operatorwaastly build→Static build passeswaastly push --dry-run→Review payload checkedReady to queue a review candidate - approve before it can go live.
waastly push→Review candidate queuedReview candidate queued
The site change is inspectable in Waastly with build output, changed files, and preview.
Brand HQ and analytics context inform the source update, but the change still ships through the website review loop.
What should we fix on the site before launch?|
Let me inspect Site Health, analytics context, Brand HQ, and the generated routes...
Site Health→Sitemap gap and metadata risksAnalytics Context→Homepage drives qualified visitsBrand HQ→Audience and proof points loadedThe sitemap issue matters because every later campaign, report, and proof asset depends on the website being findable and coherent.
Here's my plan:
- Prioritize by business goal
- Draft scoped website fix
- Build candidate
- Review diagnostics
Business Context→Discoverability is highest leveragepublic/sitemap.xml→Manual stale file removedwaastly build→Sitemap regeneratedSite Health→Finding resolved in candidateSitemap fix is ready for review.
waastly push→Sitemap fix queuedFinding resolved in candidate
The generated sitemap reflects the build output and the fix is tied back to business context before publish.
Site Health uses context to choose the fix that matters, then turns it into a reviewable website change instead of a dashboard note.
Can you turn this page into a simple launch campaign?|
Let me gather the website source, Brand HQ, files, and analytics context before drafting anything...
Brand HQ→Voice, audience, offers, proofWebsite Foundation→Pages, CMS, files, publish historyAnalytics Context→Sources, forms, conversion signalsThe campaign should be built from the website's message and proof, not from a blank prompt.
Here's my plan:
- Use website as source of truth
- Apply Brand HQ voice
- Draft campaign layer
- Approve review output
Website Foundation→Launch page and proof selectedBrand HQ→Voice and ICP constraints appliedCampaign Brief→Email, social, and page angles draftedCampaign layer is ready to create as a reviewable output.
Campaign Layer→Reviewable workspace createdMarketing layer ready
The campaign starts from website source, Brand HQ, files, and analytics context, then stays reviewable.
The website remains the digital foundation. Brand HQ, analytics context, and campaign work layer on top when they help the operator decide and act.
A control room for the site you already own.
Waastly watches for the issues small teams usually discover too late: broken links, stale metadata, missing assets, risky source changes, and pages drifting away from the business.
Watch
ObserveTracks the pages, metadata, links, and assets that make the site feel cared for.
Triage
PrioritizeGroups findings by risk and impact so the next fix is obvious.
Draft fixes
Review firstTurns approved findings into source changes that you can inspect before anything ships.
Publish safely
Approval gateBuilds a review candidate, waits for approval, and keeps rollback available.
Push a real site change through review.
Join the private alpha for the local WaastWeb workflow: edit on disk, build locally, push to Waastly, review, and publish only when the candidate is ready.
Repeatable website work, made reviewable
Protocols are playbooks for common site improvements. They help scope the work, gather the right assets, and turn the outcome into a reviewable change.
Get notified when SEO Content Cluster is ready.
Get notified when Product Launch Campaign is ready.
Get notified when Email Nurture Sequence is ready.
Get notified when Competitor Comparison Pages is ready.
Get notified when Case Study Template is ready.
Get notified when Referral Program Page is ready.
You're still in the driver's seat.
Agents handle the heavy lifting, but every tool they use is yours too. Edit content directly, manage files, configure SEO. The full platform is built for humans as well.
WaastWeb Source & Hosting
Author real WaastWeb projects locally, then push source changes into managed hosting and review.
CMS Control Room
Manage structured content, preview changes, and keep schema-backed pages out of source-control merge trouble.
Structured Collections
Model repeatable content with typed fields for posts, pages, testimonials, protocols, and other website data.
File Library
Store, organize, and reuse brand assets, images, documents, and generated file references across the site.
Review & Publish
Every source change becomes a review candidate with changed files, build status, preview, and an approval gate.
Site Health
Catch stale metadata, broken links, missing assets, and quality issues before they linger on the live site.
SEO & Analytics
Keep Open Graph, structured data, performance signals, and lightweight analytics context available for reviews.
Multi-locale
Manage content across languages from one place, preview by locale, and publish when each version is ready.
API-first Delivery
Use REST and OpenAPI for integrations while the web app and CLI ride the same public contract.
File Manager
Upload, organize, and reference images and documents through folders, metadata, and managed delivery.
Your website should be a living system, not a launch artifact.
Waastly connects local source, CMS content, files, review builds, publishing, and Site Health around the website your customers actually visit.
Your site is a real TSX project on disk. Pull it, edit it locally, build it, and keep the source portable.
Push source changes into Waastly, inspect the candidate build, and publish only after the review is ready.
Preview changes, track findings, keep audit history, and roll back if a deployment needs to be reverted.
Keep your website improving after launch.
Join the waitlist for the Waastly private alpha. We are looking for technical founders, agencies, and operators who want a safer local-first website workflow.