Cross Platform Consultation
Three weeks, a fixed price, and a document that says which platform strategy we would choose and why. Including, often enough, that you should stay where you are.
- Duration
- Three weeks
- Team shape
- One senior engineer, one architect
- Ends with
- A written recommendation
Consolidating two apps is a bet, and it should be priced as one
The case for moving two native apps onto one codebase is usually made on a saving that sounds obvious and is rarely calculated: one team instead of two, one implementation instead of two. Whether that materialises depends on how much of your cost is genuinely duplication, and for some products the answer is very little.
This is a fixed-scope engagement with a fixed price and a written output. We look at both existing apps, what they reach on the device, what your team can maintain, and what the migration would actually cost against what it would actually save. Then we come back with a recommendation and the arithmetic. Staying native is a legitimate result, and it is the one we reach more often than you might expect from this page.
What usually goes wrong, and what we do instead
The failure mode is a platform decision made on a saving nobody calculated.
Where platform decisions go wrong
- A consolidation saving assumed rather than worked out against real costs
- The device capability requirements never enumerated properly
- The migration costed and the ongoing framework upkeep forgotten
- A framework chosen for its benchmarks rather than for who will maintain it
- An assessment run by a firm that only sells one of the answers
How we run it instead
- The saving calculated against your actual team and release costs
- Everything the apps reach on the device, enumerated and tested
- Migration and three years of upkeep costed together, not separately
- The framework decision derived from hiring as much as from capability
- A recommendation that can be 'stay native', and frequently is
What the three weeks cover
The same ground every time, because the arithmetic is usually where the surprise is.
01
The existing apps
What each one does, how much of it is genuinely duplicated, and how much only looks duplicated.
02
Device capability requirements
Everything the apps reach on the hardware, enumerated and checked against what a shared layer can do.
03
The team and the market
Who maintains this in three years, what you can hire for, and what a framework choice commits you to.
04
The actual cost today
What two apps really cost you in build, release, test and coordination — measured rather than assumed.
05
Deployment constraints
Store rules, device management and security requirements, on both platforms.
06
The options
Stay native, consolidate, or consolidate partially — costed over three years, including the migration.
How we reach a recommendation
Four questions, asked in order. A no at any of them changes the answer, and we say so rather than continuing to the next.
Is the duplication real?
Two apps can look duplicated and share almost no logic worth consolidating.
- How much of each codebase is business logic rather than platform work
- Whether the two apps actually behave the same today
- What proportion of changes currently have to be made twice
Can a shared layer reach what the apps need?
This is a capability question with a factual answer, and it is worth establishing before any other argument.
- Every device capability the apps use, and how deeply
- Which of those would need native modules anyway
- What performance the app has to hold on your slowest device
Does the arithmetic work?
A consolidation that pays back in five years is not a saving, it is a preference.
- The migration cost, honestly sized
- The ongoing framework upkeep that native does not have
- The payback period, and what would have to be true for it to hold
Who maintains it afterwards?
The best framework for a team that cannot hire for it is the wrong framework.
- What your team already writes, and what they would have to learn
- What you can hire for in your market
- Whether the choice narrows your options in three years
What you end up with
Stated from your side rather than ours.
A document you can act on
Precise enough to plan from or take to a board, and readable by people who were not in the room.
The arithmetic, not the assumption
The consolidation saving calculated against your real costs, with the migration and the upkeep both counted.
An answer that can be 'stay native'
We are paid for the assessment rather than for what follows it, which is what makes that recommendation possible to give.
A defensible first step
If consolidation is right, the one part of the app that should move first, sized and costed.
How the three weeks run
The same five stages as every engagement, compressed into a fixed scope.
Diagnose
Week one: both codebases, the device capability requirements, and what two apps actually cost you.
Decide
Week two: options costed over three years, with the migration and the upkeep both counted.
Prove
Where a capability or a performance question decides the answer, we build the smallest thing that tests it on real hardware.
Deliver
Week three: the recommendation written, then walked through with the people who have to act on it.
Hand over
The document is yours, including if you take it to somebody else to act on.
What you get, and when
One document, and the working material behind it.
- How much of the two codebases is genuinely duplicated
- Every device capability the apps reach, enumerated
- What two apps cost you today, measured rather than estimated
- Stay native, consolidate, or consolidate partially, over three years
- The framework comparison, decided on maintenance as much as capability
- The payback period and what would have to hold for it
- One recommendation, with the arithmetic that produced it
- A sized and costed first move, if there is one
- A walkthrough with your team, and the document to keep
Where it can lead
Three of the seven ways we work. Which one follows an assessment depends on what it found, and none of them is the default.
Discovery / Assessment
A time-boxed investigation that ends in a written recommendation, including the recommendation not to build. You can act on it with us or without us.
Best when the problem is agreed and the solution is not.
- Where it fits: a business case nobody can evidence, or a system everyone blames.
- A written problem statement, the options considered, and the reasoning for each.
- You own the decision at the end; we own the evidence behind it.
Consulting / Advisory
Senior engineering judgment applied to decisions you are already making — architecture, vendor choice, a rebuild someone has proposed. No delivery attached.
Best when you have the team but not the second opinion.
- Where it fits: an in-house team facing a decision it cannot take twice.
- Architecture review, technology selection, or a rebuild proposal tested before it is funded.
- You own the decision and the delivery; we own being right about what we told you.
Fixed-Scope Delivery
A defined piece of work, scoped and priced up front, delivered end to end. Scope changes are re-priced in the open rather than absorbed quietly.
Best when the scope is stable enough to write down and hold.
- Where it fits: a replacement, an integration, or a first release with firm edges.
- Fixed budget, so the risk of a wrong estimate is ours, not yours.
- We own scope, estimate and delivery risk; you own acceptance.
The rest of our cross-platform work
Shared-codebase engagements overlap more than most. These are the neighbouring ones.
Related work
Engagements where the platform decision mattered as much as the delivery.
Questions about the assessment
The ones we are asked most often before a first conversation.
What does it cost?
Do you actually recommend staying native?
We have no apps yet. Is this the right assessment?
Could we consolidate only part of the app?
Do we own the document?
Are we committed to working with you afterwards?
Weighing up one codebase or two?
Tell us what you run today. Three weeks is usually enough to do the arithmetic properly.