How to Track Older Web Projects Without Losing Your Mind
Keeping a history of your web development work is one of those things everyone says they should do and nobody actually does until something breaks. I started tracking project versions the hard way when a client asked me to replicate a layout from three years ago and I had no idea what CSS framework or build tool they were using. That was mostly because I hadn't written anything down. Most developers use current tools to track current work. Git handles the versioning of code. Jira or Notion handles tasks. But there's a gap when you're dealing with legacy projects, archived codebases, or sites that still need maintenance long after the original team has moved on. A Web Development Tracker Vintage system is basically just a structured way of recording what existed, what tools were used, what the deployment looked like, and where the critical decisions live now that the people who made them are gone. I built my own for exactly this reason. After spending four hours just figuring out that a client's production site was running on a forked version of a 2016 build tool with a custom post-processing script I'd never seen, I decided to do better.
What You Actually Need to Track
Here's the list I use. It's not exhaustive but it covers the stuff that tends to come back to bite you. Core stack information: Framework, library versions, build tools, bundler configuration, and any custom plugins. Version numbers matter more than you think because dependency drift is real. Hosting and deployment: Where it lives, how it gets there, what the CI pipeline looks like if one exists, and whether there are environment-specific configurations that aren't obvious from the code alone.
Critical dependencies and their versions: Package.json lock files are part of this. So is composer.lock, Gemfile.lock, or whatever your ecosystem uses. The moment someone runs npm install without a lock file on a project older than eighteen months, you're rolling the dice. Known issues and workarounds: Document these even if they feel obvious. The workaround for that one Safari rendering bug you patched in 2019 will matter to whoever picks this up in 2027. Custom scripts and automation: These are the silent killers. A deployment script buried in a README that's slightly different from the one in the repo can save you an hour or cost you one depending on which one you follow.
Get the Full Details
How I Set Mine Up
My tracker lives in a simple markdown-based wiki inside each project repository. It's not fancy. Each project gets a TRACKER.md file at the root with the sections I listed above. When I onboard onto a new project, I fill this out during the first week. When I leave a project, I update it with anything I learned that wasn't already documented. For team projects, I push this to a shared knowledge base so the information survives when people rotate off. I know some teams use Confluence or similar tools but I found those get stale fast because nobody wants to maintain a separate document that isn't part of the code itself. One edge case I hit recently involved a project where the Web Development Tracker Vintage documentation pointed to a specific version of a package that no longer existed in the registry. The package had been deprecated and replaced with a fork under a different name. My workaround was to check the project's original git history for any commit that touched the dependency configuration file and use that to identify the actual versions in use at the time, rather than trusting the tracker alone. The tracker was technically correct for what was documented but reality had diverged. I added a note to that effect in the file so the next person wouldn't make the same assumption.
Common Mistakes People Make
People tend to over-document the surface level stuff and miss the things that actually matter. They write down that the project uses React but don't note that it's React 16 with a custom fork of react-scripts that adds a Babel plugin for CSS module namespacing. Six months later someone clones the repo and the build breaks because the CSS comes out unstyled and nobody knows why. Another mistake is treating the tracker as a one-time thing. The value drops to zero if it's not updated. I've seen trackers that are more outdated than helpful because they were written during onboarding and never touched again. Set a rule to update it whenever you make a structural change to the project.
Limitations to Be Honest About
This approach works well for small to medium teams and individual developers. It breaks down at scale where a single markdown file per project becomes unwieldy. Large organizations usually need something more structured with searchable metadata and relationships between projects. Tools like Backstage or internal wikis with proper taxonomies serve that purpose better. There's also no way to automatically capture everything you need. Some things simply require human judgment about what to record. A build tool configuration change might seem minor but it could be the only thing standing between a production site and a complete outage. Deciding what counts as minor is the hard part and it's something you learn by making mistakes. If you're looking for something pre-built, there are several open source project documentation templates on GitHub that you can adapt. None of them are perfect out of the box but they give you a starting point that's better than a blank page. The one I come back to most often is the developer experience kit that includes a project info template but you'll want to strip out the sections you don't need and add the ones specific to your workflow.
