Every framework has a lifecycle, but most leave you to reverse-engineer it from console logs and stack traces. KickJS is unusually explicit about its phases — there are three of them, the firing order inside each is documented, and the framework will throw at boot if you wire up something that violates the contract. That clarity is a feature: it means you can pick the right hook the first time instead of discovering at 2am that your DB pool was constructed before the config adapter had loaded its env vars. This article walks the three phases, the ordering rules inside each, and the contracts you can rely on at each step. The three phases A KickJS process has exactly three phases, and they happen in this order: Setup — everything that runs once during bootstrap() . Config loads, adapters mount, modules register, routes are wired, listen() fires. By the end of this phase, the app is accepting connections. Runtime — the per-request phase.…