How We Work
Method, and the parts of it that cost us work.
Evidence before recommendation
Every recommendation we make points at something in your repository: a named renderer, a named package, a named binding, a build log. You can check it, and your own developers should. A migration plan written from a discovery call is a sales document.
Rescue before rewrite
If a store deadline lands before any realistic migration date, the deadline wins and we say so. Getting one more compliant release out of the app you have is frequently the cheapest correct answer, and it is not the answer that maximises our hours.
Characterization tests before the UI layer
Shared business logic gets tests that pin its current behaviour before any screen is touched. Not aspirational tests — tests that assert what the code does today, including the parts that are arguably wrong. That is what makes "the migrated screen behaves the same" a checkable claim instead of an assurance.
Releasable slices
Work lands in slices that each end at a shippable build. The app does not go dark for a quarter, production stays patchable, and a slice that turns out to be wrong costs one slice.
We say what should not be migrated
Screens nobody opens, flows built for a process that changed, renderers written around framework bugs that were fixed years ago. These go on a retire list in the assessment, with the reason. A migration is the cheapest chance you will get to delete code, and naming the list up front is worth more than discovering it in month three.
We do not pretend Xamarin has a future
Xamarin support ended in May 2024 and it is not coming back. We do not sell "Xamarin development" as a growth path, and we will not help you write a business case that assumes one. What we sell is keeping a revenue-carrying app shippable while it moves to a supported stack, and being honest when the right answer for a module is to retire it rather than port it.
That cuts the other way too. If an assessment concludes your app is better served by a native rewrite, or by not existing, the document says so. We charge for the assessment and not for a predetermined answer.
Senior, US-based, in your repository
Every engineer on an engagement is senior and US-based, working in your repository, your pipeline and your signing setup, in your time zones. There is no delivery layer between you and the person changing your app.
Handover is part of the work
Engagements end with documentation and with your own .NET developers having done some of the conversions themselves. The measure of a finished migration is that your team can take the next OS release without calling anyone.
How we charge
Hourly, on a time-and-materials basis, as project work or staff augmentation. Scope, staffing and timeline are agreed in an initial conversation. No fixed-price packages, and no published rates: a fixed price on an undocumented mobile codebase is either padded or about to be renegotiated.