Rebuilding a Student Mentoring Platform for Two Markets

Refactoring wins when the core data model and module boundaries still match how the product works, and the problems sit in specific areas you can fix one at a time. A rewrite starts to make sense when instability has no single cause, every fix creates a new defect, and the stack itself limits what the product can do next. The decision should come out of an audit, not out of frustration, because a rewrite carries real risk to features users rely on. On this project, MobiDev ran a software audit and built a tech strategy before rewriting the architecture.

A useful audit covers code quality, architecture, infrastructure and deployment, security, test coverage, and the third-party services the product depends on. It should end with a prioritized list of problems and a recommendation on what to fix, replace or rebuild, with effort estimates. Without that, a modernization budget is a guess. Here the audit identified the system’s limitations and fed directly into the tech strategy for the rebuild.

Modernization projects usually focus on the backend, and the interface gets carried over with the same friction it had before. A UX/UI audit checks whether the flows users depend on still make sense before the rebuild locks them in again. It costs far less to change a flow in a design file than after it is rebuilt in code. On this platform the UX/UI audit was the first stage of the work, and a UX/UI designer reworked the interface based on its findings.

Start with what actually differs between markets: language, payments, legal and data rules, user types, and how the product is sold. If the differences are mostly settings, one platform with regional configuration is cheaper to run. If they reach into the data, the integrations or the business model, a separate deployment can be simpler. For this client, MobiDev cloned the platform and gave the new version a different API and database, so the platform for Asian high schoolers runs on its own.

A multi-tenant setup means one codebase, one release cycle and lower hosting costs, but every change has to work for every market. Separate deployments keep markets isolated, so an outage, a data rule or a feature request in one does not touch the other, at the cost of maintaining two systems. Teams that pick separate deployments need strong CI and automated tests to keep both in step. This client runs two independent platforms on separate APIs and databases, with continuous integration in place.

PHP remains a practical choice for web platforms with a lot of business logic, and it is cheap to host and staff. Within PHP, Laravel has the larger community and hiring pool, while Yii 2 is a mature, performant framework that suits teams already working in it. Node.js wins when the product is real-time heavy and the team writes JavaScript end to end, and Python wins when data and machine learning sit close to the core product. This platform runs on PHP, Yii 2 and MySQL, with Nginx with Nchan module handling the web and real-time layer.

Stability problems often come from how changes reach production as much as from server capacity. Automated deployment, a continuous integration pipeline and tests on the API layer catch regressions before users see them, and make releases routine instead of risky. Capacity work, caching and query tuning come next, guided by monitoring rather than guesses. On this project, MobiDev evolved an Ansible-based deployment into continuous integration with Fabric and Jenkins and added API autotests in Python.

A dedicated team fits a defined, heavy scope like a rebuild, where the vendor owns delivery and project management. Team augmentation fits once the product is live and the client has the capacity to run the roadmap, because the client sets priorities and the external engineers work inside their process. Switching at the right time keeps costs aligned with the amount of work. This client started with a dedicated team of 5 experts and moved to augmentation after the new version went live, with project management on the client’s side.

Support covers bug fixes, security and dependency updates, changes forced by third-party services and app stores, performance work, and small feature releases. The cost depends on how many integrations the product has, since each one changes on its own schedule. Support goes smoother when the team that built the system stays involved. MobiDev has kept both of this client’s platforms updated since launch.

Card processors cover most Western markets, but users in some regions expect local wallets and payment methods, and missing them hurts conversion. The integration work includes currency handling, refunds, reconciliation and the provider’s compliance requirements. Adding a second provider is easier when payments sit behind a single internal interface. The stack for this project includes both Stripe (including Alipay).

The realistic first step is ranking: using profiles, goals and past interactions to put the most relevant matches at the top, instead of relying on filters alone. Semantic search, which finds mentors by meaning rather than exact keywords, is the second. Both work best as an addition to existing search, where results can be compared against what users already get. This platform already has Algolia integrated for search, which gives an AI ranking layer something to sit beside and be measured against.

Not always, but AI features need clean, reachable data, stable APIs and a safe way to release and roll back changes. If the platform cannot deploy without risk or its data is spread across inconsistent tables, those problems surface as unreliable AI output. Sometimes a focused cleanup of the data layer and deployment pipeline is enough, and a full rebuild is not required. After its rebuild, this platform has a rebuilt backend and a CI pipeline with automated tests, which are the pieces an AI feature depends on.

Features that hold up are narrow and checkable: match ranking, semantic search, summaries of long message threads, drafting help for users, and moderation of messages. Features that often get promised and quietly dropped are fully autonomous AI mentors and advisors, because the output is hard to verify and the stakes for a student are high. A good rule is to start where a human can review the result before it matters. On a platform built around connecting students with human mentors, as this one is, AI fits best as support for those people, not as a replacement for them.

You need structured profiles, a record of who matched with whom, and some signal of whether a match worked, such as repeat sessions or ratings. Volume matters less than consistency: thousands of well-recorded interactions beat millions of noisy ones. If outcomes are not recorded, the first project is adding that tracking, not training a model. A platform at this one’s scale has enough users for match ranking to be worth testing, and an audit would check whether the history is recorded well enough to use.

AI coding tools save real time on repetitive work: boilerplate, test scaffolding, migrations and reading unfamiliar legacy code. They create rework when used to generate whole features without a clear architecture, because the output looks finished and hides inconsistent patterns that someone has to untangle later. Architecture decisions, security, data migration and code review still need experienced engineers. This rebuild began in 2017, before these tools existed, but the stages that made it work, the audits and the tech strategy, are the ones AI tools cannot replace.

Build cost is a one-time project. Running cost grows with usage: model API calls or GPU hosting, vector storage, monitoring, and the engineering time to evaluate output as models change. A feature that is cheap in a pilot can become a large line item once every user touches it, so usage limits and caching should be designed in from the start. A product with two independent deployments, like this one, would carry those running costs separately for each platform.

Treat AI output like any other part of the product that can regress: define test cases with known good answers, run them on every change, and track quality over time. Add guardrails for what the model may and may not say, and give users a clear way to flag bad results. For anything that affects a student’s decisions, keep a human in the loop. This platform already runs API autotests in its CI pipeline, which is where AI evaluation tests would run as well.