Case study
Writing the product vision before writing a single migration.
This one started differently — with a locked product-vision document, not a database schema. That decision is why the build has stayed coherent across 30+ modules.
The problem
Credentialing companies don't need more software. They need less chaos.
The target customer — credentialing companies, medical billing companies, healthcare networks, provider enrollment companies — is already drowning in tools: Excel for provider lists, email for follow-ups, Google Drive or Dropbox for documents, phone calls for status checks. None of those tools are wrong on their own. The problem is that a single provider's credentialing status lives across all of them at once, and nobody has one place to look.
The temptation with a project like this is to build a generic document-and-workflow platform and let credentialing be one use case among many. That's the exact trap the product vision document rules out on page one: "if a future feature does not support this vision, it should not be implemented." Everything revolves around the provider. Not documents, not enrollments, not payors — those exist only to support provider credentialing.
The approach
A locked vision document as the actual architecture constraint.
Before any migration was written, the product vision, scope, and information architecture were documented and versioned — "LOCKED" status, referenced by every later document. That sounds bureaucratic for a solo-built SaaS, but it's what keeps 30-plus Filament resources (Provider Education, Licenses, Certifications, Work History, Peer References, Facility Affiliations, Malpractice Insurance, CAQH, Documents, Notes, Tasks, Payors — all under one Provider) from drifting into 30 inconsistent mini-apps.
The platform is split the same way the hospital SaaS is: a Platform Super Admin layer (tenants, plans, prices, entitlements, subscriptions, invoices, payments, coupons) structurally separate from each tenant's own credentialing workspace. A tenant admin never sees platform billing; a platform admin never sees a tenant's provider data by default. That separation is enforced in the architecture, not just hidden by a permission check.
The architecture
What's actually running under it.
- Backend
Laravel, with policy-based authorization on every resource and automated tests covering core flows.- Admin panel
Filament— over 30 resources across provider sub-modules, payors, document requests, notifications, and the separate platform panel.- Schema
- 46 migrations, documented table-by-table before being built — the schema was designed on paper first, not discovered by trial and error.
- Document requests
- A session-and-response model that lets an external provider or organization contact respond to a secure request link without a platform account.
- Multi-tenancy
- Tenant-scoped data access enforced at the model layer, with a separate Platform layer for the business that runs on top of it.
The interesting problem
Completion percentage should never be allowed to make a decision.
Every provider profile can show a completion percentage — personal information, licenses, documents, practice, payors, education, affiliations, required fields, tenant-specific requirements. The obvious design is to let that number gate what happens next: can't create an enrollment below 80% complete, say. The product vision explicitly rules this out: "Completion percentage is informational only. Business rules determine whether credentialing can continue."
That's a deliberate separation between a number that helps a human understand progress at a glance, and the actual rules that decide what's allowed — because a weighted percentage is a UX aid, not a correctness guarantee. A provider could be at 95% completion and still be missing the one required license that actually blocks enrollment; a naive "gate on percentage" design would either block providers who don't need blocking, or let through providers who do. Keeping those two concerns separate in the data model is a small decision with a large blast radius if it's gotten wrong.
The outcome
What's built, and what's honestly still ahead.
The provider data model, the Filament admin resources for nearly every module in the vision document, the platform billing layer, and the document-request flow are built. This is an active build, not a finished product — the honest status is a deep, well-architected foundation with real schema and real admin tooling, not yet a polished tenant-facing product ready for its first paying customer.
The next real milestone is closing the loop from "data model exists" to "a credentialing specialist can run their whole week inside this" — which is a UX and workflow problem now, not an architecture one, which is exactly the order I'd want those problems to arrive in.
Running a credentialing operation, or building a vertical SaaS that needs this kind of provider-centric discipline?
Get in touch