Tuli Builder — An AI-Powered WordPress Website Builder

Tuli Builder is my own product — an AI-powered website builder for WordPress. You describe the page you want, and it produces real, editable pages, templates, headers and footers as clean HTML and CSS, not the nested shortcode soup that traditional page builders leave behind.

I own the entire thing end to end: product direction, UX, architecture, the AI layer, the billing and licensing system, the SaaS infrastructure, the marketing site and customer support.

The problem it solves

Every page builder on the market trades developer control for drag-and-drop convenience. The cost shows up later: bloated DOM trees, dozens of render-blocking stylesheets, Core Web Vitals that never go green, and markup that is effectively impossible to hand-edit or migrate away from.

Meanwhile, agencies and freelancers are under pressure to ship faster. The gap between “fast to build” and “clean to maintain” is where Tuli Builder sits.

What I built

• A visual builder whose underlying format is plain HTML and CSS — anything a developer can write by hand, the builder can render and edit.
• An AI generation layer that writes full pages, templates and sections from a prompt, grounded in the site’s own design tokens so output matches the brand instead of looking generated.
• A template system with headers, footers, single and archive layouts, display conditions and priority resolution.
• Query loops and dynamic data — a token system that prints live WordPress and ACF values at render time without a line of PHP.
• Licensing, billing and provisioning — subscription handling, license key validation, update delivery and customer account management.
• A code-snippet manager with a safe-mode watchdog that auto-deactivates any snippet causing a PHP fatal, so a bad edit never white-screens a customer’s site.

Engineering decisions worth noting

The hardest constraint was round-tripping. Anything the AI produces has to survive a human opening it in the visual editor, moving things around, and saving again — without markup drift. That pushed me toward a sanitizer-first design: every save runs through the same normalisation pass, elements get stable identifiers, and disallowed markup is stripped rather than silently re-parsed.

The second constraint was safety. A builder that executes customer-authored code needs hard boundaries: capability checks on every write path, no unauthenticated execution surfaces, and a fatal-error watchdog that can roll back.

Where it stands

Tuli Builder is live at tulibuilder.com with paying customers, and I continue to ship features and support users week to week.