The Question on the Call
"Why would I pay you somewhere around fifteen grand to tell me what I already told you on this call?"
That's the question I get most often from Los Angeles founders once a free call turns into a proposal with a discovery line on it. It's a fair question. The founder has lived with the idea for a year. They can describe every screen. From where they sit, discovery looks like an agency charging to read back their own notes.
Sometimes they're right, and I'll tell you when further down. But most of the time the gap between "I can describe every screen" and "another company could price this build to within a reasonable margin" is where the money in an app project goes missing.
This article is about that gap. It covers the paiddiscovery phase specifically: what it costs, what a team should hand you at the end of each week, the seven deliverables I'd refuse to sign off without, how to tell whether you could walk away with them to a different vendor, and when you should skip the whole thing.
If you want the wider picture of consulting in the city first, our Los Angeles app development page is the starting point. This piece stays narrow on purpose.
A Call Is Not a Phase
A free discovery call decides whether to work together. A paid discovery phase decides what to build. People use the same word for both, and that causes a lot of the confusion on these calls.
The call is 30 to 60 minutes. You describe the idea, we ask about users, integrations, budget and deadline, and within about 5 business days you get a rough scope and a phased proposal. We wrote up what that conversation covers in our guide to the free consultation call, so I won't repeat it here.
The phase is 2 to 4 weeks of actual work. Somebody interviews your users. Somebody draws every flow, including the ugly ones like a failed payment. Somebody writes code against the one integration nobody is sure about. Somebody puts a prototype in front of five strangers and watches them get stuck.
The UK Government Digital Service, which has published more on this than almost anyone, describes discovery as the stage where you learn about users, constraints and opportunities before you build. Its Service Manual is blunt that you should not start building your service in discovery, and that stopping at the end of discovery is not a failure if the research says stop.
That second line is the one I'd underline. A discovery phase that can only ever end in "yes, build it, with us" is a sales process with a fee attached.
What It Costs
Our published discovery and audit band is $9,000 to $22,000 over 2 to 4 weeks.That's the number we put on every proposal, and it's the one I can speak to. Other Los Angeles agencies price differently, and some bury discovery inside the build quote, which makes comparison hard.
Let me do the arithmetic out loud, because it tells you what you're buying.
Our senior time bills at $150 to $225 an hour. $9,000 at the top rate of $225 is 40 hours. $22,000 at the bottom rate of $150 is about 147 hours. So the band buys somewhere between about 40 and 145 hours of senior people thinking about your product.
Forty hours is one senior person for a week, or two people for half a week each. That's enough for a focused app with one user type and no scary integrations. A hundred and forty hours is a product designer, a senior engineer and a lead splitting three or four weeks, which is what you need when there are two user types, payments and a legacy system on the other end.
Now put it next to the build. Our MVP development tiers run $15,000 to $25,000 for a validation prototype, $30,000 to $50,000 for the next tier, and $55,000 to $75,000 and up above that. Native iOS work on its own sits at $50,000 to $250,000 and up.
Take a $60,000 build and a $12,000 discovery. Discovery is 20% of the build price. That's not nothing, and I won't pretend it is. For a $25,000 validation prototype, a $12,000 discovery would be almost half, which is exactly why I usually tell those founders to skip it (more on that below).
| Build size | Sensible discovery | Discovery as share of build | My read |
|---|---|---|---|
| $15k to $25k validation prototype | None, or a 1 week scoping sprint | 0% to about 20% | Build the prototype; it is the discovery |
| $30k to $50k MVP | $9k to $12k, 2 weeks | About 18% to 40% | Worth it if payments or integrations are involved |
| $55k to $75k+ MVP | $12k to $18k, 3 weeks | About 16% to 33% | Usually worth it |
| $100k+ native or multi-platform | $15k to $22k, 3 to 4 weeks | About 22% or less | Almost always worth it |
To be clear, those shares are arithmetic on our own published bands, not an industry benchmark. I haven't found a neutral dataset on what share of app budgets goes to discovery, and I'd be suspicious of anyone who quotes one.
If you're weighing whether a Los Angeles team is worth it at all versus a cheaper offshore shop, the comparison lives in our Los Angeles vs offshore cost breakdown. Discovery is actually where the time zone matters most, because it's the phase that runs on live conversation.
Discovery Is an Option Contract
Here's the concept I use to explain discovery to founders who come from finance or real estate. It's borrowed from options trading.
An option is a small payment for the right, but not the obligation, to do something bigger later at a known price. You pay a premium today so that tomorrow you can either exercise the option or walk away having lost only the premium.
A good discovery phase is exactly that. You pay, say, $12,000. At the end you hold a fixed-price build proposal, which is the right to buy the build at a known price. You also hold a package another vendor could quote from, which is the right to buy it elsewhere. Or you hold evidence that users don't want the thing, and you walk away having spent $12,000 instead of $60,000.
Why does this framing matter? Because it tells you what makes discovery valuable and what makes it worthless.
- An option is only worth something if the strike price is known. Discovery that ends without a fixed price is an option with no strike. You paid the premium and got nothing to exercise.
- An option is only worth something if you can walk away. Discovery whose deliverables only make sense to the vendor that wrote them locks you in. That's the portability test later in this article.
- An option is overpriced if the underlying is cheap. Paying $12,000 for the right to buy a $20,000 build is a bad trade. Just build the $20,000 thing.
Keep that lens on for the rest of this piece. Every deliverable below exists to make the strike price firmer or the exit cleaner.
Week by Week
A four-week discovery should put something new in your hands every Friday. If you get to the end of week two and all you have is a calendar full of workshops, something is wrong.
This is the shape we aim for on a four-week engagement. A two-week version compresses weeks one and two and weeks three and four, and usually tests with fewer users.
| Week | What the team does | What you receive by Friday | Your job that week |
|---|---|---|---|
| 1 | Stakeholder interviews, 5 to 8 user interviews, competitor and app store teardown, systems inventory | Draft product brief, interview notes, list of assumptions ranked by risk | Two hours for interviews, introductions to users, access to current tools |
| 2 | User flows for each core task, low-fidelity screens, integration spikes against real APIs | Flow diagrams, wireframes, a short spike report per risky integration | Decide the one or two things version one must do |
| 3 | Clickable prototype, usability tests with about five users per user type, architecture draft | Tested prototype, test findings, architecture document v1 | Watch at least two test sessions live |
| 4 | Backlog with estimates, risk register, phasing, fixed-price build proposal | Backlog export, risk register, proposal with phase prices and a readout | Challenge every estimate you do not understand |
Week 1: understand before drawing
The first week is interviews. Founders, the people who will run the thing day to day, and about five to eight actual or likely users. We also tear down the three or four apps your users already use for this job, reading their store reviews for complaints.
Nielsen Norman Group's definition of discovery puts it well: research the problem space, frame the problem, and gather enough evidence to decide what to do next. It recommends a small multidisciplinary team of about three to seven people that includes someone who can do research, a facilitator, a sponsor with authority, and someone who understands the technical constraints.
The output that matters most in week one is a ranked list of assumptions. "Dispatchers will use a phone, not a desktop." "Customers will pay a deposit up front." "The booking system has an API." Each one ranked by how bad it would be if it turned out wrong.
Week 2: draw the flows and poke the integrations
Week two turns interviews into user flows. Every core task, from the moment someone opens the app to the moment the job is done, including the paths nobody likes drawing: the declined card, the empty state, the account that got deleted.
At the same time, an engineer writes throwaway code against the riskiest integration. This is called a spike. It answers questions like "does this API actually return what the docs claim" in a day or two instead of discovering the answer in sprint four.
Your job this week is the hardest one: decide what version one must do. Not should. Must. The prioritization methods Nielsen Norman Group summarizes, such as MoSCoW and an impact versus effort matrix, are useful here mainly because they force you to write down what you're not doing.
Week 3: prototype and test
Week three produces a clickable prototype and puts it in front of real users. This is the week that earns the fee.
Apple's design team made the case for this more than a decade ago in a WWDC session titled Prototyping: Fake It Till You Make It. The core idea was to make fake apps, show them to people, learn from their feedback, and repeat, faking everything except the one thing you are trying to learn about.
How many testers? Jakob Nielsen's 2000 analysis estimated that about five users uncover roughly 85% of the usability problems in a design, and argued for several small rounds rather than one large study. He also noted you need more people when you have distinct user groups: three or four per group for two groups. So a customer app with a staff dashboard needs six to eight sessions, not five.
The downside, in the same breath: five users finds usability problems, not market demand. Five people navigating your booking flow smoothly tells you nothing about whether five thousand will download it. Anyone who sells a five-user test as market validation is overselling it.
Week 4: turn it into a price
The last week converts everything into a backlog of user stories with estimates, a risk register, and a fixed-price build proposal split into phases. Then there's a readout where you can argue with every number.
Please argue. The readout is the one moment the estimates are cheap to change. Once a phase is signed, changing it means a change order.
If a discovery runs longer than six weeks for a single app with one or two user types, I'd want a written reason. The GOV.UK guidance mentions around 4 to 8 weeks as typical, but it's written for public services that often serve millions of people across many user groups. A booking app for a Culver City salon is not that.
The Seven Deliverables
A paid discovery phase should end with seven things you own: a product brief, user flows, a tested clickable prototype, a technical architecture document, an estimated backlog, a risk register, and a fixed-price build proposal.Missing any one, you've bought part of a plan.
| Deliverable | What good looks like | Portable if | Warning sign |
|---|---|---|---|
| Product brief | Problem, users, the one metric that matters, what is out of scope | It reads without the vendor in the room | Adjectives instead of decisions |
| User flows | Every core task from entry to done, including errors and empty states | Exported as PDF and in the source design file | Only the happy path |
| Clickable prototype | Tested with real users; findings written down | You own the design file and the workspace seat | Never shown to anyone outside the project |
| Technical architecture | Platforms, backend, auth, integrations, data, deploy, store policy notes | Names public services, not a private framework | "We'll use our platform" with no detail |
| Estimated backlog | Stories with acceptance criteria and hour or point estimates | Exported as CSV or tracker file | One line per feature with a single price |
| Risk register | Risk, likelihood, cost, owner, response | Written in plain language | Empty, or only "scope creep" |
| Fixed-price build proposal | Phases, price per phase, what triggers a change order | Priced separately from discovery | Only a time-and-materials estimate |
Product brief
Two to five pages. Who the users are, what problem the app solves for them, the one metric that tells you it's working, and a list of what is explicitly out of scope for version one. The out-of-scope list is the most valuable paragraph in the document, because it's the one that prevents arguments in month three.
User flows
Diagrams of every core task. For a service business these often grow into a journey map or a service blueprint, which Nielsen Norman Group describes as mapping not only what the customer sees but the staff actions and systems behind each step. Its guides on journey mapping and service blueprints are worth ten minutes before your kickoff.
Blueprints matter in Los Angeles more than people expect, because so many of the apps we're asked to build sit on top of a physical service: a security guard arriving at an event, a jeweler meeting a customer for a fitting, a driver picking up a delivery. The app is the front of a process with people behind it.
Clickable prototype, tested
A prototype in a design tool that you can tap through on a phone, plus a short written summary of what happened when real users tried it. Nielsen Norman Group's Kara Pernice has a useful piece on low versus high fidelity: low fidelity is faster to change mid-test, high fidelity gets more realistic behavior. For discovery I usually want medium fidelity, real enough that people don't get distracted, rough enough that nobody mistakes it for finished.
The prototype should also respect platform conventions. Apple's Human Interface Guidelines exist so that an iPhone app feels like an iPhone app; a prototype that ignores them tests a design you'll have to change anyway. Our product design team prototypes against the native patterns from the first screen for this reason.
One more thing. The prototype is not the app. The GOV.UK guidance on the alpha phase tells teams to expect to throw away prototype code. If a vendor says the discovery prototype will become the production app, ask what shortcuts they took to build it in a week.
Technical architecture document
Which platforms (native iOS, native Android or cross-platform), which backend and database, how login works, every integration with its API and pricing model, where the data lives, how releases ship, and what analytics are collected.
It should also cover the store rules that change the design. Apple's App Store Review Guidelines require in-app purchase for unlocking digital features (section 3.1.1), in-app account deletion for any app that lets people create accounts (5.1.1(v)), and more than a repackaged website (4.2). On Android, Google's Play Console documentation notes that personal developer accounts created after November 13, 2023 must meet testing requirements before an app can be published. Each of those has changed a real budget somewhere.
Estimated backlog
The features broken into user stories, each with acceptance criteria and an estimate in hours or points. The INVEST checklist Bill Wake published in 2003 is still the simplest test: each story should be independent, negotiable, valuable, estimable, small and testable. A backlog of one-line features like "chat" with a single dollar figure beside each is not a backlog. It's a price list.
Risk register
A table of what could go wrong: the risk, how likely, what it would cost, who owns it, and what the team will do. Good entries are specific: "The ticketing vendor's API has no webhook, so we poll every five minutes; if they rate-limit us, sync slows." A register that just says "scope creep" and "timeline" was written by someone who didn't look.
Fixed-price build proposal
The build, split into phases, with a price for each phase and a plain statement of what triggers a change order. This is the strike price on your option. We send ours within 5 business days of the readout, and the build comes with full source code and IP transfer and a 30-day post-launch warranty.
The downside of fixed price, since I'm recommending it: the vendor carries the estimation risk, so a careful vendor adds contingency. You may pay somewhat more than a time-and-materials build that goes perfectly. You'll pay far less than one that doesn't.
The Portability Test
Discovery deliverables are portable if a different agency can quote your build from them within about a week, without re-running discovery.That's the whole test. Everything below is how to check it before you pay.
Think of it like a house inspection report. If the only person who can read the report is the contractor who wrote it, and he happens to also want the renovation job, you didn't buy an inspection.
The US Digital Service's Digital Services Playbook makes a version of this point for government buyers: contracts should keep software and data generated by third parties under the buyer's control. And 18F's De-risking Government Technology guide, which GSA revised and expanded in September 2024 with a new section on working with vendor teams, exists largely because agencies kept getting locked in. A founder in Echo Park faces a smaller version of the same trap.
- 1.Ownership in writing. The discovery contract assigns you the deliverables on payment, not on signing the build.
- 2.Source files, not screenshots. You get the design file and a seat or transfer in the design workspace, not a PDF of the prototype.
- 3.Public building blocks. The architecture names real, public services. "Our proprietary accelerator" with no detail is a lock.
- 4.Exportable backlog. Stories come out as a CSV or tracker export with acceptance criteria and estimates, not trapped in the vendor's project tool.
- 5.Re-estimable units. Estimates are in hours or points per story, so another team can apply its own rate.
- 6.Spike code included. The throwaway integration code is handed over too, even if it will be rewritten.
- 7.Separate prices. The build proposal is priced as its own document, so you can compare it against an outside quote.
Here's a cheap way to run the test for real: once you have the package, send it to one other agency and ask for a fixed-price quote. If they can do it, the discovery was portable. If they ask to start over, it wasn't, and you have your answer about what you bought.
Our ten questions for vetting a Los Angeles agency covers the rest of the contract; ownership of discovery work is the question most people forget to ask because the build feels like the real purchase.
What Our LA Builds Show
I want to be careful here. The three Los Angeles case studies I'm about to mention are website and e-commerce builds, not native mobile apps. I'm using them because they show how front-loaded decisions shaped the build, not as app outcomes.
LA Pro Security: the calculator is the rules
For LA Pro Security, we built a site with an instant quote calculator that prices security services from event type, duration and guard count, plus a guard scheduling and dispatch dashboard and a client portal. The case study records the starting point as a manual quote process that took days and scheduling kept in spreadsheets.
A calculator like that can't be written until someone has decided how every event type, duration and guard count turns into a price. That is a discovery question dressed up as a feature. It's the clearest example I have of why pricing rules, not screens, are often the real scope of a booking or quoting app.
Janvier LA: customization and booking
Janvier LA is a Shopify store for luxury engagement rings and custom jewelry with customization features and appointment booking. Custom jewelry flows are exactly where a user flow diagram earns its keep, because the path from browsing to a fitting appointment has a lot of branches. The client's own words on the case study page, attributed to the CEO & Owner of Janvier LA: "They're very accommodating to our business schedule. More importantly, they make things work."
Eternal Brilliance LA: handover you can diff
Eternal Brilliance LA is a hand-written WooCommerce theme on TailPress and Tailwind 3.4, with ACF Pro product media, an AJAX favorites system, WooPayments and Square, checkout changes isolated in a child theme, and a self-managed CloudPanel VPS running LiteSpeed. The case study states that no analytics or sales figures were provided, so I won't give you any.
What it does show is the portability principle in practice: a theme kept in git, field definitions synced to files so content structure changes are reviewed like code, and a server the brand controls. Those are architecture decisions that make the next vendor's life easy, which is the same thing you want from a discovery package.
A Worked Scenario
This is a scenario, not a client. The numbers come from our published bands; the business is invented to show the arithmetic.
Suppose a mobile detailing company in the San Fernando Valley wants an app. Customers book a wash at home, pay a deposit, and track the van. Detailers get a daily route on their phone. The owner has a quote from a freelancer for $35,000 and a proposal from an agency with a $14,000 discovery followed by a build estimated at $55,000 to $75,000.
The owner's instinct: the freelancer is half the price. Why pay $14,000 to find out the app costs more?
Walk through what a three-week discovery would surface. Two user types means two apps or two modes, and roughly double the flows. Deposits mean payment handling and refunds for rain cancellations. Van tracking means background location, which needs a clear purpose and permission copy that store review will look at. Routing means either a mapping API with per-request pricing or a manual schedule. None of those is in a one-page freelancer quote.
Now the option math. If discovery shows the owner can launch with customers booking and paying, and detailers getting a simple daily list without live tracking, version one might land in the $30,000 to $50,000 tier instead. The owner paid $14,000 to learn they could cut the build by something like $20,000 and defer tracking to phase two. Or discovery confirms the full scope, and the owner walks into the build with a fixed price instead of a $35,000 quote that was going to become $60,000 through change requests.
The downside case, stated plainly: discovery confirms the freelancer's scope was fine, and the owner spent $14,000 on documents that agreed with a cheaper quote. That happens. It's the premium on an option that expired worthless, and it's why the skip table below exists.
When to Skip Discovery
Skip a paid discovery phase when the app is small and well understood, when you already have tested designs and a spec, or when a cheap prototype would teach you more than a plan. I turn down discovery work on these grounds fairly often.
| Situation | Buy discovery? | Why |
|---|---|---|
| Marketing or content app with no accounts | Usually no | Few unknowns; a design sprint is enough |
| Rebuild of a working app on a new stack | Short audit only | Behavior is already specified by the live app |
| You already have tested designs and a written spec | No, or a 1 week technical review | Paying twice for the same thinking |
| Payments, bookings or quotes with pricing rules | Yes | The rules are the product and must be settled first |
| Health, finance or children's data | Yes | Privacy and compliance shape the architecture |
| Two or more user types (customer plus staff) | Yes | Flows multiply and conflict |
| Integration with a system you have never connected | Yes, with a spike | The API is the biggest unknown |
| Idea not yet validated with any user | Maybe; consider a validation prototype | You may need evidence, not a plan |
The one that surprises people is the last row. If nobody has ever used anything like your idea, a plan for building it well is premature. What you need is evidence that anyone wants it, and our $15,000 to $25,000 validation prototype tier exists for exactly that. The prototype is the discovery.
The USDS playbook pushes the same instinct from the other side: it asks teams to ship a functioning minimum viable product that solves a core user need within three months. Discovery that delays that without reducing a real risk is working against you.
Silicon Beach founders with a seed round and a deadline tend to fall into this bucket more than anyone. If that's you, the Santa Monica and Silicon Beach guide goes into how to sequence a raise, a prototype and a build.
Who Should Be in the Room
A discovery team needs a researcher, a designer, a senior engineer and someone on your side who can make decisions. Drop any one of those and a specific deliverable gets weak.
Without a researcher, the interviews turn into the founder describing the idea again and everyone nodding. Without a designer, the flows stay as boxes and arrows nobody can test. Without a senior engineer, the architecture document is a list of logos and the estimates are guesses. Without a decision maker on your side, week two stalls because nobody can say what version one leaves out.
That last one is the role founders underestimate. On a four-week engagement I'd plan on about four to six hours a week of your time, more in week two, plus a few hours from whoever will run the app day to day. If your operations lead can't attend, the flows will describe how you think the business works rather than how it does.
Ask the vendor to name the people, not the roles. "A senior engineer" on the proposal and a junior on the calls is a common swap, and it matters more in discovery than anywhere else, because this is the phase where judgment is the product.
A related question: should the same people run the build? I think usually yes, because context is expensive to transfer. A designer who watched five users fail at the same step doesn't need a memo to remember why that screen changed. But I'd still make the package portable, because "usually" isn't "always," and your leverage in the build negotiation comes from being able to leave.
Discovery When the App Has AI
If the app includes an AI feature, discovery needs one extra deliverable: a small evaluation set that shows the feature working on your real data. Otherwise the estimate for that feature is a guess with a model name attached.
Most of the Los Angeles app briefs I see in 2026 have an AI line somewhere. Summarize the customer's notes. Draft the quote. Answer questions about the menu. Each one sounds like a week of work, and each one can be, or can quietly eat a month.
The difference is almost always the data. A feature that drafts quotes from clean, structured pricing rules is easy. The same feature reading free-text emails from customers who describe events three different ways is not. The only way to know which you have is to try it during discovery, on twenty or thirty real examples, and write down how often the output was usable.
The downside is time: building even a small evaluation set adds a few days to discovery. I think it's the best few days you can buy on an AI feature, because it's the difference between a fixed price you can trust and one with a hidden asterisk. If you want to go further on this side, our AI development service runs this kind of test as part of scoping.
And put the ongoing model cost in the architecture document. AI features bill per use, so a feature that costs pennies in a prototype with ten testers can cost real money with ten thousand users. The discovery package should estimate it, even roughly, so it doesn't first appear on a credit card statement.
Red Flags in a Discovery Proposal
The biggest red flag is a discovery proposal that lists activities instead of deliverables."Stakeholder workshops, ideation sessions, strategy alignment" describes how people will spend your money, not what you'll own afterward.
- No user testing. A discovery where the prototype never meets a real user is a design phase with a different name.
- No fixed price at the end. If the output is "a more accurate estimate" rather than a price, the option has no strike.
- Deliverables owned by the vendor until the build is signed. That turns discovery into a deposit.
- A timeline over six weeks for one app with one or two user types, with no written reason.
- Engineers absent until week four. Architecture decided by a strategist alone tends to get rewritten.
- The discovery prototype is promised to become the production app.
- A scary cost multiplier used as the main reason to buy. See the next section.
If you're still building your shortlist, our Los Angeles app development company rankings score firms on what you can verify from public pages, which is a decent way to cut the list before you start collecting discovery proposals.
Numbers I Refuse to Print
Discovery gets sold with three kinds of numbers that don't survive checking. I chased each one before writing this.
The 100x bug-cost multiplier
"A bug found in production costs 100 times more to fix than one found in requirements," usually credited to the IBM Systems Sciences Institute. As The Register reported in July 2021, researcher Laurent Bossavit traced it to a 1987 Roger Pressman textbook citing 1981 course notes from what turned out to be an internal IBM training program, with no underlying data available. The same article quotes a formal methods consultant noting that some defects do cost more to fix later, but the evidence is inconsistent. The direction is plausible. The 100x is not a measurement. I won't use it and neither should the agency pitching you.
The CHAOS success rates
You'll see figures like "only 31% of software projects succeed" attributed to the Standish Group's CHAOS reports. The underlying reports are sold, not published, so I couldn't check the method for the recent editions. And Eveleens and Verhoef's 2010 IEEE Software paper argued that the Standish definitions measure estimation accuracy in a one-sided way and that the resulting figures are misleading; applied to their own data from about 1,200 projects, the definitions didn't reflect what happened. Without primary data, I don't print the percentage.
Our own older numbers
To be clear, this one is on us. Older pages in our own catalogue have said things like discovery reduces total project cost by 25% to 40%, or that roughly 70% of projects that skip discovery overrun. I looked for the source of both and couldn't find one. They read like the kind of numbers that travel between agency blogs without ever touching a dataset. I'm not repeating them here, and I'd treat the same claims on any competitor's site the same way.
What I will stand behind is smaller and checkable: discovery produces a set of documents and a tested prototype, and you can inspect every one of them before you pay for the build. That's a better reason to buy it than any multiplier.
Limitations
- The prices in this article are Frenchy Digital's published bands. I did not survey other Los Angeles agencies' discovery pricing, and many do not publish it.
- The discovery-to-build ratios are arithmetic on those bands, not an industry benchmark. I found no neutral dataset on discovery spend.
- The GOV.UK 4 to 8 week figure is written for public services, which are generally larger than a single commercial app.
- Nielsen's five-user figure is from 2000 and applies to finding usability problems in one design, not to validating demand.
- The three case studies cited are website and e-commerce builds, not native mobile apps. The detailing company is a scenario.
- App store rules change. The Apple and Google requirements cited were checked on September 29, 2026 and should be rechecked before any build.
Three Things This Week
You can find out whether you need a paid discovery phase in about a week, without paying anyone.
- 1.Write your riskiest three assumptions on one page. If none involves payments, sensitive data, several user types or an integration you have never touched, you probably don't need a four-week discovery.
- 2.Ask every vendor on your list for the seven deliverables by name, who owns them on payment, and whether the build proposal is fixed price. Note who answers in writing.
- 3.If you already have a discovery package from anyone, send it to a second agency and ask for a quote. Their answer is your portability test.
The answers to those three will tell you more than any proposal deck. Time to write the page.
Talk Through Your Discovery Question
Book a free call with Frenchy Digital, a senior-led Black-owned Los Angeles agency. We will tell you whether a paid discovery phase is worth it, and send a fixed-price phased proposal within 5 business days.
Not Sure You Need Discovery?
Book a free call. We will tell you whether a paid discovery phase is worth it for your app, or whether you can go straight to a fixed-price build.
1517 S Bentley Ave Apt 204, Los Angeles CA 90025
Frequently Asked Questions
Sources & References
- 1GOV.UK Service Manual, How the discovery phase works↗
- 2GOV.UK Service Manual, How the alpha phase works↗
- 3Nielsen Norman Group, Maria Rosala, Discovery: Definition (2020, reviewed 2024)↗
- 4Nielsen Norman Group, Jakob Nielsen, Why You Only Need to Test with 5 Users (2000)↗
- 5Nielsen Norman Group, Kara Pernice, UX Prototypes: Low Fidelity vs. High Fidelity (2016)↗
- 6Nielsen Norman Group, Journey Mapping 101↗
- 7Nielsen Norman Group, Service Blueprints: Definition↗
- 8Nielsen Norman Group, Sarah Gibbons, 5 Prioritization Methods in UX Roadmapping (2021)↗
- 9U.S. Digital Service, Digital Services Playbook↗
- 10GSA, A revised and expanded guide for de-risking government technology projects (September 11, 2024)↗
- 11Apple, WWDC14 Session 223, Prototyping: Fake It Till You Make It↗
- 12Apple, Human Interface Guidelines↗
- 13Apple, App Store Review Guidelines↗
- 14Google, Play Console Help: Create and set up your app↗
- 15Agile Alliance, INVEST glossary entry↗
- 16The Register, Tim Anderson, the 100x bug-cost study might not even exist (July 22, 2021)↗
- 17Eveleens and Verhoef, The Rise and Fall of the Chaos Report Figures, IEEE Software 27(1), 2010↗
