What should an end-to-end design agency own from wireframes to launch?
“End to end” has no fixed definition. A stage-by-stage matrix shows who should own discovery, handoff, build QA, launch assets and the first 2 weeks after release.
A founder has three proposals open. All three promise to take the product “end to end, from wireframes to launch.” The first ends with “final Figma files and developer handoff.” The second adds front-end and back-end development and a line called deployment. The third lists “launch support” with nothing underneath it. The words match, but the jobs are different.
The scene is illustrative. The answer to it is simple: “end to end” has no fixed definition. A proposal earns the phrase when it names an owner for every stage between the first wireframe and the first 2 weeks after release: the agency, your team, or both, with a person and a deliverable for each. Read two stages with the most care, because they are the easiest to leave blank: the review of the built product before release, and the fixes after it.
Humbleteam publishes this guide. We are a product design agency, so hold our proposals to the same test.
Why does “end to end” cover such different scopes?
Most agencies that sell this fall into one of two shapes. A design-only agency researches, designs and tests the product, then hands the work to engineers: yours, a contractor’s or a development partner’s. A design and engineering agency also writes and ships the code. Either can be the right choice. The trouble starts when a proposal uses the same phrase for both and leaves you to guess which one you are buying.
The UK government’s Service Manual draws the line clearly. Discovery is about understanding the problem before committing to build, and the manual says not to start building during it. In alpha, teams prototype and test ideas with code that is not meant for production, and they expect to throw most of it away. Beta is where the chosen idea gets built for real, and live is where the team keeps running and improving it.
A clickable prototype, however convincing, sits on the alpha side of that line. Launch sits on the other side. When you read a proposal, ask which side each deliverable belongs to, and who carries the work across.
Who owns each stage from wireframes to launch?
The matrix below shows a typical split. It describes common engagement shapes, not an industry standard, and individual agencies draw the lines differently. Use it as a template: one row per stage, one name per cell.
| Stage | Design-only agency | Design and engineering agency | Startup | Ask the proposal |
|---|---|---|---|---|
| Discovery | Leads research and problem framing | Leads research and adds a technical feasibility check | Supplies users, data and the business goal, and makes the scope call | What decision does discovery end with? |
| Flows and wireframes | Owns | Owns | Approves scope and edge cases | Which flows and which states are included? |
| UI design | Owns | Owns | Approves, and supplies brand and content | Who writes the real interface copy? |
| Prototype testing | Plans and runs sessions | Plans and runs sessions | Provides or approves participants and watches sessions | Who recruits, and how many rounds? |
| Design system and components | Design components and usage rules in Figma | Design components plus coded components | Decides who maintains them after the engagement | Design files only, or code as well? |
| Engineering handoff | Prepares the package for your engineers or a development partner | An internal step inside the agency | Tech lead accepts the work or sends it back | What must a ticket contain before engineering accepts it? |
| Build QA and design review | Reviews staging builds only if it is in scope | Runs functional testing, and design review if it is named | Gives staging access and signs off the release | Who compares the build with the design, and when? |
| Launch assets | Store screenshots, icon and website pages, if scoped | The same, and may also handle store submission | Owns store accounts, legal pages and the release decision | Which assets, and who submits? |
| Post-launch fixes | Design fixes within an agreed window, if contracted | Bug fixes within an agreed window, if contracted | Triages support tickets and sets priorities | How long is the window, and what does it cover? |
Read the table by column. A design-only agency can cover the whole chain when your engineers, or a partner you hire, fill the build work and the agency stays on to review it. A design and engineering agency carries more of the chain itself, which also means more of your product lives in someone else’s code when the contract ends. The startup column never empties. Someone on your side approves scope, owns the store accounts and makes the call to ship.
Then read the cells that say “if in scope” or “if contracted.” Those are the places where a proposal can say “end to end” and still leave a stage with no owner.
Where do the handoffs to engineering sit?
There are two handoffs. The first goes from design to build. The second goes from build back to design, when someone checks what was built.
Figma’s Dev Mode makes the first one visible. A designer marks a section, frame or component as Ready for dev, and if the design changes afterward, Figma flags it as Changed so engineers can compare versions (Dev Mode statuses). Figma also notes that marking a section ready does not stop anyone from editing it (Sections). So agree in writing who may change a design after it is marked ready, and how engineers hear about it.
The second handoff is the one proposals tend to skip. Infinum’s development handbook describes a design implementation review: a designer, ideally with a tester, works through the staging version of the product, checks screens and components against the design, and points the developer to the spec wherever they differ (Infinum handbook). Functional QA asks whether the product works. This review asks whether it matches what was designed and tested.
Some teams keep reviewing after release. Varun Parmar, Miro’s chief product officer, described in Lenny’s Newsletter in 2023 how Miro’s design team reviews everything shipped each month and says what meets the quality bar. A startup can do far less than that. The review only needs a name and a date in the plan.
Where does “end to end” usually break?
The three cases below are illustrative.
The work stops at Figma
The last deliverable in the proposal is “handoff.” The designers move to another project the week engineering starts. Questions about empty states and permissions pile up, and engineers answer them alone. The fix is cheap: book design hours across the whole build, even a few a week, and name the person who answers engineering questions.
Launch slips because nobody owns build QA
The build passes functional tests, but error states are missing, some copy is still placeholder and the spacing has drifted. For a mobile app, the stores add their own gates. Apple’s App Review Guidelines ask for a final version with placeholder text removed, tested on a device, with demo account details if the app has a login. Apple also says that, on average, over 40% of unresolved review issues relate to app completeness, and that it typically reviews 90% of submissions in under 48 hours (App Review). Google Play requires personal developer accounts created after November 13, 2023, to run a closed test with at least 12 testers, opted in for 14 days in a row, before they can apply for production access (Play Console Help). Count those steps into the launch date.
Nobody planned the first 2 weeks
The Service Manual asks teams in beta to keep enough capacity to keep learning and iterating, and to make sure support staff can cope with new users who struggle in ways nobody predicted. A startup launch is the same moment on a smaller scale. A proposed minimum plan for the first 2 weeks after release:
- One named person reads every support ticket and watches session recordings for the core task, every day.
- A short daily triage sorts each issue into fix now, fix this sprint, or roadmap.
- Designer and engineer hours are reserved for fixes before launch day, not found after it.
- One person decides what ships as a fix and what waits.
- A review at the end of week 2 decides what moves to the roadmap and when the agency’s fix window closes.
How do you test a proposal before signing?
Copy the matrix into a document and fill it in once per agency, using only what each proposal says in writing. Every cell you cannot fill becomes a question. These 8 cover most of them:
- Which of the 9 stages are in the price, and which are optional extras?
- Who from your team stays involved during the build, by name, and for how many hours a week?
- What does a handoff ticket contain, and who on our side can send one back?
- Who reviews the staging build against the design, and how many days before release?
- Who prepares the store listings and submission details, and whose accounts are used?
- What happens in the first 2 weeks after release, and how many fix hours are included?
- Who owns the design files, components and any code at the end?
- For each stage that belongs to us, what do you need from us, and by when?
If your release date is fixed, our guide to launching a startup product in 8 weeks adds an illustrative week-by-week plan to check the proposal against.
A proposal that answers all 8 in writing has earned the phrase. One that answers 5 may still be the right agency, and you now know which 3 jobs you are taking on.
The matrix is not a scorecard. A design-only agency next to a strong engineering team can cover every row. Before you sign, every row needs a name, and the names on your side need the time to do the work.
