Building the system that tells a credentialing team what's about to lapse.

The project is written down in a numbered series of documents: a vision, a scope, an architecture and a numbered series of documents covering the data model, each provider sub-section, permissions, security and billing. The vision is marked locked and says that if a feature doesn't support it, it should not be built. The central sentence is that the provider is always the centre: nothing revolves around documents, enrollments or payors, because those exist only to support a provider's credentialing.

That sounds like ceremony, and its value shows up in the code. Every credential section (education, training, licences, certifications, malpractice insurance, work history, references, affiliations) is a child of the provider and appears on the provider's page, with a completion meter that lists exactly which sections are still empty. It's also why the product refuses to grow ERP-style extras. It's a 49-migration application with a clear spine instead of a pile of modules.

Credentialing means chasing providers for documents, and the usual way, attachments in email, loses files and leaks data. So the team creates a document request and the provider gets a secure link. The link carries an 80-character random token. The token is shown once in the link and only its hash is stored, so a copy of the database can't be turned back into working links.

A request has an expiry (14 days by default), a version number that lets the team revoke every outstanding link at once, a rate limit on the public portal, and a status that moves from sent to opened to submitted. Nothing the provider uploads counts straight away: every submission goes to a review queue where a team member accepts or rejects it. That separation of received and accepted is the real feature.

A plan is more than a price. It carries limits (users, providers, locations, storage) and switches (exports, imports, advanced reports, document requests, custom fields), and when a subscription starts those entitlements are copied into a snapshot, so changing a plan later doesn't silently change what an existing customer paid for. Payments, invoices and subscriptions run through Razorpay, and invoices and subscription authorisation have their own pay-by-link pages.

The part I care about is the webhook. Razorpay calls the app when something happens, and anyone could forge that call. So the handler checks Razorpay's signature on the raw request, and every event is recorded so a duplicate or replayed event is ignored instead of paying an invoice twice. The code is tested against its own rules. It has not been run against a live Razorpay account, and I'm not going to say it has.

The suite has 92 tests and 612 assertions, and it passes. They run against an in-memory database so they can't touch real data. They cover tenant isolation and context resolution, role and policy isolation, the document request portal, tenant signup, location and user services, custom-field values, auditing, both Razorpay services, bulk-import security, and an architecture test that guards file and class naming. The pattern is deliberate: the security document lists the tests a product like this must have, such as cross-tenant access, token replay and webhook replay, and the suite follows that list as far as it has got.

It isn't complete. The baseline lists more than is built, including malware scanning of uploaded files, so I treat it as the target and the tests as the evidence, and I only claim what the tests show.

It's a working multi-tenant application with a provider-centred data model, a full credentialing workflow, secure document requests, expiry tracking, reports, roles, and a platform side for plans and billing, held together by a written security baseline and a test suite that tries to break its own isolation.

What it isn't: launched, tested against live payments, or finished against its own security document. One report page is broken, malware scanning is not built, and the platform panel isn't shown here. I'd rather publish the gaps than let a buyer find them.