The previous developer left
You have the source code, but the architecture, build setup, backend dependencies, or release process are unclear.
[ENG-SERVICES] // Mobile App Rescue
Inherited a mobile app that's becoming a problem?
I help teams diagnose, stabilize, and continue developing existing Flutter, React Native, Android, and iOS applications.
If the previous developer left, the project no longer builds, bugs keep returning, backend state is unreliable, or the release is blocked, I can find the important issues and create a practical recovery plan.
A rewrite should be a conclusion, not a sales tactic.
- Existing codebases welcome
- Flutter & React Native
- Kotlin & Swift when needed
- Backend / Supabase
- Production debugging
- Release support
01 // Sound familiar?
Most rescue projects begin with symptoms, not a clean technical diagnosis.
You do not need to translate the problem into engineering terminology before getting help.
The project no longer builds reliably
Dependencies, SDK versions, signing, native configuration, or environment setup have drifted.
The same bugs keep returning
Visible symptoms are being patched without resolving the underlying state, API, lifecycle, or architecture problem.
The release is blocked
A build, store requirement, crash, authentication flow, payment, deep link, or backend dependency is stopping deployment.
The app has been almost finished for months
The remaining integration, testing, release, and edge-case work has become the hardest part of the project.
The product state is unreliable
Caching, realtime events, backend behavior, or lifecycle handling leaves the interface out of sync until restart.
SYMPTOM 07
Nobody knows whether to repair or rewrite
A responsible answer requires enough inspection to distinguish localized risk from a fundamental constraint.
02 // My approach
Understand before rebuilding.
Existing software contains history, constraints, shortcuts, useful work, and sometimes genuinely bad decisions. Those cannot be evaluated responsibly from a screenshot or a short call.
I inspect the application, reproduce important failures, understand the architecture and dependencies, and identify the highest-risk areas before recommending large structural changes.
03 // Technical review
Find the real blockers, not a hundred-item audit nobody can act on.
The review is grouped around whether the application can be changed, tested, and released safely.
Build health, dependencies, and documentation
Builds, SDKs, environments, signing, CI/CD, obsolete or incompatible dependencies, setup instructions, environment configuration, and release ownership.
Architecture and maintainability
Project structure, state management, networking, responsibility boundaries, coupling, error handling, testability, and the tests protecting critical logic.
Critical user flows
Onboarding, authentication, password reset, payments, subscriptions, notifications, deep links, account deletion, and the product's primary workflow.
Backend, APIs, state, and synchronization
Authentication state, APIs, storage, authorization, realtime subscriptions, caching, race conditions, duplicate events, stale UI, and lifecycle behavior.
Native configuration and release readiness
Gradle, Android manifests, Xcode, entitlements, URL schemes, permissions, push configuration, signing, production endpoints, and store submission blockers.
04 // How it works
A rescue should happen in stages.
Evidence comes before random edits. Each stage reduces uncertainty before the next commitment.
STAGE 01
Access
Gather the repository, build context, known symptoms, and only the permissions needed for the first phase.
STAGE 02
Reproduce
Run the app, observe the important failures, collect logs, and confirm the expected behavior.
STAGE 03
Diagnose
Separate visible symptoms from their state, API, lifecycle, native, backend, or architecture causes.
STAGE 04
Prioritize
Rank launch, security, login, payment, and core-flow blockers ahead of polish.
STAGE 05
Stabilize
Restore a safe build and repair the critical failures preventing reliable development or release.
STAGE 06
Recover
Finish priority work and refactor only where it removes a demonstrated risk.
STAGE 07
Continue
Move into features, maintenance, backend work, or release support only if it remains useful.
Repair or rewrite should be a finding, not an assumption.
Not sure which path is appropriate? Start with the evidence.
05 // Repair or rewrite
Should the app be repaired or rewritten?
Both are possible outcomes. The decision follows inspection and depends on product requirements, economics, and risk—not developer preference.
Repair may make sense when
- The architecture is imperfect but workable
- Major flows can be stabilized
- Useful product work already exists
- Risks are localized
Rewrite may make sense when
- Fundamental architecture prevents safe progress
- Core dependencies or implementation are unsustainable
- The system cannot reasonably meet product requirements
- Repair cost and risk clearly exceed replacement
Messy code alone is not enough reason to throw away useful product work.
06 // Problem categories
Mobile problems rarely stop at the mobile interface.
I follow the failing product flow across platform boundaries instead of treating each technology as an isolated directory of skills.
Build & environment
Builds, signing, SDKs, dependencies, CI/CD
Authentication
Sessions, verification, password reset, deep-link return
Deep links
App links, universal links, intent filters, URL schemes
Notifications
Push setup, events, badges, foreground and background behavior
State & realtime
Stale UI, caching, subscriptions, races, duplicate events
Backend & APIs
Supabase, storage, authorization, functions, integrations
Payments
Checkout, subscriptions, entitlements, restore purchase
Native configuration
Kotlin, Swift, permissions, manifests, entitlements
Performance
Slow flows, rendering, networking, memory, startup
Release & stores
Production configuration, signing, submission blockers
Maintainability
Architecture, error handling, tests, documentation
FEATURED // Relevant experience
Product engineering across mobile, backend, and AI systems.
SettleTab and Tare show product work spanning mobile, backend, and AI. They are relevant product-engineering examples, not rescue engagements.
Mobile Product Development · AI Product Integration
SettleTab
SettleTab is a live Android app for itemized shared bills. People can scan a receipt or enter items manually, correct the bill, assign individual and shared purchases, calculate what each person owes, and share a read-only result.
Shashank Sangule · Founder & Lead Developer, DivWeavers
AI Product Integration · Mobile Product Development
Tare
Tare is a mobile habit reflection app that saves original check-ins, proposes structured fields for user review, and uses recorded history for progress views and insight paths.
Shashank Sangule · Founder & Lead Developer, DivWeavers
SCOPE // Responsible scope
Reliable estimates need evidence.
For an existing codebase, I prefer to review the repository and reproduce the main issues before committing to a detailed implementation estimate.
Small understood bug
Hourly work or a small fixed scope can fit a narrow, reproducible issue.
Unknown inherited codebase
Start with technical discovery or a capped review to identify the real risks.
Larger rescue
Move from discovery into a prioritized implementation plan, milestones, or weekly capacity.
FAQ // Common questions
App Rescue FAQs
Do I need to know what's technically wrong?
No. Symptoms and expected product behavior are enough to begin. The initial review is designed to find the important causes.
Do you work with code written by another developer?
Yes. Inherited repositories, incomplete handoffs, and limited documentation are normal App Rescue situations.
Do you always recommend a rewrite?
No. I preserve useful work and recommend replacement only when inspection shows it is the safer and more economical path.
Can you work with Flutter and React Native projects?
Yes. Flutter and React Native are both strong fits, with Kotlin or Swift work where native configuration or integrations require it.
Can you handle backend and platform-specific problems too?
Often, yes. I work across authentication, Supabase/PostgreSQL, APIs, storage, realtime behavior, server functions, and Android/iOS configuration.
Can you estimate before seeing the code?
I can discuss rough scope, but a reliable implementation estimate usually requires reviewing the relevant repository and reproducing the main issues.
Can you continue after stabilization?
Yes. The work can continue into features, maintenance, backend work, and release support, or end cleanly after the rescue phase.
Get a clear technical path forward.
Send the current symptoms, repository status, and the outcome you need. A short description is enough to start.