AI Build Log #002 Question: Does shared data require a shared codebase?

Two of my tools needed to share data. That seemed like a good reason to merge them—until I asked why. It sounded obvious. It wasn't.

This is Part 2 of a series — Part 1 covers how a wish for "better visuals" turned out to be a hand-edited JSON file quietly breaking every few weeks. This part picks up right after I found it.

Every time I opened that file, I braced for a syntax error. I'd broken it before, more than once, just moving a bracket. It wasn't a big problem. It was just annoying enough that I'd started avoiding it.

The obvious fix The editor already knows which channel and playlist a video belongs to. The analytics tool already has a database with almost the same information sitting in it, just structured for analysis instead of editing. So — merge the two projects. One codebase, one database, one place to change everything. It sounded simpler.

Why merge, though? Because they need to share data. Fair enough.

But does sharing data actually require sharing a codebase? I sat with that one longer than I expected. The honest answer was no — those are two different problems that happened to look like the same problem.

Then why did merging feel like the obvious answer? Because right now, they are coupled — just not on purpose. I'd kept these two projects separate a while back, for a plain reason: I didn't want changes in one to risk breaking the other. The editor needs to keep working even if analytics is mid-refactor or just down. If merging felt necessary, that meant the coupling I was trying to avoid had already crept in somewhere. So — where?

Where, exactly? While mapping out what would need to move, I found it: image prompts and file paths — data that's created and searched entirely from the editor — were living in the analytics database. Not because analytics needed to own them. They'd just gotten swept in, because the JSON-parsing pipeline that indexes videos happened to parse images too, and nobody had questioned it since.

That changed the question completely. It wasn't "these two tools need to merge." It was "ownership of a few specific things got scrambled, and now the wrong tool is downstream of the other."

What I actually decided Merging would have fixed the ownership problem too, but it would have cost me the thing I split them for in the first place: the editor staying usable even when analytics is broken or mid-refactor. That trade-off wasn't worth it just to fix one file.

So I kept the codebases separate — the editor stays an editor, analytics stays analytics. They now share a single Postgres instance, with each table clearly owned by one side:

  • The editor owns images — created there, searched there, written there
  • Analytics keeps owning video and scene indexing, the way it already did
  • Channel and playlist info — genuinely needed by both — gets served through a small shared API, instead of living in a file either side edits by hand

Nothing about this needed a merge. It needed clear ownership.

What's next The plan itself is simple to describe. Actually wiring it up — a startup script that brings both tools up together, a database migration, an API client in the editor — is a different kind of work, and a different kind of post. That's coming next.

Wrong assumption: Shared data means one project.

Discovery: The issue wasn't the project boundary. It was unclear ownership.

Next step: Build a shared backend that keeps ownership clear.