Why I Built a Change Script Generator

This is Product #6. The last one.

On February 11, I shipped my first product — an NHibernate code generator I built in two days. On March 26, I shipped this one. Six products in under two months, while working full-time. I'm still processing that.

But let me tell you about the tool first.

The end-of-sprint ritual

Your database schema changed during the sprint. A new column on Customer. A type widened from NVARCHAR(100) to NVARCHAR(200). A nullable column became NOT NULL. Someone dropped a column that was deprecated.

Now you need ALTER TABLE scripts to apply these changes to staging and production. So you open both schema versions side by side and start writing. Column by column. Checking types. Checking nullability. For one table, it's annoying. For ten tables after a sprint, it's an afternoon of error-prone tedium where a single mistake means a very bad day in production.

On every enterprise project I've worked on, this was my job. Compare the old schema against the new one. Spot the differences. Write the ALTER statements. Review them three times. Ship them carefully.

Two files in, one script out

ChangeScriptGenerator.exe Customer_old.sql Customer_new.sql

The tool takes two SQL schema files — before and after — and generates a ready-to-run ALTER TABLE script. Column additions, removals, type changes, nullability changes. It first shows you a clear diff with old and new definitions side by side. Then it outputs the SQL script with proper ALTER TABLE statements, timestamped in the output folder.

Review it. Run it. Done.

Scope discipline saved this product

The temptation was enormous. Handle index changes. Constraint changes. Column renames. Stored procedures. Support multiple tables. Add MySQL and PostgreSQL.

I locked v0.1 to columns only: adds, drops, type changes, nullability changes. SQL Server only. One table per file. These constraints match the rest of the toolkit, and they cover the vast majority of sprint-to-sprint schema changes.

If I'd tried to handle everything, this product would still be "in progress." Instead, it shipped.

Closing the loop

Product #5 tells you when your C# code has drifted from your database. Product #6 tells you when your database has drifted from a previous version of itself — and gives you the script to fix it. Together, they cover both directions of drift. That wasn't planned from day one. It emerged naturally from solving real problems.

The full toolkit, four layers:

• Generate — NHibernate entities from JSON (#1), POCOs from SQL (#2), Fluent mappings from XML (#3)
• Document — Markdown documentation from SQL schema (#4)
• Validate — Drift detection between SQL and C# (#5)
• Migrate — ALTER TABLE scripts from schema comparison (#6)

Each tool solves one problem. Each is a self-contained CLI. No dependencies between them, but they work together as a workflow: generate your code, document your schema, validate that everything matches, generate migration scripts when things change.

Six tools. 75 days. While working full-time.

I don't say that to impress anyone. I say it because before I started, shipping products felt like something other people did. The gap between "I could never do that" and "here are six of them" was smaller than it looked. Not because I'm special — because the problems were real, I'd lived with them for years, and the solutions were simpler than I expected.

Every one of these tools started the same way: a task I was tired of doing by hand. That's the whole secret, if there is one.

Available on Gumroad for EUR 15.