A startup script is useful only if it refuses to claim the system is ready when it is not

Situation

A successful `docker compose up` does not guarantee that the application is usable. The database may still be starting, WordPress may still be installing an extension, or URL normalization may run too early. A helper that launches containers and immediately prints the site address simply turns a race condition into developer documentation.

Approach

I split startup into explicit phases: start Compose, wait for readiness, normalize environment-specific state, then print the usable URL. Error codes were preserved instead of swallowed, and critical shell commands were configured to stop the flow on the first real failure. The objective was diagnosable startup, not optimistic startup.

Outcome

We saw fewer strange failures caused by partially ready containers. When startup failed, the message appeared closer to the real cause instead of forcing developers to inspect the entire stack. Local onboarding became simpler as a result.