Trade-offs, Mistakes, and Results

Challenges and trade-offs

• Speed now vs. survivability later. The whole of Act I was a bet that investing in real architecture under a three-month feature deadline would pay off in Act II rather than slow the build to a crawl. It was the right call, but a genuine risk made with the clock running.
• A bleeding-edge stack has a tax. Living near the front of the version curve meant breaking changes ahead of every tool's training data. The mitigation, read the current docs before writing against an unfamiliar API rather than trusting recall, was slower per task but avoided whole classes of confidently-wrong code, and it was a rule the whole team could follow.
• A growing team on one shared codebase. More contributors means more merge surface. The architecture absorbed most of it; decoupled modules and enforced boundaries kept conflicts localized, and combined with the CTO's daily cadence and a discipline of small, daily-demoable changes, integration stayed cheap.
• Deliberate deferrals. Some cross-cutting cleanups were consciously postponed, explicit trade-offs made with the owners to ship value over polishing internals, which accrued real interest paid down later. Naming them as conscious debt, rather than pretending they didn't exist, is what kept them manageable.
• Modeling complexity head-on. The relationship and records model carried nuance that no off-the-shelf schema anticipates, and getting it wrong would have corrupted everything downstream. It absorbed disproportionate design time precisely because it was load-bearing.

What I'd do differently

A case study that's all wins isn't honest. Watching a teammate's later v2 rework of parts of the platform was a useful mirror; it surfaced decisions that, made fast under MVP pressure, could have been cleaner or more consistent. 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. I invested in keeping the conventions aligned with the latest framework information, but I'd go further: more explicit conventions, more worked examples, and tighter feedback from the linting rules back into the instructions. Where I let them go stale, the inconsistencies showed up later as exactly what a rework cleans up.
• Commit to spec-driven development more consistently. I adopted it from day one, before the approach was widely known, authoring specifications with a dedicated spec-kit tool before writing implementation; the project's very first commit came from that spec template. The bet was right, 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, so they keep steering both people and agents.
• Build in deliberate refactoring passes earlier. An architecture set fast and early, under deadline pressure, accumulates drift that's invisible from the inside. Rather than treating a later rework as a verdict, I'd schedule intentional clean-up passes with fresh eyes during the build, not only after. Catching drift in motion is far cheaper than rediscovering it in a v2.

Results

• Act I — a working product, with a small team. A genuinely usable, feature-rich product delivered in about three months, broad enough to tell the full platform story and solid enough to support the owners' fundraising conversations, and built to be scaled on rather than rebuilt.
• Act II — a matured, team-built platform. A growing engineering team turned the MVP into a durable platform with operations laid out top-down: credential and compliance tracking with proactive expiry notifications, a first-class relationship graph between organizations and individuals, a dashboard that surfaces day-to-day operations and costs at a glance, AI-driven onboarding, and a deepened feature set, with multiple engineers committing in parallel without the architecture fraying.
• An AI surface that ships reliably. Schema-constrained extraction with sensible failure handling, dedicated background processing, and a model-agnostic abstraction that keeps provider choice a configuration detail.
• A product steered daily. A standing call with leadership, first focused on the investor story and then on customer adoption, meant direction was corrected in days, not sprints.

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 a fundraising deadline, became the foundation the team scaled into a platform, and AI-assisted speed plus a daily line to leadership kept the work pointed at the right problem.