I Put All Three Apps Side by Side—and Found Out They Weren’t Actually One Product

For a while, I had three things I was proud of.

Verbal.

Quant.

Intelligence.

Each one had grown far beyond its first version.

Verbal had the deepest actual learning loop.

Quant had become a serious subject architecture with practice, review, analytics, tests and evidence models.

Intelligence had become a separate learner-model application instead of another dashboard.

From the outside, this looked like an ecosystem.

Then I stopped looking at them one at a time.

I audited all three together.

That was uncomfortable.

Because the moment I treated them as one product instead of three impressive projects, a much harder question appeared:

Do they actually agree with each other?

The answer was:

Not enough.

Three strong foundations can still form a weak system

Individually, each project had real substance.

Verbal had the most complete subject-learning experience.

Quant had broad modelling and a much more ambitious architecture than its current content bank.

Intelligence had a serious inference pipeline and dedicated surfaces for analysis, planning, retention, skills and mocks.

None of those descriptions were false.

But they were incomplete.

A learner does not care that three repositories are individually interesting.

They care whether the whole thing behaves like one dependable system.

Can I sign in once?

Does progress belong to the same account everywhere?

Does Quant understand what Intelligence recommended?

Does Intelligence actually receive the evidence produced by Verbal?

If I switch devices, is the same learner still the same learner?

If an event retries, does it get counted twice?

If one app says I am synced, is that statement actually true?

That is where the ecosystem stopped being a diagram and became an engineering problem.

The first audit result was humbling

The test results looked respectable until I stopped reading them selectively.

Verbal had a large amount of working product behaviour.

Quant had many passing checks.

All the dedicated Intelligence tests passed.

That sounded reassuring.

Then I looked across the repositories rather than at the flattering subset.

There were stale migration expectations.

Old checks.

Missing imports.

TypeScript failures.

Tests that were not testing what I thought they were testing.

Legacy code paths.

Different assumptions about the backend.

The lesson was immediate:

A passing subsystem is not the same as a passing product.

That sounds obvious.

It is very easy to forget when the green checkmarks belong to code you spent days building.

Intelligence was not actually receiving the subject apps’ reality

This was probably the biggest architectural gap.

Intelligence expected a canonical stream of learning evidence.

Attempts.

Sessions.

Reviews.

Mocks.

Interventions.

Derived learner state.

But Verbal and Quant were still writing through their own older systems.

That meant something important:

Putting all three apps on the same Supabase project would not magically connect them.

Running more migrations would not magically connect them.

Using the same email address would not magically connect them.

The products needed explicit adapters.

Actual translation between what the subject apps record and what Intelligence understands.

Until that exists, the "ecosystem" is partly conceptual.

That distinction matters.

The database was carrying history from different eras

This project grew quickly.

That means the data architecture grew in layers.

Verbal had its own history.

Quant inherited some of that history and added more.

Intelligence introduced a cleaner shared model.

The result was not one elegant backend.

It was several generations of thought sitting beside each other.

That is normal during development.

It becomes dangerous if I pretend it is final.

Different migration folders can describe overlapping truths.

Old table names can remain technically valid while representing outdated ideas.

Tests can still expect migrations that no longer exist.

One client can assume a permission another client should not have.

Eventually somebody has to decide:

What is canonical now?

That became the shared-platform work.

I stopped thinking in terms of “connect the apps”

That phrase was too vague.

Connect how?

A link in the navbar?

Shared authentication?

Shared data?

Shared billing?

Shared recommendations?

Shared sync?

Shared settings?

A learner can experience one ecosystem only if several different layers agree.

Identity.

Access.

Evidence.

Content versions.

Sessions.

Progress.

Recommendations.

Payments.

Offline state.

Account ownership.

That is why the next phase became much more boring and much more important.

Not another feature.

A platform contract.

Verbal, Quant and Intelligence needed clearer jobs

The audit actually made the product boundaries stronger.

Verbal should teach, practise, assess and repair Verbal.

Quant should teach, practise, assess and repair Quant.

Intelligence should interpret evidence, coordinate preparation and measure whether interventions helped.

The shared platform should handle the things none of them should reinvent independently:

Identity.

Access.

Sync.

Content versions.

Event integrity.

Shared settings.

Device state.

Account ownership.

Operational rules.

That separation felt much cleaner than asking every app to solve every problem.

Quant also looked more finished than it was

The audit forced me to separate architecture from content again.

Quant had a large syllabus structure.

Many subtopics.

Reference cards.

Analytics.

Review.

Test infrastructure.

But the usable question bank was still tiny compared with the surface area of the product.

That matters.

A beautiful topic map is not topic coverage.

A drill engine is not a drill library.

A test runner is not a test bank.

A readiness model is not validated readiness.

This was not new information.

But seeing it beside Verbal and Intelligence made the imbalance harder to ignore.

The product architecture had raced ahead of the learning material.

Verbal had the opposite kind of advantage

Verbal was less architecturally glamorous in some places.

But it had something the other two needed:

More actual learner flow.

Real vocabulary.

Real practice.

Real review.

More established behaviour.

That made it the best source of truth for what the shared platform would eventually need to preserve.

The platform could not be designed only from the cleanest new schema.

It had to respect the working product that already existed.

That is a much harder constraint.

The audit changed how I define “done”

Before this, I could finish a feature and ask:

Does it work?

Now the question is larger.

Does it work inside the product?

Does it survive account switching?

Does it survive retry?

Does it survive offline?

Does it agree with the other apps?

Can the server verify it?

Can historical progress still be understood later?

Can the learner recover after interruption?

Can I explain what the system knows and why?

A feature can be locally correct and globally wrong.

That is the kind of problem I did not have when the whole project was 32 questions in one app.

This was probably the first real ecosystem audit

Part 28 was a checkpoint.

This was different.

A checkpoint asks:

What have I built?

An audit asks:

What survives when I stop being generous to my own work?

That second question is much less fun.

It is also much more useful.

The audit did not tell me to throw everything away.

Actually, the opposite.

There was enough good architecture to preserve.

The problem was the foundation underneath it.

The next step was not another redesign.

It was making the three products agree about reality.

I finally understood the difference between a suite and a system

A suite is several products.

A system is several products that cooperate reliably.

I had the first one.

I was building toward the second.

That sounds like a small wording change.

It completely changed the roadmap.

The interesting work was no longer:

What else can these apps do?

It became:

What has to be true underneath them before I can trust what they already do?

That is a much less exciting question to put on a landing page.

It may be the most important question I have asked in this project so far.