You would not be starting from zero. Four products are built and running, on two deliberately different architectures. What follows is what exists today, what is missing, and how I know. Every line is traceable to a dependency-graph extraction of a named commit.
Patterns across the portfolio
Two spines, on purpose. Personal and local-first products run on Expo with data on the device. Multi-user business products run as a monorepo with Express, Postgres and a generated API contract. That second spine already carries authentication, a generated client shared across web and mobile, and AI services in another product in the portfolio. Several more products exist and are deliberately left off this sheet.
Engineering signals
Across the systems reviewed so far: no detected import cycles in the dependency graphs reviewed; contract-generated API clients and validation; versioned data migrations; domain-specific ontologies and state models; deterministic checks around AI output; automated evaluation harnesses; and an existing test suite.
These are structural signals, not a claim of production readiness. They show that the work has moved beyond generated interfaces into connected systems that can be inspected, tested, challenged, and hardened.
Where I would want you first
how I know all of this
Static dependency-graph extraction, per repository, at a named commit, AST only. It proves what exists and how it connects. It does not prove correctness, security, or test coverage. Node and edge counts describe structure, not maturity. I am happy to walk any repository with you and let you judge for yourself.
The question is no longer whether AI can produce working software here. The next question is how well this software holds up under experienced human engineering review.