Mike, your thinking is correct and your equation is close to correct. Here's what I just tested on my high-rate data files and it worked:
Ac = Ac + (acceleration_current - g) * (timeNow - timePrevious)
Do this every cycle of the code, and when Ac goes negative you have apogee. In my experience, this happens about 2 seconds after true apogee due to various sources of error. Still good enough for deployment above 30K ft.
Your idea is a simpler idea compared to what I do. I use the data to integrate velocity and altitude at 1000Hz, and use a negative velocity value as one trigger for apogee. I also use a smoothed velocity off the barometric pressure sensor as a second trigger.
Here is my code in case you want to use it:
//calculate the new acceleration based velocity
//this makes the apogee event mach immune
accelVel += (accelNow - g) * (timeNow - timePrev);
//calculate the new acceleration based altitude
accelAlt += accelVel * (timeNow - timePrev);
Proper calibration of these MEMS sensors is critical. If your Z-axis is outputting -10 when its perfectly aligned vertical (minus g), then this is a bias in the sensor called an offset. The cumulative error of this value will make your apogee estimate less accurate. Store this value in EEPROM and subtract it off of the acceleration readings each cycle before conducting calculations with it. The offsets don't change that much over time, and I have an entire routine dedicated to calibrating my system.
I'm nearly finished with the prototype of my 3rd generation system, which has a lot of similarities to yours. It records data at 1300Hz and sends telemetry at 20Hz over 433Mhz LoRa.