HP_
← Back to blog

// Software

SaaS Product Development Lessons from Building birchspace

SaaS products fail when they look like software but do not actually own a workflow. A login page, dashboard, and pricing table are not enough. The product has to replace a messy process with something customers can trust.

That is the lens I use when building birchspace, an HR management platform.

Start with roles before screens

HR software is role-heavy. Employees, managers, admins, company owners, and support users do not need the same access.

Before designing the dashboard, answer:

  • Who can see employee records?
  • Who can edit sensitive data?
  • Who approves changes?
  • Who receives notifications?
  • Who manages billing?
  • What should be logged?

If roles are vague, the product becomes fragile. Permissions are not polish. They are the product foundation.

Authentication is part of the customer experience

For many internal tools, password fatigue is real. Email OTP, phone OTP, SSO, and magic-link style flows can reduce friction, but they need to match the audience.

For birchspace-style HR software, the auth decisions affect:

  • employee onboarding
  • manager access
  • admin security
  • support workflows
  • mobile and desktop usage

Better Auth, email OTP, and Resend are useful tools, but the product decision is how people should enter and re-enter the system without creating security problems.

Billing should follow the product model

Stripe billing should not be treated as a separate feature. It needs to match:

  • company accounts
  • seat counts
  • plan limits
  • trials
  • invoices
  • customer portal access
  • cancellation rules
  • feature entitlements

If billing is bolted on late, product access becomes hard to reason about.

Admin tooling is not optional

Every SaaS product needs internal tools. Even a simple first version usually needs:

  • user lookup
  • account status
  • billing status
  • support notes
  • audit history
  • feature flags or plan checks
  • email resend flows

Without admin tooling, every customer issue becomes a database problem. That slows down support and creates risk.

Desktop and mobile only matter when the workflow needs them

birchspace has web, API, desktop, and mobile surfaces because different HR workflows may happen in different places. But extra apps should not be added just to sound bigger.

The test is simple:

  • Does a mobile app make the workflow faster?
  • Does desktop improve reliability or access?
  • Does the user need notifications or offline access?
  • Is the workflow frequent enough to justify the surface?

If not, web may be enough.

SEO for SaaS should map to buyer questions

Good SaaS SEO is not just "best HR software" pages. Useful pages answer real questions:

  • What does this product replace?
  • Who is it for?
  • What workflows does it support?
  • How does pricing work?
  • How secure is it?
  • What happens during onboarding?

For founder-led SaaS, the best content often comes from explaining the workflow better than competitors.

The build order I prefer

For most SaaS products, I would build in this order:

  1. Roles and data model.
  2. Authentication and account creation.
  3. One core paid workflow.
  4. Admin tooling.
  5. Billing and entitlement checks.
  6. Email notifications.
  7. Analytics and lifecycle events.
  8. SEO pages and customer education content.

That order keeps the product grounded in actual usage.

Bottom line

SaaS product development is less about adding features and more about owning a workflow. If the product can clearly replace a messy process, billing, onboarding, content, and growth become much easier to reason about.