Every app development agency has a great demo. Smooth animations, clean UI, confident walkthroughs. That's table stakes.

The better question: what are they willing to show you beyond the demo? The test coverage trends, the postmortem docs, the actual team who'll write your code. That's where the signal is.

The Demo Problem

Demos are optimized to win pitches, not predict delivery.

This isn't deception. It's selection bias. Every agency shows their best work, their smoothest flows, their most impressive screens. The portfolio site features the three projects that went well, not the twelve that were mediocre. The case study highlights the outcome, not the three months of scope creep that preceded it.

The demo environment is controlled. The data is fake but perfect. The user journey follows the happy path. Nothing crashes because nothing is real.

Meanwhile, the team presenting might not be the team building. The architecture shown might not be the architecture delivered. The timeline quoted assumes everything goes right, which it won't.

McKinsey found that 70% of outsourced projects fail due to poor communication. The Standish Group reports only 29% of IT projects succeed. The gap between "what we showed you" and "what we shipped" is where projects die.

What Demos Hide

The prototype-to-production gap is real. That beautiful demo might be a Figma prototype, a proof-of-concept built by senior developers for the pitch, or a reference app from a different industry running on infrastructure you'll never see. Ask directly: "Is this a production app? Can I see it in an app store? Who built it, and will they build mine?"

The senior team disappears. Proposals feature impressive bios. LinkedIn profiles show 15 years of experience. Then the contract is signed and the actual work is done by developers you've never met. Industry estimates put vendor team turnover during projects at 30-40%. The people who win the deal aren't always the people who do the work.

Reference apps age poorly. A banking app built in 2021 on React Native 0.64 tells you almost nothing about how the vendor handles React Native 0.73 in 2025. Frameworks evolve. Best practices change. Old wins don't guarantee new competence.

The difference between "we built this" and "we maintain this" matters. Building an app is one skill. Keeping it running, updated, and secure for three years is another. Ask about apps they've operated long-term, not just launched.

Five Artifacts That Actually Predict Success

Stop asking for better demos. Start asking for evidence of how they actually work.

1. Test coverage dashboards

Not a single percentage, a trend. Is coverage increasing or decreasing? What's tested: just unit tests, or integration and E2E as well? A vendor who tracks this publicly, internally, is a vendor who cares about code quality when no one's watching.

What good looks like: A live dashboard or recent screenshot showing 70%+ coverage with an upward trend. Bonus: they can explain what isn't tested and why.

Red flag: "We test thoroughly" with no numbers. "We'll set up testing after MVP."

2. Postmortem documentation

Every production app has incidents. The question is whether the team learns from them. Blameless postmortems with root cause analysis, customer impact metrics, and specific remediation steps indicate engineering maturity.

What good looks like: A redacted postmortem from a real incident showing timeline, impact, root cause, and prevention measures. They should be willing to discuss failures openly.

Red flag: "We've never had a major incident." (They have. They just don't document them.) Defensiveness when asked about past problems.

3. Release metrics

How often do they deploy? What's their rollback rate? How long between code merge and production? Deployment frequency correlates with team health and code quality. Teams that deploy weekly have figured out testing, CI/CD, and risk management.

What good looks like: Deployment logs showing regular releases (weekly or better), low rollback rates, and staged rollouts (1% → 10% → 50% → 100%).

Red flag: "We do big releases quarterly." No visibility into deployment history. Manual deployment processes.

4. Architecture diagrams (real ones)

Not the marketing version with clean boxes and arrows. The actual system diagram showing services, dependencies, data flows, and failure points. If they can't produce this for existing projects, they won't produce it for yours.

What good looks like: A diagram that includes the messy parts, third-party dependencies, legacy integrations, known bottlenecks. They should be able to walk you through failure scenarios.

Red flag: "We'll design the architecture after discovery." Diagrams that look like they came from a sales deck.

5. Named team with anti-swap clauses

Who exactly will write code on your project? Not roles, names. With bios. And a contractual commitment that these specific people will remain on the project, with defined notice periods and replacement approval rights if changes are necessary.

What good looks like: You meet the actual developers before signing. The contract includes team continuity clauses with teeth.

Red flag: "We'll assign the team after kickoff." Vague role descriptions instead of named individuals. Resistance to contractual team commitments.

Questions That Make Bad Vendors Squirm

Use these in your next evaluation. The answers, or the evasions, tell you everything.

"Show me your last three production incidents."

Good vendors discuss failures openly. They've learned from them. They have documentation. Bad vendors get defensive or claim perfection.

"Who exactly will be writing code on my project?"

Names, not roles. If they can't answer, the team doesn't exist yet. You're buying a promise, not a capability.

"What's your rollback procedure if a release fails?"

Every mature team has one. If they hesitate, they're either inexperienced or reckless. Both are disqualifying for enterprise work.

"Can I see your CI/CD pipeline?"

Not a diagram, the actual pipeline. Build logs. Deployment history. This separates teams who talk about DevOps from teams who practice it.

"What's your crash-free session rate on live apps?"

A specific number indicates they measure. "Very high" or "we don't track that" indicates they don't. For enterprise apps, you want 99.5%+ and a team that obsesses over getting higher.

The Evaluation Shift

Traditional vendor evaluation rewards presentation skills. The best slides, the smoothest demos, the most confident sales engineers.

Artifact-based evaluation rewards engineering discipline. The teams that document, measure, and learn. The teams that can show you how they work, not just what they've built.

This shift disadvantages vendors who've invested heavily in sales and marketing. It advantages vendors who've invested in engineering culture. That's the point.

The vendors who squirm when you ask for postmortems are telling you something. The vendors who light up, who pull up dashboards and share war stories and debate architecture decisions with obvious enthusiasm, are telling you something too.