What Should You Ask in the First Discovery Call?
A 2025 Standish Group study found that 68% of outsourced software projects come in late, over budget, or short on the scope everyone agreed to. Here is the part that stings. Most of those failures were catchable during evaluation, before a contract existed. And the first real call with an agency will tell you more than their whole website if you push on the right questions.
1. "Show me a case study that matches my industry." Anyone can assemble a glossy portfolio. What you actually want is proof they have solved a problem shaped like yours. Building a fintech app? A food-delivery case study tells you nothing about whether they can survive PCI compliance or handle real-time transaction flows under load.
2. "What's your developer retention rate?" Turnover is the quiet project killer nobody warns you about. When their senior Flutter developers churn out every eight months, you inherit a mid-project handoff that quietly eats three or four weeks of velocity. The good shops hold onto people for two years and up.
3. "Who will actually work on my project?" The classic move: parade the A-team through the sales calls, then quietly staff your build with juniors once the ink dries. So ask for names. Ask to interview them. A flicker of hesitation here tells you plenty.
4. "Walk me through your code review process." No pull request should hit main without at least one human reading it first. Ask who does the reviewing, what they actually look for, and how they settle disagreements when two seniors disagree. No review process means no quality control. It is that blunt.
5. "What happens when a developer leaves mid-project?" It happens. Not maybe, eventually. The answer you want sounds like documented knowledge transfer, a replacement inside one to two weeks, and a few days where the outgoing and incoming developer actually overlap. The answer that should worry you is dead air, or a confident "that doesn't happen here."
How Do You Evaluate Their Flutter Code Quality?
The 2024 Veracode State of Software Security report puts it bluntly: 74% of applications have at least one security flaw, and third-party code is one of the main ways those flaws get in. You can't judge any of this from a pitch deck. You have to read the code.
Request an anonymized code sample from a recent project. Any serious agency hands one over without drama. Redacting client info is fine. A flat refusal to share anything at all is a red flag. So, what are you reading it for? A few things:
State management pattern: Do they stick to one approach, whether that's BLoC, Riverpod, or Provider? When you see all three jostling inside a single project, that's architectural chaos showing through. Good teams pick one pattern and hold the line on it everywhere.
Test coverage: Just ask for the number. On a production app, anything under 60% means bugs are reaching real users. You want unit tests sitting on the business logic, widget tests covering the UI flows that matter, and at least a handful of integration tests tying it together. Zero tests? Walk away.
Linting and null safety: Look for a real analysis_options.yaml that is actually configured, not an empty stub. Full null safety should be on. If an agency is still shipping legacy nullable code in 2026, they simply haven't kept pace with where Flutter has gone.
Red flags in code: Deprecated packages rotting in pubspec.yaml. Business logic stuffed inside UI widgets. No real line between the data, domain, and presentation layers. Strings hardcoded where localization should live. Platform channels invoked with no error handling around them. Spot any of these and you're looking at a team that ships fast but doesn't ship clean.
What Does Their Development Process Reveal?
A 2025 Digital.ai State of Agile report found that teams using CI/CD deploy 208x more frequently than the teams without it. Process is the line that separates a real agency from a loose group of freelancers wearing an agency logo.
Sprint length and demo cadence. Two-week sprints that end in an actual demo are the floor here, tracked in Jira, Linear, or ClickUp with story points and a velocity you can read. Go longer than three weeks between demos and you're flying blind. What you want is working software in front of you on a rhythm, not another status report.
How they handle scope changes. Scope always moves. That's just reality on any build worth doing. A good agency runs it through a change-request process where the change gets documented, the impact gets estimated, you approve, and the sprint adjusts. A bad one either fights every change or swallows them quietly and then misses the deadline anyway.
CI/CD pipeline. Does a merge to main automatically fire off tests and a build in GitHub Actions, Codemagic, or Bitrise? Can they push to TestFlight and Google Play Console straight from that pipeline? Because if developers are building APKs by hand on their laptops and uploading them one at a time, the whole thing is held together with tape. A real pipeline also runs the Dart analyzer and flutter test on every single push.
Hotfix protocol. A production bug at 11pm does not politely wait for the next sprint planning. So ask how they deal with a P0. The answer should sound rehearsed: branch off main, fix it, test it, deploy, then backport into the development branch. No hotfix process usually means one thing. They haven't shipped enough apps to have ever needed one.
Curious how we actually run this? Here's exactly how a Geminate Solutions engagement works, start to finish, from the first discovery call all the way to production deployment.
How Do You Verify Their Track Record?
Clutch's 2025 B2B Buying Behavior Survey found that 89% of buyers check online reviews before they pick a service provider. Smart. But reviews are a single signal, and you need more than one. Treat verification as layers, not a checkbox.
Check Clutch and G2 reviews, but read them critically. Hunt for the detailed ones that name specific project types instead of floating generic praise. A review that says "great communication" is nearly worthless next to one walking through how the agency handled a production outage at 2 AM.
Contact their references directly. Ask for three, then actually call them. Two questions do most of the work here: "What went wrong during the project?" and "Would you hire them again?" If a reference cannot name a single rough patch, that reference was coached. Real projects always have a war story.
Check their freelance marketplace history. Where a profile exists on the major freelancer platforms, dig into the job success rate, the length of the contracts, and whether clients kept coming back for more. A 95%+ job success score sitting on 20 or more contracts is a genuinely strong signal, not marketing.
Examine their published case studies. Do the numbers show up, things like "reduced load time by 40%" or "scaled to 250K daily active users", or does it stay fuzzy with "improved performance"? Hard numbers come from teams that measure their own work. Fuzzy claims come from teams that never did.
We've shipped apps serving 250K+ daily users. See the case study for the real version: the architecture calls we made, the challenges that nearly derailed it, and the outcomes we could actually measure.
What Contract Terms Protect You?
A 2024 Gartner survey found that 53% of IT outsourcing disputes trace back to vague contract terms, not technical failures. Let that land. The contract is what protects you when things go sideways. And on a long build, something always goes sideways eventually.
IP ownership must be explicit. The contract should say it plainly. Every line of code, every design, every doc produced during the engagement is yours. Not "upon final payment." Yours from the moment it's created. And if the agency is quietly keeping any right to reuse your code elsewhere, you want that surfaced upfront, not discovered later.
Code escrow for fixed-price projects. Paying in milestones? Then the code should be in front of you the whole way through, never held hostage behind a final invoice. A shared Git repo settles this in about five minutes. When an agency insists on handing over code only at completion, you're left with zero visibility into how it's actually going.
Payment milestones tied to deliverables, not dates. "Pay 30% on signing, 30% at beta, 40% at launch" beats "pay monthly no matter what shipped" every time. When money is pinned to working software, both sides end up wanting the same thing.
Developer replacement guarantee. Spell it out in writing. If a developer leaves or just isn't pulling their weight, the agency puts a replacement in within a defined window, usually one to two weeks, and you don't pay extra for the overlap during the transition.
Right to audit and exit clause. You should be free to review code quality whenever you want, not on their schedule. And the exit clause needs a sane notice period, 30 to 60 days, not a six-month lock-in stacked with penalties. A real development partner earns the next month of your business. It doesn't trap you into it.
What Are the Red Flags That Should Make You Walk Away?
Plenty of agencies that look great on paper still deliver mediocre work. We've watched a lot of these engagements up close across our mobile development practice, and a handful of patterns reliably predict a bad ending. Here they are:
No portfolio or a vague one. "We've built apps for various industries" with no screenshots, no metrics, and not even an anonymized client name attached? That means they've either done nothing meaningful or can't put it on display. Either way, it's your problem now.
They won't share code samples. Real agencies anonymize a sample and share it precisely because they're proud of the quality. A hard no usually means the code wouldn't hold up under a careful read. Some hide behind NDAs, which is fair enough on paper, but they can always fall back on personal projects, open-source contributions, or even a clean architecture diagram.
Pricing well below market rate. Senior Flutter developers run roughly $3,000-7,000/month globally. So when an agency quotes you $1,200, do the math. They're either staffing it with juniors or planning a bait-and-switch the moment you sign. Cheap development almost always costs more once the bill for the rework lands.
No process documentation. Ask to see their development workflow doc. No doc means the process is ad hoc, reshaped by every new project and every new developer who walks in. That kind of inconsistency shows up in the product eventually.
The founder can't explain their tech stack choices. Why Flutter and not React Native? Why Riverpod over BLoC? Why Firebase instead of Supabase? Technical leadership should fire back clear, opinionated answers without flinching. "We use whatever the client wants" isn't a strategy. It's a tell that they don't have one.
Unrealistic delivery promises. When one agency swears your complex app ships in 4 weeks and everyone else quoted 12, something is off. They're either lying or quietly planning to cut corners you never agreed to. Fast is great. Suspiciously fast is a warning sign.
Honestly, a 30-minute discovery call tells you more than a 30-page proposal ever will. Book one and bring this checklist with you. We'll answer every question on it, no dodging.
