Building FurballRescue:
AI as a Development Partner

We started with an old custom .NET MVC application that Lab Rescue of the LRCP had been using since 2012. It tracked animals, foster families, medical records, and adoptions — and it had served the organization well for over a decade. But we knew there was an opportunity to do much more.

Foster-based rescue organizations — the ones without a physical shelter, relying entirely on volunteer foster homes — were underserved by every product on the market. Most rescue software was built for brick-and-mortar shelters or municipal animal control. We wanted to build something purpose-fit for foster-based rescues, and we decided to use AI as deeply as we could throughout the entire process.

If this were a marketing piece, we'd skip this part. But it's the most useful section for anyone thinking about using AI for real product development.

The first rewrite came out as a Blazor Server application. It worked — Claude had successfully reverse-engineered the legacy domain — but Blazor relies on persistent SignalR WebSocket connections for every active user, which wouldn't scale well for a multi-tenant SaaS product with many concurrent users across many organizations. We pivoted to ASP.NET MVC with server-rendered Razor views. Straightforward, stateless, horizontally scalable.

Then there was the database.

We started with SQLite — lightweight, no external dependencies, perfect for getting features built quickly. When it came time to deploy, we invested heavily in a sophisticated replication setup using Litestream on Azure Container Apps. The idea was elegant: SQLite on fast local ephemeral disk, with Litestream continuously replicating WAL changes to Azure Blob Storage. Near-zero latency writes, one-second durability.

The reality was a gauntlet. Litestream's documented directory replication mode silently didn't work in v0.5.x. Container Apps' ephemeral storage meant every restart wiped everything — and health probes triggered database provisioning before the restore finished. Azure Files' SMB mounts were incompatible with SQLite's WAL mode, causing silent corruption. Git Bash on Windows silently mangled Linux paths in Azure CLI commands, setting environment variables to C:/Program Files/Git/data instead of /data. We generated pages of hard-won operational knowledge.

It all worked, eventually. Then we realized that per-tenant PostgreSQL on Azure's managed Flexible Server would give us everything we needed — real multi-tenancy, proper concurrent access, managed backups, no ephemeral storage gymnastics — for about the same cost. We migrated. The Litestream documents went to the archive.

None of this was wasted. Each wrong turn clarified what we actually needed. The SQLite phase let us build features without worrying about database infrastructure. The Litestream phase taught us exactly what our deployment requirements were. And AI was the one doing the bulk of the implementation work at each stage — including the migrations between them. The cost of a wrong architectural bet was days, not months, because the rework was AI-assisted too.

We approached testing through Behavior-Driven Design, and we were thorough about it.

Every user role in the system was audited: what each role needed to accomplish, what permissions it held, what the testable behaviors should be. All 35 permissions were traced through roles, controllers, and views to verify the authorization matrix. Every controller action was checked for test coverage, and gaps were filled. Tests were then evaluated for substance — we wanted meaningful scenarios that validated real business behavior, not trivial assertions.

The result was 265 BDD scenarios across 53 feature files, running as integration tests that drive a real browser against a real database. They run on every push through GitHub Actions.