Launch or Rebuild
Ask ten teams what they need from a design studio and you will hear the same fog: “a website project,” “a refresh,” “some UX help.” Those phrases hide two completely different jobs. Until you name which one you are buying, every estimate is fiction.
At Phoenux we force an early fork: Launch or Rebuild. Almost every serious engagement is one of those doors. Everything else — positioning sprints, UX audits, AI readiness, discovery add-ons — exists to make one of the two paths cleaner.
Launch
Launch is for a new product or MVP that is validated enough to put in front of real users. Not a pitch deck. Not a prototype that dies in Figma. A smallest credible product that teaches itself and generates learning.
The work starts with a cut list. What hypothesis are you testing? What is explicitly out of v0? We design one priority journey end to end — signup, core loop, or checkout — with empty, loading, error, and success states. Platform choice (custom, low-code, or no-code) follows constraints, not fashion.
Launch fails when teams confuse a prototype with an MVP, or when they try to ship twelve journeys before one works. Speed comes from focus, not from skipping craft. A Launch engagement should answer a decision: double down, pivot, migrate stack, or stop.
Typical Launch shapes: an MVP sprint on one journey; research then MVP when the wedge is still fuzzy; a platform-honest build with exit notes when lock-in is the real risk. See Rapid MVP Development when you are ready to size that work.
Rebuild
Rebuild is for something already live that looks finished but does not feel designed. Users stall. Support tickets pile up with “where do I…?” The brand says one thing; the product says another. New segments arrived and the IA never did.
Pretty skins without information architecture changes fail. A Rebuild maps the journeys that pay the bills, strips ceremony, and rebuilds hierarchy so power users and first-timers can both move. Sometimes the marketing shell needs work first. Sometimes the in-app product is the bottleneck. Pretending a homepage refresh fixes an in-app IA problem wastes a quarter.
Rebuild often starts with a UX audit or AI readiness pass when stakeholders disagree about what is broken. Then phased Product & Interface Design or Legacy UX Modernization — keep mental models that work, replace what blocks growth.
Side-by-side
Launch optimizes for learning and a cut list. Rebuild optimizes for decision density and migration-friendly systems. Launch asks “what is the wedge?” Rebuild asks “which journey pays the bills, and what blocks it?”
Launch success looks like a shipped path and a clear next-stage memo. Rebuild success looks like measurable movement on activation, time-to-value, support volume, or expansion — on the journeys you named up front.
Budget bands differ too. Focused Launch sprints often land in the $8k–$25k range. Rebuilds that touch multiple journeys and systems more often sit in defined-project territory ($25k–$120k+). Those are illustrative; Rates explains how we size.
How to choose on a call
If there is no live product people depend on yet, you are in Launch territory — even if you already have a landing page. If customers pay into a product whose interface no longer matches the business, you are in Rebuild territory — even if marketing wants “a redesign.”
If you cannot say Launch or Rebuild in one sentence, we start there. Then we size a sprint or a project — not a vague retainer that hopes the problem will clarify itself.
Related reading: For SaaS for buying context, Rates for engagement models, and Creation when you are ready to ship.
Signals you are actually in Launch
You have a hypothesis, not a live customer base depending on the product today. You are choosing between two or three onboarding shapes and cannot tell which one wins without watching real users try it. Engineering is waiting on an interface decision, not the reverse. Marketing has more assets than the product has screens — a landing page, a deck, a waitlist — and none of it forces the one journey that matters into focus.
Founders often self-diagnose Launch correctly but then buy the wrong scope: a full brand system before the core loop is proven, or five journeys designed at once because “users will need all of them eventually.” Both waste the runway Launch is supposed to protect.
Signals you are actually in Rebuild
Paying customers exist, and at least one of them has said some version of “I don’t know how to do X in here.” Support tickets repeat the same three questions every month. A new hire on the customer side needs a Notion doc of screenshots to complete a task the product should teach in-app. Sales quietly demos a different, cleaner environment than what customers actually use.
Rebuild also shows up as organizational drift: three teams have each proposed a different fix for the same screen, and none of the fixes agree on what the screen is for. That is an information-architecture problem wearing a visual-design costume, and no amount of polish resolves it without a journey-level pass.
What changes after the call
Once we agree on the door, the shape of the engagement follows automatically. Launch calls start with a one-page brief: the hypothesis, the one journey, what counts as a signal to continue. We timebox states — empty, loading, error, success — before we timebox visuals, because a beautiful screen that cannot show a real error is not shippable.
Rebuild calls start with a journey inventory, not a moodboard. We ask which paths generate revenue or retention today, rank them, and pick the one with the worst ratio of importance to usability. That becomes the first phase. Everything else waits for a second phase memo, which keeps stakeholders from relitigating scope mid-project.
The cost of getting the door wrong
Teams that buy a Rebuild-shaped engagement for a Launch problem end up with a beautifully systemized product nobody has validated wants to exist. Teams that buy a Launch-shaped sprint for a Rebuild problem end up with one polished screen bolted onto an information architecture that still does not hold together — a nicer room in a house whose layout does not work.
The mismatch is expensive in a specific way: it is not visible until months later, when the roadmap stalls on a decision the wrong-shaped engagement never forced anyone to make. Naming the door early is cheap. Discovering it late is not.
Where Discovery fits, if at all
Neither Launch nor Rebuild starts with SEO, AEO, or paid traffic. Reach without a coherent product to receive it just moves the point of failure downstream — more visitors landing on a confusing core loop, or more search traffic bouncing off a stalled activation flow. We treat Discovery services as what you add after Creation ships something worth finding, not before.
That sequencing is not dogma for its own sake. Teams that invest in visibility before the product is coherent usually end up paying twice: once for the traffic work, and again for the redesign that traffic exposed as necessary.
Examples in plain language
Launch example: a B2B tool with paying design partners, no product UI yet, and a hypothesis that one onboarding path will activate teams. Cut everything except that path. Ship. Measure. Decide.
Rebuild example: a live SaaS with strong revenue and a UI from three product generations ago. Admins cannot configure what sales sells. New hires need screenshots in Notion to complete core tasks. Map admin and activation journeys first; reskin later if at all.
Hybrid trap: a live marketing site and a half-built app. That is usually Launch for the product journey and a lighter Web Design pass for the shell — two scopes, one program, not one vague “website.”
Common mistakes
Calling a clickable prototype an MVP. Shipping a marketing site and calling it Launch when no product journey exists. Starting a Rebuild with a moodboard before naming the paying journey. Buying a retainer because the problem is unclear — retainers work when the cadence is clear, not when the door is not.
Another failure mode: optimizing SEO or AI visibility before the product is coherent. Discovery is supporting craft. If the product confuses humans, making it more findable is not a strategy.
What to bring to the first conversation
One sentence for Launch or Rebuild. The journey that pays the bills. The metric that would make the work worth doing. Constraints you will not move (compliance, platform, deadline). References for taste — not “make it like X,” but “this feels decisive.”
A short glossary
Wedge — the one hypothesis a Launch product exists to test, expressed as a behavior you expect to see, not a feature list. Cut list — everything explicitly out of v0, written down so it stops resurfacing in every planning meeting. Journey that pays the bills — the specific path a Rebuild has to fix first, ranked by revenue or retention impact, not by which team is loudest. Decision density — how many real decisions a Rebuild resolves per week of work, the metric that predicts whether a project stalls.
Platform-honest — a build recommendation that names the real tradeoffs of custom, low-code, or no-code for your constraints, including what happens when you outgrow the choice. Failure-first — designing the error, empty, and denied states of an AI or automated feature before the happy path, since that is where trust is actually won or lost.
We will push back if the brief is theater. That is the point of a studio that still has founders in the files.