How We Eliminated Separate iOS and Android Maintenance in Six Months

Netsujo Inc. replaced an HR Tech SaaS provider's business app using React Native and TypeScript. We completed requirements definition through release in approximately six months, brought the iOS and Android implementations into one codebase, redesigned the interface, and stabilized the app after launch. Maintenance has been handed over, Netsujo’s scope of work is complete, and the app remains in operation.

The value of this work went beyond choosing a new framework. We examined which functions people actually used, reconstructed the meaning of legacy data, and changed the maintenance structure so the product could continue evolving after release. Here is how we connected business needs, implementation choices, migration, and operations in a real client engagement.

We present this work through an FDE (Forward Deployed Engineer) lens: understanding the client’s operations and connecting requirements, engineering decisions, release, and maintenance handover.

We took on a business-speed problem rooted in technical debt

The existing app had accumulated many years of feature additions and a large codebase. The iOS and Android versions were developed and maintained separately. Changes to a feature therefore required work in both environments, while impact analysis on older code slowed new development and lengthened the release cycle.

Users also faced an interface that had become harder to use. Technical maintenance costs and everyday usability were both affecting the product's ability to improve.

The data layer introduced another challenge. Parts of the legacy schema lacked adequate documentation. Before releasing a replacement, the team needed to understand which records had to move, how the old and new apps would coexist during transition, and who would maintain the result. The client did not have enough spare internal engineering capacity to lead a large replacement alone.

Netsujo staffed the work with one project manager who also worked as an engineer, and two development engineers. We took responsibility for requirements, architecture, development, release work, post-launch stabilization, and the maintenance handover. This combination let us address the technical and delivery decisions together.

We began by inventorying every screen and feature

Copying every function from the old application into new code would have preserved much of the old complexity. During requirements definition, we inventoried all existing screens and functions instead.

We then assessed functions against two criteria: frequency of use and impact on business operations. A frequently used screen requires careful continuity. An infrequently used action may still be critical to a business process, while another feature might no longer justify being carried forward. This assessment also helped us identify unused functions and narrow the replacement scope.

The distinction mattered. Removing functions solely to reduce engineering work could disrupt users. Keeping everything without examining its purpose could recreate the same maintenance burden. By relating function priorities to real use and operational impact, we made the first replacement scope more concrete.

Our public case record does not quantify the number of screens or features removed. What we can document is the inventory method, the two assessment criteria, and the resulting scope definition before implementation.

We chose a full replacement over incremental repair

We evaluated incremental changes alongside a complete rewrite. In this project, two structural problems would remain under a series of small fixes: separate native codebases for iOS and Android, and deeply accumulated technical debt. Maintaining both implementations would continue to duplicate engineering work.

We therefore judged that a full replacement would have a lower total cost for this particular situation. We selected React Native and TypeScript to consolidate both platforms in a shared codebase. That also made it easier to use engineers with web-development experience on future changes.

This was a decision about the product's maintenance model, not an endorsement of rewriting every old app. A stable application with a narrow set of defects may be a better candidate for incremental improvements. The relevant comparison includes migration risk, continued maintenance, availability of engineers, and the number of times a change must be implemented.

The same reasoning is useful when deploying AI or SaaS software into customer environments. An integration choice should be assessed against the work of keeping it current, recovering from failures, and supporting new use cases after the initial launch.

We investigated undocumented legacy data and prepared the migration

A new interface would not make the replacement usable if the old data could not follow the users. In this engagement, the legacy schema was not fully documented. We reconstructed the old schema and developed migration scripts to bridge the existing data model and the new application.

This is more than a mechanical change to table names. The relationships among records, the meaning of the fields, and the information required by business workflows need to remain coherent when the application changes. Our work included investigating that structure and preparing the migration approach.

We then handled app-store submission and release activities, followed by stabilization work after launch. Netsujo’s scope of work is complete and maintenance has been handed over. The app remains in operation on the consolidated codebase.

Those are the implementation and operational activities documented in our case study. The acceptance framework below is our recommendation derived from the experience; it is not presented as the original client's test specification.

What we delivered, and what changed after launch

The engagement produced concrete changes:

Our published case study also records positive feedback on the refreshed UI from staff using the product, shorter release cycles, and faster feature delivery. The work resolved the need to maintain the same changes in two independent platform codebases.

We do not attach invented percentages to those results. Hours saved, release-frequency multiples, user retention, and revenue impact were not disclosed as comparable measurements for this project. We report the completed engineering work and the qualitative improvements recorded in our case evidence.

How we use these lessons in FDE-style delivery

When software is intended to support a customer's business, implementation and day-to-day operations belong in the same plan. We recommend organizing acceptance around interface and workflow, data, and operations.

For interface and workflow, verify that frequently used actions and operations with high failure impact can be completed in the new system. For data, verify the required records and relationships after migration. For operations, identify who will address incidents, support requests, and future changes once users switch over.

This three-part structure is a practical interpretation of the work we carried out in the HR Tech engagement. Actual acceptance tests depend on the customer environment, permissions, personal data, migration windows, and operational risks. We are not claiming to reproduce confidential test artifacts.

In our project, we carried the work through requirements, implementation, migration preparation, release, and maintenance handover. We believe an FDE-style practitioner creates value by understanding the operation the software must serve and connecting technical change to a maintainable production workflow.

Discuss a legacy app or integration with us

If an existing app has grown difficult to maintain, if iOS and Android changes are duplicated, or if you are concerned about migration and support after a rewrite, Netsujo Inc. can begin by assessing the current functions, data model, and maintenance responsibilities. We can compare incremental improvement with full replacement for the specific situation.

Our work combines requirements and technical assessment with engineering delivery and, where agreed, release and maintenance handover. The exact implementation and operational responsibilities are defined for each engagement.

Our HR Tech mobile-app engagement (Japanese-language page) / Discuss AI implementation or engineering support

---

Our first-party case record: Business-app full replacement (Japanese-language page). The approximately six-month delivery, three-person team, React Native replacement, data migration work, maintenance handover, UI feedback and release-cycle improvements are recorded in our case study. The FDE-style acceptance framework is our recommendation.