A note about this build log entry: I published this after the week it covers. DevNitro reconstructed a draft from work-related entries in my journal, Git commit history, and time tracking. I reviewed, edited, and approved the final post. The story reflects what I knew and built at the time.

From the Backlog to the Build Log

Week of October 17 - October 23, 2025

What I Worked On

Last week I closed with SQLite support unfinished in GCT. This week the migration framework caught up to all three database providers. I refactored SQL statements for cross-database compatibility, normalized the Users table so it doesn't lean on SQL Server specific syntax, and built provider-specific journal handling so SQL Server, Postgres, and SQLite each track their own migration state correctly.

The bigger decision landed midweek. Instead of building a separate migration tool for client projects, GCT itself will ship the migration tool, and each client's version will be built on top of it. That keeps one codebase in sync everywhere instead of maintaining a fork per client. I wrote up a Client Migration Integration Guide to go with it.

What the AI Did Well

Rewriting SQL statements across three dialects is exactly the kind of mechanical, high-surface-area work AI handles well. Removing dialect-specific calls, normalizing the Users table, and wiring up provider-agnostic journal handling touched a lot of small spots across the codebase, and the AI worked through most of them without me reviewing every line.

By midweek the framework created and seeded all three databases correctly in one pass. That's the payoff from last week's open gap: the seed data path that wasn't working got fixed, and the architecture held up under real testing across SQL Server, Postgres, and SQLite.

What Needed Correction

Folding the client migration tool into GCT wasn't clean. Once the new framework landed, BlankSite's migration tool started throwing errors across all three database providers, and I spent real time chasing that down before it worked.

I also lost a chunk of a day fighting dotnet SDK behavior on Linux while trying to get the refactored migration tool running there. It wasn't a great day, and I said so at the time.

What Shipped

GCT's migration framework supports SQL Server, Postgres, and SQLite, and it creates and seeds all three from the same codebase. The Client Migration Integration Guide is written, and GCT's own test suite is back to passing after the migration changes landed.

BlankSite's migration tool still needs to catch up to the new framework, and that carries into next week.

The Numbers

Category Hours
Product / Features 42h 6m
Content 10h 36m
Community 1h 17m
Business 0h 28m
Total 54h 27m

Most of the week went into the prototype's database layer, with a smaller slice on HowdyChad video work.

Getting one migration framework to behave identically across three database engines is unglamorous work. It's also what makes a platform usable regardless of what database a client already runs, and this week it started to hold up.

Curious how this site was built?
Watch the 5-minute walkthrough at devnitro.com →

An AI built this blog (but not this post)

This entire blog system (domain models, database, services, UI, auth, etc.) was built by DevNitro on its own in 95 minutes. I recorded every second.

    We respect your privacy. Unsubscribe at any time.

    Built with Kit