--- title: "I bolted a review overlay onto a Classic ASP app" canonical: https://dxdev.com/blog/2026-05-08_review-overlay-classic-asp/ datePublished: 2026-05-08 --- At 4:06 PM on May 8, I merged the checkout feature branch into the Packages redesign branch, pushed to an internal host, and sent the reviewer a URL. That part was routine. What was different was the page he loaded. Alongside the Packages page stepper redesign, there were 7 annotated review points rendered inline, each one sitting next to the component it described, each one carrying a design decision and a checkbox. That was the first time I had done design review that way. The review-block layer of the engine that produced it took 72 minutes to build, on top of a foundation I had laid earlier that day. ## how design review had worked before the platform is a 25-year-old Classic ASP codebase. Review had worked the same way for most of my time with it: build a thing, screenshot it, paste the screenshot into a JIRA comment, wait for the reviewer to tell me what looked off. The comments came back as text pointing at pixels in a frozen image. Nothing linked to anything. If the question was "does this purple match the toggle," the answer arrived two messages later in a different thread, and I had to look up which toggle and which purple. I had internalized that as normal. It was not a problem I was planning to solve. The product was old; the review process would be clunky. That was wrong. ## phase 1: the foundation The checkout ticket was the tournament checkout page, a cart-driven Purchase Summary view for tournament organizers. Around 1 PM, in the middle of wiring the cart model, I built the first layer of what I started calling the visual-walkthrough engine: an ASP `include` file, a page opt-in mechanism, and JSON sidecars at `ai/design/ITEM-XXXX.json`. Each sidecar listed the highlights for a page with anchors that referenced elements by selector. Any page that included the engine file and pointed at a sidecar got the highlights rendered on load. Nothing in the database. No dependencies outside the repo. I shipped that as part of checkout Phase 2 and filed a follow-up ticket to build the DB registry and staff sidebar. V1 was already useful for review even without those things. ## phase 2: the review blocks The foundation put highlights on the page. What it did not do was carry the design reasoning. A yellow box around a stepper cell does not tell the reviewer why I chose 5 cells instead of 4, or why I picked `#5640a3` for the outline instead of a different shade. Starting at 2:54 PM, I built V2: inline review blocks that hydrated from two fields in the sidecar, `designNotes` and `designDecisions`. The `designNotes` field held the reasoning for each highlight. The `designDecisions` field held the specific yes/no question. When the block rendered, it showed the note and a checkbox. The reviewer's response could post back to `/ajax/design-brief-content.asp`, which logged it server-side. The full brief for the Packages R2 pass lived at `ai/design/ITEM-XXXX-r2.md`. Seven highlights. Decisions like: does the 1px `#5640a3` outline on the stepper cells match the Monthly/Annual toggle? Does the `#01b300` active fill read clearly at that size? Does splitting the Teams section into 2 rows with three purple subtitles aligned under the columns feel right, or too busy? Those questions existed before I built the engine. They were in my head, in scratch notes, in prior JIRA comments. Moving them into `designNotes` and `designDecisions` in a sidecar file did not create new information. It moved the information to the place where it mattered. ## using it immediately The merge and push at 4:06 PM were the end of the session. I updated JIRA comment 60028 to point the reviewer at the walkthrough, moved a cart-model heads-up out of comments into Dev Notes, and that was it. The reviewer had an internal host and 7 decision points waiting on the live page. I had not planned to build review tooling that day. Checkout Phase 2 was the job. The tooling emerged because I was already touching the ASP include layer and already writing the design brief for the R2 pass. The gap between "I have these decisions written down somewhere" and "the reviewer can see them on the actual page" turned out to be about 72 minutes. One thing I was watching: whether the walkthrough would stay lightweight as more pages and more decision points accumulated. A system that adds friction proportional to the number of reviews it tracks is a system people stop using. The JSON-sidecar model kept each page's state in its own file, which meant the complexity was local. Whether that held once the follow-up ticket's DB registry came in was still open. ## what the commit trail shows 338 commits went out that day across 16 repos. The visual-walkthrough engine was not the main event. Checkout Phase 2 shipped. The agent dashboard got its inline session spawn working. The calendar composer landed. The nightly cron went live. The walkthrough was one commit in a long day. That is the point. It was not a dedicated project with its own sprint slot. It fit into the existing session because the gap it was closing was immediate and concrete. The design decisions for the Packages redesign existed. The reviewer needed to see them. The fastest path to that was building the tool and putting it on the page. The 72 minutes bought one specific thing: the 7 checkboxes on the Packages R2 page now sit next to the stepper cells they ask about. When the reviewer answers whether the 1px `#5640a3` outline matches the Monthly/Annual toggle, the outline and the toggle are both on the screen with the question, and the answer posts back to `design-brief-content.asp` instead of turning up two messages later in a thread about a frozen screenshot. What I still can't say is whether that holds when the follow-up ticket moves the sidecars into a database. Each of those 7 decisions currently lives in one JSON file, and I'll only know the engine stayed lightweight if a page with 7 more decisions is no harder to review than this one.