From proving to cementing
With the MVP doing its job in fundraising conversations, the mandate changed: stop proving the idea, start cementing the platform, hardening what was demoed into something durable and building the depth real customers would demand. As that happened, the company grew the engineering team, and the work became feature-based.
Direction ran through the CTO, not me
Day-to-day direction came from the CTO's daily meetings, and that division of labor 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) that everyone ran. A new engineer could pick up a feature and work in parallel without stepping on anyone or waiting for hand-holding, because the architecture corrected mistakes before review did. The enforced boundaries did the onboarding a manual handbook otherwise would.
My role was occasional, not managerial
The architecture I'd set was the baseline everyone built on; beyond that 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 when a new pattern was worth making the norm. The team itself shifted from proving the platform to deepening it: richer data modeling, a notifications engine built out across many event types, role-based routing restructured across the codebase, auth hardening, mobile polish, all features layered onto a base that didn't need re-laying.
The daily call with leadership ran throughout. Where Act I asked "what will convince an investor?", Act II asked "what will make a customer adopt, and stay?" Leadership brought the market and the customer; I brought what was buildable, at what cost, and what each choice meant for the architecture six months out. Combined with the CTO's daily engineering cadence, this kept work flowing as small, daily-demoable increments against a shared staging branch rather than multi-week dark periods.
The CEO joined those daily meetings and effectively acted as our product manager: running UAT on completed work, catching gaps before they reached customers, and driving a steady stream of feature and functionality improvements. A lot of the product's polish came from that tight loop — build it, have it acceptance-tested against real expectations the same week, refine. It meant the team was rarely guessing about whether something was actually done.