Independent consulting
A freelance mobile architect needs positioning
Why independent mobile architecture work depends on clear problems, scoped offers, proof and delivery boundaries.
By Mike Salari. Staff mobile engineer · 500+ technical interviews from the hiring side.
3 min read
Expertise is not the offer
Many senior engineers think freelancing starts by saying they can build mobile apps. That is true, but it is too broad. A buyer with a real budget usually has a sharper problem.
The app is slow. The architecture is blocking teams. The release process is fragile. The team cannot hire senior mobile talent. The SwiftUI migration is stuck. The Kotlin Multiplatform strategy is unclear.
A freelance mobile architect needs positioning around problems, not only skills.
Sell a diagnostic before a transformation
Architecture consulting is risky when the scope starts too large. A better first offer is often a diagnostic: review the app architecture, identify risks, map the migration, audit performance, review release safety or evaluate platform strategy.
A diagnostic gives the client clarity before they commit to a larger engagement. It also protects you from selling a solution before you understand the system.
The output should be concrete: findings, priorities, tradeoffs, proposed phases and what not to do.
Boundaries make you easier to buy
Clear boundaries reduce buyer anxiety. Define what is included, what is not included, how long it takes, what access you need and what the client receives at the end.
A vague offer says: I can help with architecture. A stronger offer says: in two weeks, I will audit your iOS architecture, review module boundaries, identify performance and release risks, and deliver a prioritised migration plan.
Specificity makes the work feel safer.
What a scoped diagnostic looks like
Take a team with a UIKit app that wants new screens in SwiftUI and disagrees about whether navigation moves first. The first offer is a decision, not a migration:
| Part | Boundary |
|---|---|
| Decision | Whether to migrate the account settings flow now, and where navigation ownership stays |
| Inputs | Read-only repository access, a reproducible build, the supported OS list, the release constraints |
| Examination | One agreed flow: entry points, state ownership, relevant tests |
| Deliverables | Annotated boundary diagram, risk list, alternatives, a phased recommendation |
| Time | Five consulting days inside a two-week window, once access is in place |
| Not included | Production changes, whole-app performance certification, a full security assessment, the migration itself |
Write a stop point into it. If the app does not build or the owners are unavailable, you re-scope instead of stretching the days. For each finding, record the affected path, what you observed, the consequence and the decision it blocks, and say whether you reproduced it, read it in the code or still need a test. Keep implementation a separate decision, so the diagnostic is still worth paying for if another team does the work.
Proof should match the buyer's fear
If the buyer worries about performance, show performance work. If they worry about team scale, show modularisation, ownership and standards. If they worry about fintech correctness, show reliability, security and release discipline.
Generic proof is weaker than relevant proof. The client wants to know whether you are good and whether you understand the kind of risk they are carrying.
Independence is an operating system
Freelance work needs more than technical skill. It needs scoping, pricing, contracts, communication, delivery cadence, expectation management and the ability to say no to unclear work.
The best independent engineers are not just strong builders. They reduce uncertainty for the client.
That is the positioning: trusted for the architecture decisions that are too expensive to guess, instead of available for any mobile work.
If the number is the next conversation, use Leverage before you quote it.
