Skip to content
All posts

Click-by-click tour of saas.otf-kit.dev proves its true production readiness

DaveOTF Kit
7 min read
Click-by-click tour of saas.otf-kit.dev proves its true production readiness

A working SaaS app you can click through before paying is rare. Most template shops sell screenshots and a promise; the gap between a marketing page and the delivered code is where buyers get burned. OTF's SaaS Dashboard has a public landing page and a live demo at saas.otf-kit.dev, so you can inspect the visible screens before deciding whether the kit fits your project.

This is a screen-by-screen record of the demo observed on October 9, 2026. The walkthrough used the no-signup demo as Demo User. The public landing page was also checked while signed out. Demos change, so treat these notes as a dated inspection, then follow the links and confirm the current behavior that matters to your team.

A live demo to inspect before buying

A live preview gives you something more useful than a screenshot: a running interface you can navigate. It lets you inspect which pages, labels, and controls are present in this specific build. It does not by itself prove that every control saves data correctly, that access rules are secure, or that the delivered source has every feature shown in the preview.

That distinction matters when evaluating any starter. Our article on why screenshots lie makes the same practical point: a static image cannot answer questions about navigation or interaction. A browser tour can. It is still one observation, though, not a substitute for checking the source and testing your own critical flows.

The tour: screens visible on October 9, 2026

I first checked the site while signed out, selected the live demo, entered through its no-signup option, and walked the available workspace. The steps below describe visible screens and controls. Where I did not submit or destructive actions could alter shared demo data, I say so rather than treating a button as proof of a complete backend flow.

  1. Public landing page. While signed out, the root page showed Features, Pricing, FAQ, GitHub, Sign in, and Get started in its navigation. The hero included “View live demo,” which opened the demo sign-in route. Pricing and FAQ sections were visible farther down the page. I used the demo link rather than creating an account.

  2. Sign in. The sign-in page offered email and password fields, a Google sign-in option, and “Try the demo (no signup).” GitHub was marked “Soon.” I selected the demo option; I did not submit an email/password form or test Google authentication.

  3. Dashboard. The demo opened on a dashboard with issue-count cards, charts, Recent Issues, and Recent Activity. The cards showed 28 total issues, 24 open, 6 in progress, 4 completed, and 7 urgent. Recent Issues listed issue titles alongside identifiers, statuses, dates, and project names. Those are the values shown during this session, not a promise that the demo data will stay fixed.

  4. Plan label and Upgrade control. The sidebar showed a Free plan label and an Upgrade button. I did not open a plan or payment flow, so the button’s destination and behavior remain unverified. Billing for a buyer’s product is not included in the delivered kit. The customization guide documents an optional implementation path for adding Stripe Checkout and a webhook; those instructions are not a shipped billing feature.

  5. Organizations. The workspace switcher listed Acme Corp, Beta Labs, and Gamma Inc. It offered a create-organization option, and the creation form showed a workspace name field. I switched between the listed workspaces and inspected the create form without submitting it.

  6. Members. The Teams screen showed a people table with names, teams, roles, workload, and weekly counts. Invite People opened a form and a Pending invites list with member and viewer roles. The table displayed member and viewer roles, and a member row menu showed Message, Email, and Remove. I did not remove anyone or send an invitation.

  7. Profile and notifications. Profile settings showed editable name and email fields and a Change avatar control. The Notifications tab showed switches for mentions, assignments, subscribed issue comments, and a weekly digest. I inspected these controls without changing or saving settings.

  8. Projects. The Projects screen listed projects with status, members, progress, and issue counts, and included a New project button. The paused project's row menu offered Open project, Pause, and Delete. I did not delete a project.

  9. Recent activity and Inbox. Recent Activity showed issue titles, statuses, and dates. The Inbox showed assignment and mention notifications, with an unread filter. Together, these screens let a visitor scan recent issue updates and unread notifications in the demo.

  10. Sign out. The account menu included Sign out. Selecting it returned me to the sign-in page, which offered email and password, optional Google sign-in, and the no-signup demo entry. I verified the route change, not any broader session-security guarantee.

The demo is a buyer-facing preview, not a security review. It can show that a screen or control is present; it cannot establish its permissions, data isolation, persistence, or behavior under failure. If one of those details affects your launch, test it in a deployment you control and inspect the corresponding implementation before you depend on it.

11 production screens. Login and database wired.

The SaaS Dashboard Kit includes login, a database, and a working dashboard. Live demo at saas.otf-kit.dev.

See the live demo

What the tour can tell you

A guided preview helps you decide what to inspect in the source. The October 9 session showed a public landing page, an email/password sign-in route, an issue dashboard, workspace navigation, member and project controls, profile settings, notifications, and an Inbox. It also showed where the boundary of this walkthrough lies: I inspected the displayed controls, but avoided submitting profile changes, creating organizations, sending invitations, or deleting records in a shared demo.

Email and password sign-in. The sign-in screen presented email and password fields, Google as an additional sign-in option, and a separate no-signup demo action. For details about the delivered implementation, confirm the current authentication configuration in the kit rather than assuming every provider is enabled in every deployment.

Billing is an integration you add. The Free label and Upgrade button were visible in the demo sidebar, but I did not verify a working upgrade flow. The delivered kit does not include app billing. Its customization guide describes how to add Checkout and a webhook as developer work. Treat the guide as instructions for extending the kit, not evidence that a payment system ships ready to use.

Workspace and member controls. I could inspect a workspace switcher, a creation form with a name field, the people table, pending invites, and a member row menu. I did not test whether workspace data is isolated. A visible label or control does not answer that implementation question; check the code and run an appropriately scoped test before making an access-control decision.

Projects and activity. The project list exposed status and issue counts, and a row menu showed Open, Pause, and Delete. The Recent Activity list showed issue titles, dates, and statuses; Inbox displayed assignment and mention notifications. This is a quick way to inspect visible work and notifications in the demo.

From preview to your own product

Use the live SaaS Dashboard demo to repeat the inspection before buying. Start with the sign-in route and dashboard, then check the workspace, member, project, and notification screens that matter to your application. Controls and demo data can change after this dated walkthrough.

After purchase, compare the delivered source with the screens you plan to keep, then configure the providers and deployment settings your app needs. The ship-to-production checklist covers the work between a working starter and a production deployment, including DNS, TLS, custom domains, and production builds. Keep the demo’s visible behavior separate from claims about production readiness until you have tested the paths your users will rely on.

A useful starter should make that evaluation concrete. You can click through the preview, decide which parts match your product, and identify what still needs implementation. That is a better buying decision than inferring functionality from a screenshot or a feature list.

Sources

Evaluating kits with your agent? Start from one you can click before you buy — browse starters at otf-kit.dev/templates.

kitsbackendannouncement
Free starter

Ship your first screen tonight — free starter in your inbox

The quickstart, the SDK repo and the live kit demos, on this screen and in your inbox.

No spam. Unsubscribe any time.

Get the free AI configs pack

The AI files every kit ships: CLAUDE.md, .cursorrules and task prompts. Drop them in and your AI tool knows your project.

No spam. Unsubscribe any time.

Prefer the free SDK? Star it on GitHub →