How to Vet a Los Angeles App Development Agency:10 Questions

Consider a founder who gets a two-line email from her agency. It says, more or less, that the app is theirs until the final invoice clears, and the final invoice is about $18,000 more than she thinks she owes. This is a scenario, not a client of ours, but every piece of it is a pattern buyers describe.

The app lives in the agency's Apple Developer account. The code lives in the agency's GitHub. The contract says "client owns deliverables" and never defines deliverables. She has paid for roughly nine months of work and owns, in any way she can prove, a Figma link.

That scenario is why this article exists. Not because agencies are crooks (most aren't), but because every one of those problems was checkable before she signed, and nobody told her where to look.

So here is the claim. There are ten questions that separate an agency you can trust from one you have to hope about. Each has a good answer, an evasive answer, and a way to verify it yourself without taking anyone's word for it. Most take about ten minutes.

To be clear about my conflict: I run Frenchy Digital, a senior-led, Black-owned app and AI agency in Los Angeles. You should ask us all ten. Throughout, I'll say how we answer them, including where our own proof is thinner than you might want.

Use these questions to test documents, not personalities. Every agency in LA is friendly on a discovery call. Friendliness is not a signal.

The wrong model is that vetting means judging whether the team seems smart and responsive. The real model is that vetting means checking whether their answers point to something outside the conversation: a record, an account, a clause, a live app. Smart people can be evasive. A bizfile entry can't.

If you want the broader checklist of green flags and red flags (portfolio quality, team pages, pricing transparency, communication cadence), that work is already done in our guide to choosing an LA app development company. I won't repeat it. This piece is narrower: ten questions, and the verification step for each.

Here's how I'd run it. Send the ten questions in writing before the second call. Written answers are easier to compare across three agencies, and they become part of the record if something goes sideways later.

Then do the verification yourself. Don't ask the agency to verify its own answers; that's the whole point.

A good answersounds like: "We're [Name] LLC, a California LLC, entity number such and such. Here it is on the contract's first line." It takes them five seconds because they have it memorized from signing things.

An evasive answersounds like: "We're a collective of LA creatives," or "our parent company handles contracts." Neither is fatal on its own. But if they can't tell you which parent, in which country, you're about to sign with someone you can't find.

How to verify it. Go to bizfile Online, the California Secretary of State's business search, and type the legal name. You'll see the entity's status, its formation or registration date, and its agent for service of process. That last one matters: it's where legal papers go if you ever need to send them.

What you're looking for is an active status and a formation date that roughly matches the story. An agency that says it has shipped apps since 2015, with an entity formed eight months ago, might have a reasonable explanation (a restructure, a new partnership). Ask for it.

If the agency is formed in Delaware or another state but works in California, it will usually show up in bizfile as a registered foreign entity. If it doesn't show up at all, that's a question worth asking directly.

The LA layer. If the agency operates inside the City of Los Angeles, the City's Office of Finance says businesses there need a Business Tax Registration Certificate. You can ask to see it. Be careful here, because "LA" in marketing often means Santa Monica, Culver City, Burbank or Pasadena, which are separate cities with their own rules. An agency in Culver City without a City of LA certificate is not doing anything wrong.

The downside of this check is that it proves existence, not competence. A perfectly registered LLC can still write bad code. That's fine. Question 1 is the floor, not the ceiling.

How we answer it.Our legal entity is on the first page of every proposal, and we'd rather you look us up than take our word for it.

The first half is familiar. The senior people on the sales call are not always the people who build. That's not automatically bad; a good lead with two mid-level engineers can be the right team. You just want to know.

The second half is the one nobody asks. If the people writing your code are subcontractors, and the agency never got a written assignment from them, the agency may not own the code it's promising to transfer to you. You can't receive more than the agency holds.

Why California makes this interesting. Labor Code section 2870 limits what an employment agreement can make an employee assign. It says an assignment provision does not apply to an invention the employee developed entirely on their own time without the employer's equipment, supplies, facilities or trade secret information, unless the invention relates to the employer's business or research, or results from work the employee did for the employer. Any clause that reaches further is, in the statute's words, against the public policy of this state and unenforceable.

For work an agency's engineer does on your app, on the job, the exceptions almost certainly apply, so the assignment should hold. The risk is at the edges: a side library an engineer wrote at home, reused in your app. That's rare, but it's why a careful agency tracks what code comes from where.

There's a companion rule. Section 2872 requires an employer whose agreement includes an invention assignment to give the employee written notice, at the time of the agreement, that it doesn't apply to inventions that qualify under 2870. An agency that has its paperwork in order will know what that notice is.

A good answersounds like: "Your lead is [name], an employee. We use one subcontractor for QA; every contractor signs an IP assignment to us before touching a repo, and our employees sign invention assignment agreements with the 2870 notice. We'll represent that in the MSA."

An evasive answersounds like: "We have a global talent network," with no names and no mention of paper.

How to verify it.Ask for the names of the lead engineer and designer, and look them up. Then ask for a warranty in the contract that everyone working on the project has assigned their rights to the agency in writing. You don't need to see every staff contract. You need the agency to be liable if it's wrong.

The cost of this question is a little awkwardness. Agencies that use offshore subcontractors sometimes get defensive, as if you're accusing them. You're not; offshore teams can be excellent, and the trade-offs are covered in Los Angeles vs offshore app development cost. You're asking about paper, not geography.

Here's the misconception. Most people think that if you pay someone to make something, you own it. For employees, that's roughly right. For outside contractors, including agencies, it's usually wrong.

Under 17 U.S.C. section 101, a work made for hire is either a work prepared by an employee within the scope of employment, or a specially ordered or commissioned work that falls into one of nine listed categories (a contribution to a collective work, part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas) and that both parties agree in a signed writing to treat as made for hire.

Look at that list. A standalone mobile app doesn't obviously fit any of it. So a contract that just says "this is a work made for hire" may not do what it says. The U.S. Copyright Office's Circular 30 walks through the same two situations, and it's worth ten minutes of your time.

If the work isn't made for hire, the copyright starts with its author, per section 201. Moving it to you takes a transfer, and section 204(a) says a transfer of copyright ownership, other than by operation of law, "is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed or such owner's duly authorized agent."

Therefore: the clause you want is an express assignment. Belt and braces, many contracts include both the made-for-hire language and a fallback assignment of everything that doesn't qualify. That's a normal pattern, and a lawyer will recognize it.

The trigger matters as much as the words.Most agencies assign IP on payment. That's reasonable; they don't want to hand over code for an invoice you might not pay. The trap is when payment means the final payment on the whole project, so you own nothing until the very end.

A fairer shape is assignment per milestone: when you pay for phase one, you own phase one. If the relationship ends at phase two, you leave with what you paid for.

A good answer: "Section 8. We assign all right, title and interest in the deliverables and source code to you on payment for each milestone. Pre-existing tools we reuse are licensed to you perpetually and royalty-free, and they're listed in Schedule B."

An evasive answer: "Standard industry terms, you own everything, don't worry." Standard according to whom?

How to verify it.Read the clause yourself. Check four things: it uses the word assign (not just license), it covers source code and not only "deliverables," the trigger is per milestone or at least clearly defined, and pre-existing agency code is listed and licensed to you. If any of the four is missing, ask for it in the redline.

The pre-existing code point is the one agencies push back on, and fairly so. A shop that has built an authentication module ten times won't give it away exclusively. A perpetual license is the right compromise. What you want to avoid is a license that ends when the relationship does.

How we answer it.Full source code and IP ownership transfer to the client. It's in our proposals, not just on our website, and I'd want you to read the clause rather than trust this paragraph.

Why is this so important? Because the app store listing is the business. Your reviews, your ratings, your downloads, your in-app purchase history, your push notification certificates. If they live in someone else's account, a contract dispute becomes a hostage situation.

The cost is small. Apple's enrollment page says the Apple Developer Program is 99 USD per membership year, with prices varying by region (checked September 29, 2026). Google's Play Console Help lists a US$25 one-time registration fee. Call it about $124 in year one to own both storefronts.

The friction is real, though.Apple requires an organization to be a legal entity that can contract with Apple; its enrollment page says it doesn't accept DBAs, fictitious business names, trade names or branches, and that you need a D-U-N-S Number. Getting one can take days. The upside: Apple says your organization's name is what appears as the seller on the App Store. That's your brand, not your agency's.

Apple also has a view on agencies publishing for clients. Guideline 4.2.6 of the App Store Review Guidelines says apps created from a commercialized template or app generation service will be rejected unless submitted directly by the provider of the app's content, and that such services should not submit apps on behalf of their clients. A custom agency isn't necessarily a template service, but the direction of travel is clear. Apple wants the content owner to be the publisher.

The roles, briefly. On Apple's side, the Account Holder manages the account, renews the membership, accepts legal agreements for the organization, adds the first Admins and approves banking changes. That person should be you or someone on your payroll. The agency gets an Admin or Developer role. On Google's side, Play Console has three access levels (account owner, admins and users). Same logic: you own, they're invited.

If it's already too late. Both platforms support moving an app. Apple's app transfer process keeps the app on sale and keeps its reviews and ratings, and the bundle ID travels with it. Google Play accepts transfer requests between developer accounts after checking policy compliance. Both require the current owner's cooperation. Which is exactly the thing you may not have in a dispute.

A good answer: "You enroll, we'll walk you through the D-U-N-S step, then invite us as Admin. We never hold your Account Holder credentials."

An evasive answer: "It's easier if we publish it under ours for now, we'll move it later." Easier for whom?

How to verify it.Log into App Store Connect and Play Console yourself, look at the users list, and confirm you're the Account Holder and account owner. If you can't log in, you don't own it. That's the whole test.

The same rule applies whether you're building native iOS app development or a cross-platform build. The storefront is yours.

An IP clause gives you the legal right to the code. A repository you own gives you the code. Those are different things, and the gap between them is where projects die.

Think of it like a house under construction. The deed says it's yours. But if the builder has the only keys and a dispute starts, the deed doesn't get you through the front door this week.

The fix costs almost nothing. Create a GitHub or GitLab organization in your company's name. Add the agency's engineers as members. Keep owner rights to yourself and one other person on your side.

If the agency has already started in its own organization, that's common and fixable. GitHub's documentation on transferring a repository covers moving a repo to another user or organization, and a good agency will do it in an afternoon once asked.

There's a bonus.Owning the repo is the best progress report you'll ever get. You don't need to read code. You can see whether commits happen every day or every three weeks. A status call that says "great progress this sprint" next to a repo with two commits is information.

What about source code escrow? It's a real product, and for large enterprise deals where the vendor keeps the code, it makes sense. For a custom app you're paying to own outright, escrow is solving the wrong problem. Own the repo and you don't need a third party holding a copy.

A good answer: "Send us an invite to your org. If you don't have one, we'll set it up in your name and hand over owner rights on day one."

An evasive answer: "We deliver the code at the end of the project." This isn't sinister in itself, but it means every month until then, you're trusting instead of checking.

How to verify it.Open your organization's settings and look at the member list and roles. Then look at the commit history once a week. That's it.

The honest downside: some agencies keep proprietary tooling or a shared component library in their own repos, pulled in as a dependency. That's fine if it's licensed to you perpetually (see Question 3), and a problem if your app won't build without access they can revoke. Ask whether a fresh machine with only your repos can build the app. If the answer is no, find out what's missing.

This is the one verification step I'd never skip, and it takes about two minutes an app.

Ask for three to five App Store or Google Play links. Open each one. Check three things: the app is live and downloadable in the US, it has been updated in the last year or so, and the seller or developer name.

That last check is the clever one. Tap through to the developer page on the App Store and you'll see every app published under that account. If the agency's portfolio apps are all listed under the client'scompany, that tells you the agency practices what Question 4 preaches. If they're all listed under the agency's own name, you've learned how it will probably treat yours.

A good answer: a handful of links, with the agency explaining what it built in each (the whole app, the backend only, a redesign) and a client contact who will take a ten-minute call.

An evasive answer: "Our best work is under NDA." Some of it may be, and that's legitimate. All of it being under NDA is not.

How to verify it.Beyond the store listing, ask the reference client one question: "If you had to take the app to another agency tomorrow, could you?" Their answer covers Questions 3, 4 and 5 in one breath.

Watch for the partial-credit problem. An agency may truthfully list an app it touched for two months as "our work." Ask what percentage of the current app is their code. Nobody knows exactly, but a straight answer ("we rebuilt the booking flow, about a third of it") beats a vague one.

How we answer it, including the part that's thin. Our three LA case studies are not native mobile apps, and I'd rather tell you that than let you assume. LA Pro Security is a website for a Los Angeles security company with an instant quote calculator (event type, duration, guard count), a guard scheduling and dispatch dashboard, and a client portal. Janvier LA is a Shopify store for luxury engagement rings and custom jewelry, with customization features and appointment booking. The third is below, under Question 9.

They're evidence of how we scope, build and hand over for LA businesses. They're not evidence of App Store outcomes, and you should weigh them that way. For mobile work specifically, ask us for app references and hold us to the same two-minute check.

Most apps collect more than their founders think. An email for login, a location for "near me," a device identifier for analytics, a crash reporter that grabs a stack trace with a user ID in it. Each SDK you add brings its own collection.

Does the CCPA apply to you? Maybe not. Civil Code section 1798.140 defines a covered business as a for-profit entity doing business in California that collects consumers' personal information and meets at least one threshold: annual gross revenue above $25,000,000 as adjusted, buying, selling or sharing the personal information of 100,000 or more consumers or households a year, or getting 50 percent or more of annual revenue from selling or sharing it.

That revenue number moves. The California Privacy Protection Agency announced on December 17, 2024 that the threshold rose to $26,625,000 from January 1, 2025, and it adjusts these amounts every other year. So an early-stage startup often won't be covered by the revenue test. A consumer app with real traction can hit the 100,000 consumer test well before it hits the revenue one.

The store rules apply either way. Apple requires app privacy details for new apps and updates, including the practices of third-party partners whose code you integrate. Google Play requires a Data safety section. Your agency will be the one who knows which SDKs are in the build, so it should draft these with you.

The contract clause. If you are covered, the same section 1798.140 describes a service provider as someone processing personal information on your behalf under a written contract that prohibits it from selling or sharing that information, or using it outside the business purposes the contract names. If your agency will touch production user data (support, debugging, migrations), that clause belongs in your agreement.

A good answer: "We'll produce a data map in discovery listing every data type and SDK. We'll draft the Apple privacy labels and the Play Data safety form from it. We'll sign service provider terms. Whether CCPA applies to you is a question for your counsel."

An evasive answer: "We're fully GDPR, HIPAA and CCPA compliant." An agency isn't compliant in the abstract; your app is, or isn't, based on what it collects and what you do with it. Compliance-by-badge is a warning sign.

How to verify it. Ask for the data map as a deliverable with a date. Compare it against the SDK list in the repo you now own (Question 5). If they don't match, you've found something before a reviewer did. The California Attorney General's CCPA page is a readable starting point for your own homework.

A modern app sits on a surprising number of accounts: the cloud host, the database, the domain registrar, email delivery, push notifications, payments, analytics, error tracking, maybe an AI model provider. Count them. It's often ten or more.

Agencies often set these up on their own accounts during the build because it's faster. Then the project ships and nobody moves them. Two years later the agency's card expires, or the relationship sours, and your production database is technically theirs.

A good answer: "We'll give you a list of every service in week one. You create each account; we get invited. Where a service needs a card, it's yours."

An evasive answer: "We host it on our servers, it's included." Included is nice until you want to leave.

How to verify it. Ask for the list, then log into each one. The billing owner field is the truth.

How we handled it on a real LA project. Eternal Brilliance LA is a fine jewelry store we built as a hand-written WooCommerce theme on TailPress and Tailwind 3.4, with ACF Pro product media, AJAX favorites, WooPayments and Square, and a checkout child theme. It runs on a self-managed CloudPanel VPS with LiteSpeed that the brand controls. The case study says the brand needed to own its platform, and the server is the brand's, not ours.

It's a website, not an app, so don't read it as mobile proof. Read it as the pattern: the theme is in git, the server belongs to the client, and the next developer could pick it up.

To be clear about the trade-off: a self-managed server is cheaper than managed hosting and gives you control, but somebody has to patch it. The case study notes a written maintenance and security plan was proposed covering updates, off-server backups, uptime monitoring and hardening. Owning your infrastructure means owning that job too, or paying someone to.

Agency websites are full of numbers. Percentage lifts, user counts, funding raised by clients, revenue multiples. Some are real. Many were true once, for one client, measured by the client, and have drifted into the marketing since.

So ask directly: "Pick the most impressive number on your website. Where does it come from, and could I see the evidence?"

A good answerseparates what the agency measured from what the client reported and from what it can't show. Something like: "That figure is the client's own report from their analytics; we don't have access. Here's the reference contact."

An evasive answerdoubles down: "Our clients see 500% growth on average." Average across how many? Measured how? From what baseline?

Here's the example I'd hold up.The Eternal Brilliance case study ends with a plain statement: the counts it gives (19 WooCommerce template overrides, 8 ACF field groups, two payment processors) come from the theme's codebase, and because we haven't been given analytics or sales reporting for that client, the page carries no traffic, conversion or revenue figures.

That's what honest proof looks like. It's less impressive on a first read. It's far more useful, because every number on the page is one you could check if you had the repo.

I'll admit the flip side. Some pages on our own site have carried headline tiles I can't currently verify, and I've kept them out of this article on purpose. If you find one, ask us the same question. We should have to answer it too.

How to verify it.References, but asked well. Don't ask "were you happy?" Ask "what went wrong, and what did they do about it?" and "did the number on their website come from you?"

When a reference gives you a quote, it tends to be about behavior, not metrics. The CEO and owner of Janvier LA told us: "They're very accommodating to our business schedule. More importantly, they make things work." That's not a growth figure, and I'm not going to turn it into one.

Nobody likes asking this on a first call. It feels like discussing the prenup on the first date. Ask anyway, because an agency's answer tells you how it thinks about your independence.

There are two exits to plan for. The good one: the app launched, you're hiring in-house, and you want a clean handover. The bad one: something broke down mid-project and you need to leave with what you paid for.

A good answer points to a written handover list. Something like:

• Repository ownership confirmed in your organization, with all branches and tags
• Every credential, API key and secret rotated and handed over through a password manager
• Build and release instructions that let a new developer ship an update from a clean machine
• Architecture notes and a list of every third-party service with its billing owner
• Agency users removed from App Store Connect, Play Console and cloud accounts on a date you choose
• Termination terms that let you leave after any milestone, owning everything paid for to that point

An evasive answer: "Why would you want to leave?" It's often said as a joke. Laugh, then ask again.

How to verify it. Find the termination section in the MSA and read what you get on termination for convenience, not just for cause. Then ask the reference client from Question 6 whether any developer outside the agency has ever shipped an update to their app. If yes, the handover works in practice.

How we answer it.The IP transfer and full source handover are standard for us. There's a 30-day post-launch warranty, and after that, clients either take the app in-house or move to a retainer between $2,500 and $9,500 a month. Either path works, because you own the code.

Score each agency on whether its answer names something you can check. Here are all ten on one page.

Scoring is simple. Two points if the answer names a document, account or record and your check confirms it. One point if the answer is specific but you couldn't check it yet. Zero if it's a feeling.

Let's do the arithmetic out loud. Twenty points available. An agency scoring 16 or above has answered at least six questions with verified specifics. Below 12 means at least four answers were feelings, and I'd want to know which four before going further.

Weight Questions 3, 4 and 5 double if you like. They're the three that decide whether you own your app. An agency can score perfectly on the rest and still leave you with a Figma link, like the founder in the opening scenario.

If you're scoring more than one agency and want a starting list, our top 10 app development companies in Los Angeles ranks firms on public, checkable attributes. Run these ten questions on your top three.

And if you're not sure the project is scoped well enough to ask good questions yet, a short discovery phase comes first. What that costs and what it should produce is in app development consulting in LA. Our own MVP development page publishes its tiers ($15,000 to $25,000 for a validation prototype, $30,000 to $50,000, and $55,000 to $75,000 or more), so you can hold our answers to a price.

Some numbers show up in every article on this topic. I left them out, and here's why.

App project failure rates.You'll see figures claiming most software or app projects fail or overrun. They usually trace back to consulting-firm surveys with definitions of failure that don't match an agency build, or to vendor blog posts that cite each other in a circle. I couldn't trace one to a primary source that measures what these articles claim, so none appears here.

An "average cost of an app in LA."Every one I found was published by an agency selling apps. They aren't neutral, so I didn't print one as fact. The only prices in this article are our own published bands and the platform fees Apple and Google state themselves.

Growth tiles from case studies.The LA Pro Security case study page has carried a lead-increase figure and an active-client count that I can't verify from anything I have. I didn't repeat them. The same standard applies to any agency's tiles, including ours.

Review ratings.I didn't quote a Clutch rating for us or anyone else, because I couldn't load the profile pages directly on the day I checked. Look them up yourself on the day you shortlist.

What I couldn't check.How long a D-U-N-S Number takes varies, and I've given no figure. Whether a specific agency needs a City of LA certificate depends on where it operates, which you'll have to confirm with them. Platform fees and CCPA thresholds were checked on September 29, 2026; both change. And the legal points are general information, not legal advice for your contract.

You can get from here to a defensible shortlist in about a week. Three steps.

1. 1.Enroll your company in the Apple Developer Program and Google Play Console today, and start the D-U-N-S request if you don't have one. It's the step with the longest wait and it protects you whoever you hire.
2. 2.Email the ten questions to your top three agencies and ask for written answers by Friday. Look up each one on bizfile Online while you wait.
3. 3.When answers arrive, score them with the table above, open every store link they send you, and read the IP assignment clause in the draft contract for the word assign.

Whoever answers all ten with documents instead of feelings is probably your agency. Time to send the email.