If you can render things to static files, or functions, then your plan will work. We don’t “run” anything (except your functions) at browse time - so if you can find a workflow to “do whatever you intend” during build - so the static files and functions accomplish your goals, then you can do it here 
Files from your prior build(s) are NOT AVAILABLE in the build environment - so any files you want to carry forward from an older build and reuse without change need to be either:
- in git
- in our build cache (which only caches dependencies by default, but can be used to cache anything you want!)
- fetched live from your site (you have full outgoing internet access). This seems least efficient, but is within the realm of possibility particularly for specific single files that are harder to generate - e.g. results of a long API call that only change once a week that you can “reuse” for builds during that week. For a site-wide effect like I think you are describing, it would probably not result in much of a speedup to download much of your site like a crawler, during build.
You can manipulate and debug your usage of our build cache using plugins like these:
(note you need to replace YOUR_TEAM_SLUG with your team’s slug - or start from your site listing page, click plugins, and search for cache)
(or, you can roll your own cache handler based on your examination of the source code for our build environment: GitHub - netlify/build-image: This is the build image used for running automated builds ).
Note that no matter how you approach cache manipulation during build, please make sure your build works WITHOUT cache - as it is usually but not 100% available, and you will need to be able to (re)generate it from scratch on any build request.
Not sure this will help, but like I said, we aren’t scully experts, so if that doesn’t make sense, could you try explaining your goal in a bit different way, and we’ll get our best scully minds to take a look?