The key here is going to be the ratio between the number of times users request data in a read-only fashion versus updating the data. If the system has to re-write 5-10 thousand html files when somebody updates a record in the database, static pages would only be helpful if around half a million or more requests for the static data occur before another update.

Also, how long do you think it would take for the build_html() script to complete after being called? You need to realize that most users are going to try to verify that they're update "took" in the system by immediately checking for it. If the new static page hasn't been re-built, they're going to think it didn't update and either re-submit or call tech-support (you) to complain.

Ultimately, you need to get some numbers on how many files would be updated, how often updates are performed, how many times the static pages would be requested between updates, how much CPU time does the current fetch take, how much CPU time would the build_html() script take, etc... and decide if it would benefit your situation. I'd wager it might be more hassle than it's worth and it might even cause some breaks in the business rules...