Software built for real operations, not just games.

HealthCore + PharmaCore is a multi-tenant SaaS platform that merges two systems small-to-mid healthcare businesses usually run separately: an outpatient clinical system (patient triage, doctor consultations, e-prescriptions) and a pharmaceutical inventory and supply-chain system (batch and expiry tracking, manufacturing, point-of-sale). The gap I was targeting is the handoff between a doctor writing a prescription and a pharmacist filling it — in most small clinics that handoff still happens on paper or over a phone call, which is exactly where medication errors, stock discrepancies, and billing mismatches creep in.

Architecture

Built as a modular monolith rather than a microservice mesh: one deployable Laravel application split into clean internal module boundaries (app/Services/HealthCore, Inventory, Manufacturing, Finance), with two panels sitting on top of the same codebase — a Platform panel (/admin) for managing tenant companies, plans, and subscriptions, and a Company panel (/company) where clinical and pharmacy staff do their actual work. I chose a monolith deliberately: for a solo-maintained product, transactional consistency across modules matters far more than the independent scaling a microservice split would buy me, and a single codebase is something one person can actually keep in their head.

Multi-tenancy without running hundreds of databases

Rather than a database-per-tenant (painful to migrate at scale) or a fully shared schema with no guardrails (one bug away from a cross-tenant data leak), every business model uses a BelongsToCompany trait that registers a global query scope on boot — every query is automatically filtered to the authenticated user's company, with no per-controller "don't forget to scope this" discipline required:

static::addGlobalScope('company', function (Builder $builder) {
    if (auth()->check() && !auth()->user()->is_platform_admin) {
        $builder->where('company_id', auth()->user()->company_id);
    }
});

Branch-level restriction stacks on top of that: a user flagged restrict_to_branch only sees records under their own branch, while a company-wide manager sees across all of them.

Feature areas

Engineering problems I actually had to solve

Two cashiers, one batch, at the same time. In a busy pharmacy, two people could sell from the same expiring batch simultaneously and oversell it. Batch queries take a database-level pessimistic lock (lockForUpdate()) inside a transaction, so batches are claimed in expiry order without a race condition.

Stock getting deducted twice. If both the clinical dispensing step and the sales/billing step tried to reduce inventory, the ledger would corrupt. I settled on a Single Stock Authority pattern: the dispensing service prepares and validates the item list but always delegates the actual stock movement to one sales-workflow service — never two paths writing to inventory.

A cashier double-tapping "Settle" on a bad connection. Unstable networks mean people retry. Every settlement carries a deterministic operation_key, and a compound unique index on (company_id, operation_key) means a retried request is silently absorbed instead of creating a second payment record.

Verification

The full test suite currently passes 64 tests across 166 assertions, 0 failures, covering the parts that actually worried me: FEFO batch allocation picking the correct expiry order, the prescription-to-dispensing handoff not double-deducting stock, cashier settlement idempotency under duplicate submissions, manufacturing yield/QC gating, and branch-level data isolation.

StockMata is a multi-tenant B2B commerce, inventory, POS, and accounting platform, built for retail, supermarket, distributor, and restaurant/hospitality businesses. The deliberate architectural choice here is a split most tutorials never mention: WordPress stays as the public-facing, searchable, content-editable front of the site, while a completely separate NestJS + React backend handles the actual transactional work — POS, inventory, ledger, sync. It's a pairing chosen for a real reason: WordPress gives indexable pages and easy content editing for free, which a single-page React app doesn't, without forcing the transactional engine itself to live inside WordPress's constraints.

Offline-first, on purpose

The standout piece of this build is the sync engine: sales happen through a React 19 client backed by browser-native IndexedDB, so a cashier can keep ringing up sales through a total network dropout. Each offline sale gets a client-generated UUID and queues locally; once the connection returns, the queue pushes to the backend inside a database transaction. Every operation is checked against its UUID before it's applied — a retried or duplicated push returns the already-synced result instead of double-charging or double-deducting stock.

Feature areas

Engineering problems worth mentioning

Duplicate transactions from retried sync requests. The same fix as any idempotency problem, applied to an offline-first context: every synced operation carries a UUID, checked inside the same transaction that would apply it, before it's applied.

Profit distortion when supplier costs change. Naive reporting recalculates old sales against today's cost price, which quietly erases historical profit. Every sale line stores its own cost-price snapshot at the moment of sale, so a price change next month can't retroactively rewrite last month's numbers.

A separate, larger project sharing the StockMata name and some DNA with the WordPress-fronted version above, but built as its own standalone enterprise webapp — no WordPress anywhere in this one. Its own tagline sums up the intent better than I could: "Sales, stock, debts, and reports for African SMEs." Where the first StockMata is a commerce/POS platform, this one grows into a genuine light-ERP: manufacturing, HR, multi-tier approvals, and per-tenant customization sit alongside the same POS and inventory core.

Onboarding that adapts to the business

Rather than one fixed feature set for everyone, a sector-preset engine provisions different module bundles, role templates, and default departments depending on what kind of business is signing up — retail, pharmacy, restaurant, manufacturing, distributor — gated further by a commercial tier (community/pro/advanced/erp). A pharmacy gets batch and expiry tracking by default; a restaurant gets kitchen-display routing; a manufacturer gets Bills of Materials. Same core platform, different provisioned shape.

Feature areas

Extending the schema without migrations

Enterprise tenants inevitably need fields the core schema never anticipated — a NAFDAC number, a license plate, a doctor's license ID. Rather than bolting on a migration per tenant request, custom fields are stored using an EAV-inspired pattern in typed PostgreSQL JSONB columns, so a business can define its own typed, validated fields at runtime.

KCC Pharmaceuticals needed a single place for staff to handle HR requests, internal communication, compliance, and company records. Rather than deploying an off-the-shelf intranet plugin and working around its limits, I built a custom WordPress plugin (kcc-intranet) on a child theme, which gave full control over the access logic and workflows the company actually needed.

Designed around a real constraint: Nigerian office networks

Connectivity and power aren't guaranteed in the office, so that shaped the build from the start rather than being patched in afterward — an offline mode caches static assets and saves local drafts for forms like leave requests, so a dropped connection mid-form doesn't cost someone their work.

Access & security

A five-level staff clearance system (Staff → Manager → HR/Admin → Executive → WordPress-administrator override) controls both page access and content visibility, with visibility further scoped by department. Login runs through a custom email-OTP flow rather than a generic two-factor plugin, and a built-in Network Access Control module supports IP/CIDR allow- and block-listing for locking the intranet to office or VPN ranges. On top of that sits a mandatory policy-acknowledgment gate: a staff member who hasn't signed off on the current Privacy Notice, Acceptable Use Policy, and Data Subject Rights notice gets redirected there on every page load until they do — with the acknowledgment page itself whitelisted so nobody gets stuck in a redirect loop.

WordPress's default search doesn't know about any of this clearance logic — out of the box it would happily show a low-clearance employee the title of a restricted executive announcement. So search results are filtered through the same visibility rules as everything else before they ever reach the page, meaning a search box can't be used to route around the access model it sits inside.

On the operability side: an audit log records who did what — logins, downloads, permission changes, DSR requests — with actor, IP, and a bit of context, stored in its own table with automatic retention cleanup rather than growing forever. Built-in diagnostics (URL health, broken-media detection, page health, shortcode health) mean I can catch a broken link or a missing asset without manually clicking through every page, and page assets only load on the pages that actually use them rather than on every request.