From First MVP to a Team-Built Platform: Architecting an AI Startup in 9 Months

The setup

I joined Lorica — an early-stage startup building the compliance and vendor-coordination infrastructure for the private security industry — when it was in its infancy. Most security firms still run on phone calls, spreadsheets, and fragmented systems to manage employees, vendors, and credentials, and that fragmentation creates real risk: compliance gaps, failed audits, insurance disputes, operational drag. The work split cleanly into two acts: a fast first sprint to a product real enough to raise on, and then a growing team to harden that product into a platform. As a founding engineer I led the application architecture and built much of the core, working alongside our CTO and a small team, in a daily cadence with the company's leadership throughout.

Act I — building the first working product

The brief from day one was a real, working product, not a throwaway demo, with the feature-heavy push due in roughly three months. It was a small-team effort: I led the application architecture and built much of the core, our CTO owned the infrastructure, database structure, and specs, our CEO acted as product manager driving features and UAT, a frontend engineer joined about a month in, and another engineer came on in December to take on features. By the end of December the product already handled authentication, professional and company onboarding, credential management with AI document extraction, a compliance dashboard, vendor and team management, messaging, and search.

The hard part was delivering that breadth on a three-month clock without bolting features on however was fastest. I made the foundational architecture calls — a typed codebase, tooling-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 team build directly on the product instead of restarting.

Act II — growing the team

Once the MVP was doing its job, the mandate shifted from proving the idea to maturing the platform. The company grew the engineering team and the work became feature-based. Day-to-day direction came from the CTO's daily meetings, not from me — and that worked because of how Act I was built. The team largely didn't need a separate set of instructions to stay aligned: the foundation was already typed, bounded, and convention-driven, with module boundaries enforced by tooling and a single pre-push quality gate (type-check, lint, format, tests). The enforced boundaries did the onboarding a manual handbook otherwise would.

My own role with the team was occasional, not managerial: the architecture I'd set was the baseline everyone built on, and I'd join the odd PM 1:1 or an ad-hoc call to detail how a part of the architecture should fit together or to update the shared coding standards. The CEO acted as our product manager — joining the daily meetings, running UAT on completed work, and driving feature and functionality improvements. Because the foundation held, new engineers became productive quickly and could work in parallel without stepping on each other — features landed as small, reviewable, daily-demoable increments rather than multi-week dark periods.

The AI workflow I built, not just used

Much of this was AI-assisted, and that's most of the reason a small team could reach a credible MVP and then mature a full platform inside nine months. But generic AI assistance produces generic code. The real leverage came from teaching the tools this codebase:

• Conventions-as-skills. Focused, on-demand assistants that each owned one concern — architecture conformance, security review organized by request lifecycle, and test trustworthiness — loading only the rules relevant to the change at hand.
• Specialist reviewer agents. Narrow reviewers with distinct jobs: one that verifies a refactor is fully integrated and the old code is actually gone, and one that encodes the team's accumulated code-review standards so recurring issues get caught before human review even starts.
• A local mirror of CI review. The same review the pipeline posts on a pull request, runnable locally — so I saw the verdict before opening the PR, tightening the loop from hours to minutes.
• End-to-end workflow automation. The path from "ticket assigned" to "PR open" — spin up an isolated branch from a ticket with full context, open a templated PR linked back to the tracker — collapsed to a few keystrokes.

The point wasn't novelty. It was that every recurring judgment call I made got captured as tooling, so the next contributor — human or AI — made the same call automatically. That compounding is a large part of why velocity climbed the way it did. AI didn't replace architectural judgment; it compressed the distance between a decision and a working, type-safe implementation of it.

What I'd do differently

A case study that's all wins isn't honest. Three things I'd genuinely change:

• Treat the AI's instructions as a first-class, continuously maintained artifact. On a fast-moving stack the models' training data lags reality, so the quality of the instructions largely determines the quality of the output. Where I let those instructions go stale, the inconsistencies showed up later.
• Commit to spec-driven development more consistently. I adopted it from day one — authoring specifications before implementation, before the approach was widely known — because a clear spec is the best prompt. But the discipline frayed under deadline pressure; I'd keep specs as living documents wired into the workflow.
• Build in deliberate refactoring passes earlier. An architecture set fast and early, under deadline pressure, accumulates drift that's invisible from the inside. Scheduling intentional clean-up passes during the build is far cheaper than rediscovering that drift later.

The takeaway

The hard part wasn't the MVP itself; it was building it so a team could build directly on top of it without restarting. The architecture I led, under deadline pressure, became the foundation the team scaled into a platform. The lesson I carry into every engagement: strict, machine-enforced architecture is what turns AI-assisted speed and a growing team into multipliers instead of liabilities.

That's the overview. The rest of this series goes deep on each part of the story, from the problem and the MVP through the architecture, the AI workflow I built, and the trade-offs and results. Start with Part 2 below.