Skip to main content
Skip to content

Resources

Landing pages are not products: what a real SaaS template needs beyond a hero section

Last updated 29 May 2026 · Dan Tinsley, Halbon Labs

A beautiful landing page can sell a template. It cannot run a SaaS product.

Many starter kits look impressive on the first scroll: gradient hero, animated badge, pricing cards, testimonials, maybe a dashboard screenshot. Then you log in and find the actual product surface is thin: empty dashboard, generic settings page, weak forms, missing error states, no admin tools, and inconsistent mobile behaviour.

A SaaS template should be judged by the screens users live in, not only the pages visitors see before signup.

The homepage is the easiest part to polish

Marketing pages are visible, linear, and forgiving. Product interfaces are not.

A real SaaS interface has to handle:

  • empty data;
  • partial data;
  • loading states;
  • failed requests;
  • user mistakes;
  • destructive actions;
  • permissions;
  • billing status;
  • mobile layouts;
  • keyboard navigation;
  • dark mode;
  • long names;
  • timezones;
  • admin workflows;
  • support workflows.

A template that ignores these states pushes product design work back to the buyer.

1. Empty states should teach the product

A dashboard with no data should not feel broken.

Good empty states explain:

  • what the user is looking at;
  • why it is empty;
  • what to do next;
  • whether an action requires a paid plan;
  • where to import, create, or connect data.

For example, “No projects yet” is weaker than:

Create your first project to start tracking tasks, budgets, and team activity. You can invite teammates after the project is created.

Empty states are onboarding moments. A production template should include them.

2. Error states should be designed, not dumped

Errors are part of the interface.

A good SaaS starter includes patterns for:

  • form validation;
  • failed saves;
  • network failures;
  • permission errors;
  • billing-required states;
  • expired sessions;
  • missing records;
  • deleted records;
  • unavailable integrations.

A raw stack trace or generic toast is not enough. Users need clear language and recovery actions.

3. Settings pages reveal product maturity

Settings are where SaaS products become real.

Useful starter settings include:

  • profile;
  • password or auth provider notes;
  • email preferences;
  • billing;
  • team members if applicable;
  • API keys if applicable;
  • data export;
  • account deletion;
  • notification preferences;
  • security settings;
  • organisation profile for B2B products.

A template without settings may still help you start, but it is probably not a full product foundation.

4. Billing UI should reflect billing state

Billing is not just checkout.

The product should show:

  • current plan;
  • renewal date;
  • trial status;
  • cancellation state;
  • failed payment state;
  • upgrade or downgrade path;
  • billing portal access;
  • invoice link if supported;
  • permission-aware plan prompts.

A pricing page is marketing. Billing settings are product.

5. Admin surfaces matter earlier than you think

Even small SaaS products need internal visibility.

An admin interface might include:

  • users;
  • subscriptions;
  • recent signups;
  • audit logs;
  • failed webhooks;
  • support notes;
  • usage metrics;
  • account status;
  • feature flags;
  • delete or suspend actions.

You can build without all of this on day one, but a serious template should at least include a pattern for internal operations.

6. Tables need real interaction design

Dashboards often depend on data tables. A table is not production-ready just because it renders rows.

Check for:

  • sorting;
  • filtering;
  • pagination;
  • bulk actions;
  • row actions;
  • responsive behaviour;
  • empty states;
  • loading skeletons;
  • error states;
  • permissions;
  • accessible labels;
  • keyboard focus.

Tables are where weak UI kits often reveal themselves.

7. Forms need more than inputs

Forms should include:

  • labels;
  • validation messages;
  • disabled states;
  • dirty-state handling;
  • success messages;
  • server error handling;
  • loading states;
  • destructive-action confirmations;
  • accessible focus management.

A form that works only on the happy path will create support issues.

8. Mobile dashboards are not optional

Even B2B products are used on small screens.

A SaaS template should handle:

  • navigation collapse;
  • tables or card alternatives;
  • sticky actions;
  • touch target sizes;
  • overflow menus;
  • long labels;
  • modal behaviour;
  • safe spacing.

A responsive homepage does not prove the app is responsive.

9. Dark mode should be tokenised

Dark mode is not simply inverting colours.

A strong design system uses semantic tokens for:

  • background;
  • foreground;
  • muted text;
  • borders;
  • cards;
  • destructive states;
  • focus rings;
  • charts;
  • status badges.

If dark mode is a series of one-off utility classes, customisation becomes painful.

10. Accessibility is product quality

Accessibility issues often appear in product screens:

  • unlabelled icon buttons;
  • modals without focus management;
  • poor contrast in badges;
  • keyboard traps;
  • animated panels that ignore motion preferences;
  • hidden controls that screen readers cannot understand.

A template that claims premium UI should include accessible defaults.

11. The product should not smell like a template

“Template smell” appears when every buyer ships the same obvious layout, same filler copy, same icon grid, same testimonial cards, and same generic dashboard.

A better template gives you structure without making your product feel cloned.

Look for:

  • customisable tokens;
  • component ownership;
  • domain-specific pages;
  • real layout variation;
  • clear content slots;
  • documented customisation paths;
  • no lorem ipsum left in functional areas.

Product UI audit checklist

Before buying a SaaS template, inspect:

  • Dashboard beyond the hero screenshot.
  • Empty states.
  • Loading states.
  • Error states.
  • Settings pages.
  • Billing UI.
  • Admin or operations surfaces.
  • Tables and bulk actions.
  • Forms and validation.
  • Mobile app screens.
  • Dark and light mode.
  • Keyboard navigation.
  • Reduced-motion behaviour.
  • Customisation path.
  • Absence of lorem ipsum in product-critical areas.

Template Empire angle

Template Empire separates frontend-first Empire UI kits from full-stack SaaS templates, but both are built around the same idea: a product surface should feel real beyond the landing page. Polished dashboards, settings, admin patterns, accessibility, and quality gates matter because buyers are not just launching pages. They are launching products.

Further reading