Navia AI — board advisory, venture research, and a high-risk feature shipped safely

Advice that stays technical

Coaching is a high-trust setting, so the central question is not how much the model can do but where it should. Much of the advisory work is drawing that line clearly: where AI can lead, where it should only assist, and where a human stays in charge of the relationship. The same judgment shapes how quality is measured. A product people lean on personally has to be evaluated on whether it is good for the person using it, not only on whether it responded.

Brand, market, and design research

Before public launch, I prepared a coordinated research package for the founding team and its working group: pre-launch brand diligence, and a competitive landscape drawn three ways — business model and capital, technology and AI architecture, and brand and design — against one consistent set of competitors, so a reader can follow any one company across all three views. It was delivered as decision-ready documents and the decks the team uses for venture planning.

The discipline mattered more than the volume. Every document opens with its evidence model and confidence tiers, and closes with what was not checked. Findings are sequenced as decisions on a dated clock, with a named owner for each open question, rather than as general advice. A figure that could not be sourced is labelled undisclosed instead of estimated. Most AI-assisted market research fails at exactly this point: it produces confident, uniformly toned claims with nothing underneath them.

The timing is most of the value. Diligence of this kind is cheap before there is brand spend, a fundraise, or an enterprise security review riding on the answers, and expensive afterwards.

The feature the beta was asking for

Beta users wanted to work on more than one thing at a time. The product coached a person toward a single goal; someone pursuing a second had to set the first aside. The request was multiple coaching projects per person — each with its own memory and its own feedback — and a way to manage challenges across them. It is also the kind of capability that gives paid tiers a reason to exist.

It had been deferred for a sound reason. The change reached into the most sensitive data the product holds: each person's accumulated coaching history, stored encrypted. Reshaping that record is the most dangerous operation in the codebase, because a coach that has forgotten you is worth nothing. The technical debt was not messy code. It was the absence of the safety machinery a change like this needs before anyone should attempt it.

Clearing the debt first

So the first deliverable was not the feature. It was the net under it: automated tests on the backend against a real database rather than mocks, component tests on the frontend, and an end-to-end browser suite that runs fully offline against fixtures built from real content shapes, so it cannot drift from production. Every external service — model APIs, payments, sign-in, push, voice — has a documented mocking boundary, and a call that escapes it fails fast rather than spending money.

The pipeline that runs those tests is deliberately separate from the deploy path, so that adding tests could never add a new way for a production deploy to fail. Writing the suites surfaced several latent issues on the first day. I fixed the ones that were plainly defects and handed the ones that were really product decisions back to the founder rather than deciding them for him.

Building the change so it could not lose data

• A data model that avoided a schema migration. Projects live inside the existing encrypted record, so encryption and key handling did not change at all.
• Entitlement derived, never stored. Which projects are active under a person's plan is computed on every read from a reproducible ranking. Upgrades and downgrades take effect the moment the plan changes, with nothing to reconcile — which removes a whole class of downgrade bugs before they can exist.
• One service layer owns the data. A single module is the only code allowed to touch project records, and its contract is written in the module: nothing in it logs or returns decrypted coaching content.
• Concurrency handled properly. The end-of-session memory merge never holds a database lock while a model call is in flight. It re-reads under lock in a fixed order so two writers cannot deadlock, re-checks the person's plan inside the lock, and commits once.
• Fail closed. A record that will not validate is never reset and written back, because that would overwrite recoverable data with nothing. A project deleted mid-session stays deleted; stale work is dropped rather than resurrecting it.
• Errors that cannot leak. Validation libraries tend to echo the value they rejected, and here that value would be someone's private coaching history. Every error path reports the kind and count of failure and nothing else — including the subtle case where the location of an error is itself user-derived text. Marker tests across the suites prove it.
• A rehearsed migration. An idempotent transformer with a dry-run mode, rehearsed against a scratch database, run in an announced maintenance window behind a verified backup, with restore as the rollback. It ran clean in production.

Taking review, and deleting my own work

My first rollout plan was built for a zero-downtime switchover the product did not need at its stage. The founder's review said the architecture was sound and the rollout was disproportionate. He was right.

I rewrote the design document first, so the repository never described behaviour the code no longer had. Then I removed the extra machinery in a single working session, against a written list of the safety properties that had to survive the cut, and verified each one afterwards with every suite green. Removing your own work while protecting what matters is a harder skill than writing it, and it is the honest answer to a question every founder asks a contractor: how do you decide how much engineering a problem deserves?

A working agreement for AI-assisted development

Like most new products, the application is developed with AI coding tools, which multiply both throughput and blast radius. My first commit was a provider-neutral working agreement for coding agents: one canonical guide, with thin adapters for each tool so the rules cannot drift apart per vendor. It sets a hard rule that no agent pushes to the branch that deploys to production, engineering principles that prefer the simplest implementation that meets the requirement, a test-cadence protocol, and a policy that test failures are reported and never hidden.

The founder has since extended that document himself rather than routing around it — and the proportionality principle my own rollout was judged against was one of his additions. A governance document its owner keeps amending is the best evidence the abstraction was right.

What this demonstrates

I make someone else's codebase safe to change quickly, and then make the change the team has been deferring: entering a production system I did not write, installing the safety net, shipping a risky data change with a rehearsed migration and a rollback, and leaving the team faster than I found it.

And I can do the venture work beside it — tell a founding team what is proven, what is assumed, and what is still undecided, before money is spent proving it. Most solo founders cannot otherwise buy those two things without hiring two people who will not talk to each other.