Someone technical you can trust to look at this.
Architecture reviews, platform decisions and second opinions on mobile projects, from a team that has shipped 52+ apps. Start with a paid 90-minute call and a written answer. No proposal, no discovery process, no six-week engagement to find out what we think.
90 minutes · Fixed fee · Written summary within 2 working days
Which page do I need?
You are here if you already have developers (or a proposal from someone else) and you need senior mobile judgement before you commit.
We give you the answer and the reasoning. We are not asking to take the work over.
You want us to build it instead
The app is broken, half-finished, or the developer disappeared
App Rescue & Code Audit → That is hands-on. This is advisory.
You already know it needs rebuilding and want it done in stages
Nothing is built and you need scope, roadmap and a real budget
The problem is that users leave, not that the code is wrong
The question is specifically about AI placement
You do not need us to build the app. You have a team, or an agency, or a proposal on your desk. What you need is someone who has made this decision fifty times to tell you whether the plan holds up: whether the architecture will still be workable in three years, whether native or cross-platform is right for your constraints rather than in general, whether the quote in front of you is fair, and whether your developers are right that it needs a rewrite. We give you the answer, the reasoning behind it, and the version of the answer you can repeat to your board without us in the room.
01. What you are actually asking
Four questions, in the buyer’s own words
"My devs say we need to rewrite it. Is that true?"
Sometimes it is. Usually it is three modules, not the whole thing, and the difference is a year of runway.
See the answer"Check this before I sign."
A proposal, an estimate, a codebase from an agency you are about to commit to. One read, before the money moves.
See the answer"Native, Flutter, or React Native: which one for us?"
It is not a quality question. It is a constraints question, and the constraints are yours.
See the answer"Will it go the distance, or constantly crash?"
The app demos well. You want to know whether it survives ten times the users, three OS releases and the developer who wrote it leaving.
See the answer02: The person on the call
Anand Yadav
I take these calls myself. That matters here more than on any other page we have, because consulting is the one service where you are not buying a deliverable. You are buying somebody’s judgement, and you should know whose.
The most useful thing I can tell you about my judgement is where it has been wrong. I have recommended Flutter for projects that should have been native, because Flutter is what I know best and it took me a few years to notice that was affecting the recommendation. That is the bias in this room, and the conflict-of-interest section below is how we control it. Anybody who tells you they have no bias is either not paying attention or hoping you are not.
03. Deliverables
What you actually get
A written answer, not a conversation you have to remember
Every engagement ends in a document, including the 90-minute one. If it was only ever a call, you cannot show it to your board or your investor.
The recommendation, and the two we rejected
Every recommendation names the alternatives we considered and why each lost. That is what makes it survive being questioned six months later.
The reasoning, in language you can repeat
Written for the person who has to defend the decision, not to prove we are clever.
The "do nothing" option, costed
Always present, always taken seriously. On a real share of these engagements it is the right answer.
Risks, ranked, with what triggers each one
Not a list of everything that could go wrong. The three that plausibly will, and the signal that tells you it is happening.
What we could not determine
Explicitly listed. Every engagement has some. A review with no unknowns section is a review that guessed.
Everything is yours
The document, the diagrams, the notes. Take them anywhere, including to the agency you are about to hire instead of us.
04. The conflict of interest, out loud
We build apps. Here is how we stop that biasing the advice.
The number one reason people do not hire a technical consultant is not price. Research put it first with a direct quote: “consultants hate code… for the consultant it’s a risk-return tradeoff that just always favors a rewrite from scratch.” That fear is rational, and it applies to us. We are an app development agency. If we tell you to rebuild, we are the obvious people to rebuild it. So here are four rules, published before you engage us. Hold us to them.
1. The consulting fee is not credited back against a build with us
This is deliberate, and it is the opposite of what we do everywhere else on this site: our App Rescue audit, our ASO audit and our definition sprints are all credited back in full against the work that follows. On this service, crediting it back would be the problem. A fee that turns into a deposit the moment we recommend more work is not advice, it is a discounted sales call. You pay for the judgement. It stays paid for whatever the judgement is.
2. The person who reviews your project is not the person who would win the build
The reviewer’s recommendation does not affect their work, their utilisation or their bonus.
3. We publish the rebuild criteria before we read anything
Same five questions on every engagement, sent to you in advance. A rebuild is only recommended when the written answer shows which specific ones failed and why repair does not fix them.
4. Every recommendation includes what it would cost you to do nothing, and to hire someone other than us
Including, where it is the honest answer, “keep your current agency and give them this document”.
And the thing none of that fixes
We know Flutter better than we know anything else, which means Flutter looks like a reasonable answer to us more often than it should. Anand says so above. The four rules are how we control it; they do not delete it. If the recommendation you get is Flutter, ask us which of the four alternatives we ruled out and why. That answer is in the document, and if it is thin, push back.
05. Process
How an engagement runs
Duration shown for the Architecture Review. The Second Opinion is steps 1, 3 and 7 compressed into one call plus a written summary.
NDA, then the question
We sign before we see anything. Then one question: what decision are you trying to make, and when do you have to make it?
The criteria go to you before we look
Rebuild criteria, review checklist, severity definitions. In advance, so the verdict cannot be reverse-engineered from what we want to sell.
Read the material
Code, repository history, architecture documents, the proposal or estimate, the crash and performance dashboards, the store listings.
Talk to your developers
Not about them. With them. They know things no repository shows, and they are usually right about more than management thinks.
Run it ourselves
Build the project from a clean checkout, on a real device. How long that takes, and how much of it is undocumented, is one of the most predictive things we measure.
Check it against the platform and legal calendar
Play target API, iOS SDK requirements, EU obligations. Architecture decisions with a date attached get flagged separately.
Write the recommendation, the rejected alternatives, the do-nothing option and the risks
Walkthrough call with you and your team, recorded
Then 30 days of follow-up questions at no charge.
06. Engagements and fees
What you can buy, and what it costs
Four units. Three of them are smaller than anything else on the market. Published rates we found elsewhere ran roughly £95 to £300 per hour, monthly retainers from about £2,500 to £30,000, and one-off audits at €6,400 for two weeks or £3,500 for four.
Second opinion
One 90-minute call on one decision (a proposal, an estimate, a stack choice, a rewrite argument) plus a written summary with the recommendation, the rejected alternatives and the do-nothing option.
Architecture review
The full process above. Code, repo history, build, developer interviews, platform calendar, written report and a recorded walkthrough.
Advisor
A set number of hours a month, on call for your team. Architecture questions, code review on the parts that matter, release problems, store rejections, hiring.
Technical due diligence
For investors and acquirers looking at a mobile product. Covers the mobile-specific risks a generic software diligence misses.
Also available inside any of the above
A workshop session with your developers on one topic: release process, testing strategy, the new React Native architecture, moving off a dead dependency. No separate fee.
07. Where the received wisdom does not survive checking
Three numbers our industry repeats that we are not going to use
We sell Flutter development. Please read the second one with that in mind.
The "10x developer"
Traceable to a real 1968 study (Sackman, Erikson and Grant, Communications of the ACM), which reported ratios between 10:1 and 28:1. The study was a small experiment about online versus offline debugging and was never designed to measure differences between individuals. When someone did design for it properly, 494 programmers each doing ten identical tasks, the middle 50% clustered within about 2x, and roughly half of all the variation was the same person differing day to day, not one person differing from another.
"Cross-platform saves 30 to 40% of your development cost"
We could not find a primary source for this. Not one. Every result is an agency blog citing another agency blog, and a large share of those agencies sell cross-platform development. We sell cross-platform development. This is the single easiest sales line available to us and we are not going to use it, because we cannot show you where the number came from. Cross-platform genuinely does save money in a lot of situations. The savings are not a fixed percentage anybody has measured.
"Gartner says most rewrites fail"
No such Gartner figure could be located. The real, traceable 2026 Gartner prediction is much narrower: more than 70% of mainframe exit projects begun in 2026 will fail to produce the intended benefits, attributed largely to overestimating what generative AI can do. That is a genuinely interesting finding. It is not about your mobile app.
And one we will not use for the opposite reason
The Standish Group’s CHAOS report is the most-quoted source in this industry. Its methodology was shown to be systematically biased in IEEE Software in 2010. We do not cite it anywhere on this site, on any page, ever.
How consulting runs
You are buying a second opinion, not a sales pitch
Sometimes the honest answer is that your team is fine and the plan is wrong. We would rather say that in week one than bill you for a rebuild nobody needed.
08. The checklist
What we look at
Published, so you can see what you are buying and rule out the parts you do not need.
Architecture and boundaries
Where the seams are, what depends on what, and how much of the app you would have to touch to change one thing. The practical question is not 'is it clean' but 'what does the next feature cost'.
The rewrite question
Against the five published criteria below, not against taste.
Platform choice against your constraints
Team skills, hiring market, how deep you go into native APIs, regulatory deadlines, budget shape, how long you have to live with it.
Build and release
Clean-checkout build time, CI/CD, signing, TestFlight and Play tracks, staged rollout, rollback. Where releases actually break is almost never the code.
Testing
What is covered, what is not, and whether the tests would catch the thing that broke last time.
Crash, stability and performance
Crash-free rate, ANRs, cold start, memory and jank, all traced to causes, on real mid-range devices, not flagships.
Dependency health
Every third-party SDK: still maintained, licence, what it costs to remove, and which one is going to be abandoned first.
Store account and asset ownership
Who owns the Apple Developer account, the signing certificates, the Play console, the analytics. Boring, and the single most common way clients lose control of their own product.
Platform and legal calendar
Every deadline in the calendar below checked against your specific app.
Data, offline and sync
What happens on a bad network, what happens on two devices, what happens when the same record is edited twice.
Mobile-specific security
Key and token storage, certificate handling, what is recoverable from a decompiled binary. Not a penetration test. These are the mobile risks a strong web or backend team has usually not met.
Where AI should run, if at all
On-device versus server, what that means for cost, latency and privacy.
The team
Bus factor, what is undocumented, what only one person knows. Written for the team, never about the team.
We advise across the stack, not just ours
Flutter, native iOS (Swift/SwiftUI), native Android (Kotlin/Compose), React Native, Cordova/Capacitor and Kotlin Multiplatform. If the right answer for you is native iOS and Android with two in-house teams, that is the answer you will get.
09. The five criteria, published in advance
When we will tell you to rebuild, and when we will not
We send these before we read your code, every time. A rebuild recommendation has to show which of the five failed, and why repairing it does not work.
Can the platform still be shipped to the stores?
The framework or a core dependency can no longer produce a build that meets current Apple and Google requirements, and there is no supported upgrade path.
Can the next feature be built at a sane cost?
Adding a normal feature repeatedly costs multiples of what it should, and the reason is structural rather than a skills or process problem.
Can it be made stable?
Crashes and data problems come from the architecture, not from a fixable set of bugs, and we can name which architectural decision causes them.
Can anyone else work on it?
The knowledge exists in one person's head, there are no tests, no documentation and no build instructions, and reconstructing that is more expensive than starting over.
Does it block something the business has already committed to?
A regulatory date, a platform deadline or a signed commitment cannot be met on the current foundation.
One failure is usually not enough
Most projects fail one of these and the right answer is targeted repair, often to three modules, not to the product. We say so, and we tell you which three.
And the option almost nobody offers: strangle it instead
Replace one screen or one module at a time behind the existing app, shipping the whole way, with a working product at every point. It is slower on paper and dramatically less risky in practice. See App Modernization & Migration.
10. The platform and legal calendar
The dates your architecture has to survive
Architecture decisions made without this calendar get expensive. Every row is first-party.
Apple: uploads must be built with iOS 26 SDK or later
Already binding. Rebuilding on the current SDK also changes how your app renders.
Google Play: new apps and updates must target API 36
Miss it and you cannot ship updates.
EU Cyber Resilience Act: vulnerability reporting
24-hour early warning, 72-hour notification, 14-day final report. An architecture and monitoring decision.
EU Cyber Resilience Act: full obligations
Plan for it in decisions you make now, not in 2027.
Android developer verification for installs outside Play: Brazil, Indonesia, Singapore, Thailand
Matters if you distribute outside the Play Store in those markets.
React Native: legacy architecture support dropped
If you are on React Native and not on the New Architecture, that is now a dated decision with a real cost attached.
Checked 11 August 2026. Sources: Apple Developer news, Google Play Console Help, Android Developers Blog, European Commission Digital Strategy (CRA), React Native New Architecture working group, flutter.dev. Next recheck due 11 November 2026. Not legal advice.
11. For investors and acquirers
Technical due diligence on a mobile product
If you are buying a company or leading a round and the product is a mobile app, generic software due diligence will miss most of what matters. The mobile-specific risk surface:
Who owns the Apple Developer account and the signing certificates. If they sit with a departed contractor or an agency, the buyer is not acquiring the ability to ship. This is the most common serious finding.
How many codebases are actually behind the product. "iOS, Android and web" sometimes means one shared codebase and sometimes means five, and the difference is the entire post-acquisition feature roadmap.
Store position and its durability: ranking, keyword position, and how much of the download volume depends on something the seller cannot repeat.
Review authenticity, and the gap between App Store and Play sentiment. A large discrepancy between the two platforms is a signal worth chasing.
Revenue concentration by platform, and what a single policy change on either store does to it.
Crash and ANR rates from the live consoles, not from a deck.
Third-party SDK licensing: what is in the binary, under what licence, and what the buyer inherits.
Whether the app can currently be built at all from a clean checkout by someone who did not write it.
Same rules as everything else on this page
Criteria published in advance, findings ranked, unknowns listed, and no interest in being hired to rebuild whatever we find.
12. How long
Timeline
One decision, one call, written summary within 2 working days
A full architecture review, report and recorded walkthrough
Included with every engagement, at no extra charge
13. Engagements
How we work together
Second opinion
90 minutes and a written answer on one decision.
Architecture review
Fixed fee, 5 working days, full written report.
Advisor
Monthly hours, on call for your team. 30 days notice either way.
Technical due diligence
The investor/acquirer scope, for buying, funding or auditing a mobile product.
The fee is not credited against a build with us
See the conflict-of-interest section above for why. It is the point of the service, not an oversight.
If you do want us to build afterwards, that is Mobile App Development, quoted separately and honestly, and we will tell you plainly if someone else is the better fit for it.
What clients say
Anand is a highly technical person, he has resolved our app's issues on time and made the apps live on Google Play and Apple App Store. He has shown his responsibility towards work. I would like to recommend him to all.
This was a long and complicated project. However, Anand executed it flawlessly. He was patient with the requirements, was a fast learner in situations where he encountered something new and was a great and prompt communicator.
He is well versed in several coding languages and provided the solution I needed. Is very good at communicating as well.
15. Stacks and tools
What we work across
Mobile
Backend and data
Build and release
Monitoring
AI in apps
We advise on stacks we do not sell
If the right answer for you is native iOS and Android with two in-house teams, that is the answer you will get, and we will help you write the job specs.
16. Work
Related work
These three are builds, not standalone consulting engagements. They are here because in each one we made the architecture decision ourselves and then had to live with it for years, which is the only real evidence that a technical opinion was any good.
Virtue Insight
code shared across 3 platforms
iOS, Android and web from largely one codebase, with real-time chat and enterprise crash reporting. The cross-platform decision, made once and measured. Engagement up 65%, 72% push open rate.
Read the case studyFidex Wallet
uptime, zero security incidents
Architecture where stability is the product. $45M under management in year one, day-30 retention 67% against a 38% industry figure.
Read the case studyQuickChain
transaction success rate
Reliability that came from error handling and network design rather than features. Settlement from 72 hours to under 60 seconds; 5,000 to 250,000 monthly users in twelve months.
Read the case study17. FAQ
Questions people actually ask
Will you sign an NDA?
Yes, before we see anything at all: code, proposals, dashboards, any of it.
Will you just tell us to rebuild it and then offer to do it?
That is the objection this whole page is built around. Four published rules and five rebuild criteria are sent to you before we read anything. The most important one: our fee is not credited against a build with us, deliberately, so that recommending more work earns us nothing today.
What if our architecture is fine?
Then the report says it is fine, we tell you what to watch for and when to look again, and we invoice the same fee. That happens, and it is a good outcome.
Do you work directly with our developers?
Yes, and it is usually the most useful format. We talk with them, not about them. Reviews are written for the team to act on, never for management to use against them.
Our devs think we need a rewrite. How do you handle disagreeing with them?
Usually they are right about the problem and the disagreement is about scope. We apply the five criteria in writing, which turns "it needs a rewrite" into "these three modules fail criterion 2, here is what repairing them costs versus replacing them". That is a conversation a team can have without anybody losing.
Can you review a proposal or estimate from another agency?
Yes. That is the most common Second Opinion, and 90 minutes is usually enough. We will tell you whether the price is reasonable, what the estimate has left out, and which three questions to send back before you sign.
Can you review a codebase you did not write, in five days?
Yes, to a specific depth. We will not have every detail of your business logic, and we do not claim to. We will have the architecture, the dependency and release risks, the stability picture, and how expensive the next feature is, and the unknowns section lists what we could not determine.
How do we know you are actually senior?
52+ apps and products shipped end to end over 7+ years, Upwork Top Rated with 100% Job Success across 54 reviews, and ten apps taken over from other developers. Anand's name is on the page and he takes the calls. Ask on the call about a project that went badly. We will answer that one.
Native, Flutter or React Native: do you have a default answer?
No, and be careful of anyone who does. There is no credible evidence that framework choice predicts business outcomes; it is a constraints decision. Our honest bias is toward Flutter because it is what we know best, which is exactly why the conflict-of-interest section exists.
Who owns what you produce?
You do: the document, the diagrams, everything. Take it anywhere, including to a different agency.
Can we hire you to implement the recommendations?
Yes, quoted separately at the normal rate with nothing credited back. And if a different team is the better fit, we will say so.
Do you do technical due diligence for investors?
Yes. The scope section has the detail. It is a different engagement with a different report.
What if we need you long term?
The Advisor model: a set number of hours a month, 30 days notice on either side.
How soon can you start?
A Second Opinion call is usually available within a few days. A full review usually starts within a week or two.
Tell us the problem. We bring the engineering.
A short call, an honest answer on whether we are the right team, and a scope you can hold us to.
Start a project