Rescuing a Stalled EdTech Platform: How We Shipped What 70 Engineers Couldn't

Client Overview

MTS is an education company building a multi-sided platform for students, teachers, and administrators. Their product spans a mobile experience for students, a web portal for teachers, and an admin/back-office system — all of which need to stay in sync to run real classroom workflows.

Business Challenge

MTS had been working with a vendor of roughly 70 engineers who could not deliver a working product. The codebase was fragile, the client was unhappy, and the project was effectively dead — at risk of being scrapped entirely after significant investment.

Goals

Make the platform usable end-to-end so it could actually be put in front of students and teachers
Restore client confidence after a failed engagement
Move from firefighting to predictable feature delivery
Get the product into production with real users

Solution

Instead of a rewrite, we ran this as a structured rescue. We audited all three codebases, isolated the single biggest blocker keeping the app from being usable, fixed it, and then moved into a steady cadence of feature work — culminating in a live production launch.

System Architecture

Three coordinated surfaces talking to one source of truth: a React Native student mobile app and an Angular teacher portal both consuming a Laravel REST API, with the Laravel admin panel acting as the back-office for content, users, and operational data. All three surfaces shared the same domain model so a change in the back-office reflected consistently across student and teacher experiences.

Student Mobile App

React Native

Teacher Portal

Angular

Admin Panel & Backend

Laravel

Integrations

Authentication for students, teachers, and admins
Push / in-app notifications for student mobile app
Media and content delivery for learning materials
Email transactional flows for account and operational events

Security Considerations

Role-based access control across student, teacher, and admin surfaces
Server-side authorization on all sensitive endpoints (not just UI gating)
Tightened API contracts to prevent over-fetching of student data
Production deployment hardened before go-live

Delivery Timeline

Phase 1 — Audit & Triage
Initial weeks
End-to-end review of all three codebases, dependency check, and a prioritized list of what was actually blocking launch versus what just looked bad.
Phase 2 — Stabilize the core
Following sprints
Fixed the single biggest blocker and the surrounding flows so the app became demoable and usable in real conditions.
Phase 3 — Feature delivery
Ongoing
Moved into a predictable feature delivery cadence across mobile, teacher portal, and admin panel.
Phase 4 — Production launch
Final phase
Hardening, deployment, and taking the platform live for students, teachers, and administrators.

Key Challenges

Three codebases, no clear ownership

React Native, Angular, and Laravel had been touched by many hands with no consistent conventions. We mapped the real state of each before changing anything so we'd stop introducing new regressions.

Broken trust with the client

After a vendor of 70 engineers failed to deliver, the client expected more excuses. We rebuilt trust by shipping a usable build fast, then sticking to a predictable cadence rather than promising big rewrites.

Fragile core flow blocking launch

A single core flow was unreliable enough that the whole product looked broken. We prioritized that one flow above everything else so the app could be demoed and tested with real users.

Mobile / web / backend drift

API contracts didn't match what the React Native and Angular apps actually consumed. We aligned the contracts on the Laravel side so both clients could rely on consistent shapes.

Business Outcomes

Dead → Live

Project rescued and shipped to production

A project the previous vendor couldn't release went live and started serving real users.

3

Platforms stabilized

Student mobile app, teacher portal, and admin/backend — all aligned around one source of truth.

70+

Engineers replaced by a small senior team

A lean senior team delivered what a much larger team could not, by ruthless prioritization.

Background

MTS came to us with a project that was, for all practical purposes, dead. A previous vendor with around 70 engineers had been working on it for an extended period without producing a release the client could ship or even reliably demo. Trust between the client and the previous team had completely broken down.

The Challenge

The product spanned three codebases that all had to work together: a student-facing mobile app in React Native, a teacher portal in Angular, and an admin panel plus backend in Laravel. Any one of those is enough to stall a team — together, with no clear ownership and a tangled history, the system had ground to a halt.

Our Approach

Instead of trying to rewrite everything, we treated this as a rescue mission. The first job was to make the app actually work — not perfect, just usable — so the client could finally see real value moving.

Deep audit of all three codebases to map the real (not assumed) state of the system
Triaged the issues and zeroed in on the one core blocker keeping the app from being usable
Fixed that blocker first, so the platform could be put in front of actual users
Switched into proper feature development with predictable releases
Hardened, deployed, and took the product live

The Result

What a 70-engineer team could not deliver, a small senior team at GreeLogix shipped. The app went from a stuck, unreleasable project to a live product serving students, teachers, and administrators across three coordinated platforms.

Why this case still matters

This was one of GreeLogix's earliest engagements and set the template for how we still work today: senior engineers, brutal prioritization, and a bias toward shipping over rewriting.

Tech Stack

React NativeAngularLaravelPHPMySQLREST APIsNode tooling

Lessons Learned

On rescue projects, ship a usable build before doing anything else — trust is rebuilt by releases, not roadmaps.
A small senior team almost always beats a large one with no clear ownership.
Pick the one blocker that's making the whole product look broken, and kill it first.
Align API contracts at the backend rather than patching each client — drift compounds fast.
Resist the urge to rewrite. Stabilize, then evolve.

Related Services

Services proven on this engagement — explore how we deliver them for other clients.

Industry

EdTech Software Development

Frequently Asked Questions

Why didn't you rewrite the platform from scratch?

A rewrite would have extended the failure pattern that already burned the client. We chose to stabilize the existing React Native, Angular, and Laravel codebases first so MTS could get back to a usable, demoable product fast — then evolve it from there.

How can a small senior team outperform 70 engineers?

Large teams without clear ownership generate coordination overhead and conflicting decisions. A small senior team can hold the whole system in its head, ruthlessly prioritize, and ship the one fix that unblocks everything else.

Can GreeLogix rescue a stalled or failing project like this?

Yes. We routinely audit and rescue stalled software projects across mobile, web, and backend stacks. We start with a paid technical audit, agree on the single biggest blocker, and ship a usable build before scoping anything bigger.

What tech stack was involved in the MTS rescue?

React Native for the student mobile app, Angular for the teacher portal, and Laravel (PHP + MySQL) for the admin panel and backend, all communicating over REST APIs.