Every project we take on moves through the same four stages: discovery, design, build, launch. The labels aren't the point. Plenty of studios use the same four words and mean something completely different by them. What matters is the order, and what we refuse to skip.
Discovery comes first because it's the stage most easily skipped under time pressure, and the most expensive to skip. It's not a formality before the "real work" starts. It's where we find out what the real work actually is. A request that arrives as "we need an app" usually turns out to be a narrower, more specific problem once we've asked enough questions about the business, the users, and the constraints nobody put in the first email.
Design comes before a single line of production code, not after. Wireframes and interface decisions get reviewed with the client while they're still cheap to change. The alternative, building first and adjusting the interface once the backend is already opinionated about it, is how projects end up with UI compromises nobody actually chose, just inherited.
Build is iterative, not a single disappearance followed by a reveal. We'd rather show a rough version of the right thing early than a polished version of the wrong thing late. Regular check-ins during this stage exist so that if we've misunderstood something from discovery, it surfaces in week two, not week eight.
Launch is the stage most often treated as the finish line, and we don't treat it that way. Shipping is when real users start finding the edge cases nobody thought to ask about in discovery. We stay through that (monitoring, support, the unglamorous week after the glamorous one) because that's when a project either holds up or doesn't.