The problem and the product
Lorica is building the compliance and vendor-coordination infrastructure for the private security industry. Most security firms still run on phone calls, spreadsheets, and fragmented systems to manage employees, vendors, and credentials. That fragmentation isn't just inconvenient; it creates real risk: compliance gaps, failed audits, insurance disputes, and constant operational drag. The product replaces that friction with a unified, compliance-first platform designed for how security operations actually run.
The platform has two complementary halves, and both shaped the engineering:
- The internal workforce layer. Helps a firm manage its own people by tracking licenses, training, insurance, and credential expirations in one verified source of truth. A lapsed license is a liability event; this layer makes that risk visible before it bites.
- The cross-company layer. Extends that same verified data across organizational boundaries, enabling compliant vendor management, controlled information sharing, and coordinated workflows between primes and subcontractors. The same professional can be engaged by several organizations at once under different arrangements, and this layer keeps that web of relationships clean and governed.
Together they turn compliance from a cost into an operational advantage: risk made visible, audits made defensible, and vendor relationships made manageable at scale. And while the wedge is private security, the underlying infrastructure (portable credentials, verified profiles, compliance-ready workflows) generalizes to any regulated, liability-heavy industry.
That was the opportunity. But before any of it could be built properly, the company needed something more immediate: a product real enough to raise on. That split the work into two acts.
Act I — building the first working product
From day one the brief was explicit and ambitious: build a real, working product, not a throwaway demo, with the feature-heavy push due in roughly three months. The owners would also use it to open fundraising conversations, but there was never a plan to fake it; the goal was something genuinely usable that happened to tell the platform's story convincingly.
It was a small-team effort, not a one-person show. I led the application architecture and built much of the core; our CTO set up the infrastructure and CI, shaped the database structure, and authored most of the specs (I reviewed them so the AI tooling could act on them); and a frontend engineer joined about a month in and owned much of the UI through the build. A further colleague came on near the end of the period to take on features.
By the end of December, about three months in, the product already carried a substantial feature set:
- Authentication & security — email/password auth, Google OAuth, magic links, CSRF protection, and hardened middleware.
- Professional onboarding — a multi-step flow with document upload, profile photos, and bio.
- Credential management — add/edit flows, AI-powered document extraction and auto-fill, expiration reminders, bulk upload, and access-gated document viewing.
- Company & vendor management — role-based company dashboards, company and vendor profiles, a verification dashboard, and vendor pricing and compliance setup.
- Compliance — a dashboard with violations management, alerts and cron jobs, and hierarchical country/state filtering.
- Associations, team & HRIS — association and invitation flows, multi-vendor invites, team role management, and HRIS import with in-app notifications.
- Messaging & search — a real-time messaging system, plus search and recommendations with endorsements.
- Admin & infrastructure — audit logs, security-incident tracking, a performance dashboard, and a monorepo with a CV-parsing worker.
Delivering that breadth on a three-month clock, with a small team, was the real challenge of Act I. The decisions that made it possible:
- Breadth on a real foundation, not bolted-on features. The temptation under a hard feature deadline is to bolt each new feature on however is fastest. Instead I made the foundational calls (a typed codebase, enforced module boundaries, a clean data-access layer, shared validation contracts) up front, because I was architecting for a team that was about to grow. Every feature landed on that base rather than beside it, which is what let the growing team build directly on the product instead of restarting.
- AI as a first-class feature, hardened early. The document-extraction pipeline — drop in a CV, get structured, verified profile data — was a headline capability from the start, so even early it ran through schema-validated output with a retry guard rather than hoping the model behaved.
- A daily line to leadership. From early on the owners joined a daily call, walking through what shipped and shaping what came next. The CEO acted as our product manager in those meetings — running UAT on completed work and driving feature and functionality improvements — so priorities were re-validated continuously and the three-month feature push stayed on track.
The outcome: a genuinely working, feature-rich product, solid enough to open fundraising conversations and built on architecture solid enough for the company to scale the team directly on top of it.