Why Nebutra Sailor Exists

Most SaaS starters are useful on day one and expensive by day thirty. They usually prove that authentication, billing, and a dashboard can exist in the same repository. Real products need more than that: tenant boundaries, permissions, audit trails, content workflows, deployment rules, and a way to keep product surfaces consistent as the team moves faster.

A starter should carry production shape

Nebutra Sailor treats the starter as an operating system for a SaaS company, not as a folder of examples. The landing page, dashboard, docs, studio, gateway, and shared packages are separate enough to evolve, but close enough to share contracts, tokens, and release discipline.

AI-native without making AI the architecture

AI features belong inside the product, but they should not replace the product architecture. Sailor keeps model access, streaming, rate limits, usage metering, and auditability behind explicit packages and gateway boundaries. That lets teams add AI workflows without weakening the SaaS fundamentals around identity, tenancy, and billing.

Governance is part of the product

The project is intentionally opinionated about design tokens, package boundaries, route ownership, tests, and publishing workflows. Those choices reduce the number of local decisions each team has to remake, and they make later changes safer because the system has named places for content, UI, data, and platform behavior.