What it is
The Application Template is a working project skeleton plus a pattern library, covering the five-project solution structure we use for internal web applications, the authentication and authorization approach, database access conventions, deployment steps, and a growing set of documented pitfalls. A new application starts from this rather than from scratch.
Why it mattered
By the time three internal applications had shipped, the same problems were being solved for the third time, and worse, the same mistakes were being made for the second time. Each application had independently discovered how to derive its own base path when hosted under a virtual directory, how to configure the web server correctly, how to structure authorization. Consolidating that into one place was less about saving setup time and more about stopping repeat failures.
What makes this different from a generic starter
The distinguishing property of this template is that almost nothing in it is theoretical. Every pattern and every documented pitfall traces back to a specific incident in a named project, with the symptom recorded alongside the fix.
The clearest example: one project’s background retry mechanism had no memory of prior failures, so it retried a permanently broken operation every few seconds and logged an error every time, for over five weeks, producing roughly 1.3 million log rows and about forty-one gigabytes of data before anyone noticed. Nothing crashed. The existing guidance in the template already prevented a bad tick from taking down the host, but it did nothing about a single stuck item being retried forever. So a bounded backoff pattern went into the template, tracking consecutive failures per item and stepping the retry interval down to a low but non-zero rate, low enough to stop flooding logs, non-zero so the problem stays visible.
Another entry came from a web server hosting incident: the setting that warms an application on startup does not apply after a later recycle, so a scheduler application with no regular user traffic can sit cold and silently stop working while the hosting environment still reports healthy. That pitfall is now a named symptom-and-fix row rather than knowledge in one person’s head.
A third came from building a job monitoring page and hitting a two-part permissions gap in the database’s own scheduling metadata: the built-in roles grant access through stored procedures but not to the underlying tables, and granting permissions to the documented login was insufficient because the actual connection used integrated security, meaning the real connecting identity was a machine account rather than the expected login. Both halves are now documented together, including the step of verifying which principal is actually connecting before granting anything.
The result
The template now covers user interface patterns, database patterns, authentication, data access, data warehouse conventions, integrations, and deployment, each as its own reference document. The pitfalls table has grown into the most valuable part of it, since each row represents an outage or a debugging session that will not need repeating.
Where it stands
Actively maintained, and updated whenever a project surfaces something worth carrying forward. The convention I follow is that a lesson learned on one project does not count as captured until it lands here, because that is the only place a future project will actually see it.