Taking over a software project: the first month

Most guides to taking over a software project are a checklist: access in the first 24 hours, an audit in the first week, a plan by day 30. This note is one takeover instead, read from its git history. In March 2026 a team of four developers, Easinvy's founder among them, took over a live cooking-competition platform. The work was done outside Easinvy, and the platform is not named here. "We" below means that team. The commits cited are the founder's; two of the others merged the pull requests, and the third set up the servers and the QA deploy. Every date, count and line number comes from a commit or a file in the platform's repositories.

What we took over: two codebases from two eras

Two codebases came with the platform, built in very different ways. The first was a backend of Spring Boot and Kotlin services behind a GraphQL federation router, set up for Kubernetes on AWS, over PostgreSQL. Four engineers made its 851 commits between January 2024 and November 2025, and only one of them committed after July 2025. It had a build workflow, a test workflow and 64 test files.

The second was the app's frontend, generated with Lovable, an AI app builder. On the day we imported it, its repository held 781 commits, 777 of them made by Lovable's bot, almost all since January 2026. It was React, Vite and TypeScript, with Capacitor for the mobile app, and it talked to Supabase straight from the browser: 50 of its source files referenced it. It had no test script, no tests and no workflow.

Keep the screens, replace what sits behind them

The new backend came first. Its repository was started on 23 March 2026, and within three days it had sign-in on Express and MongoDB, the APIs behind the ranking and video pages, and user identity, profiles and enrolment.

On 26 March at 14:03 we imported the generated frontend as it stood on 25 March: 251 of its 252 files, 250 of them byte for byte. The next day the frontend was wired to the new backend, and Google sign-in moved out of the browser and onto the server. The backend now signs its own tokens, which brings its own question, covered in How to revoke a JWT. On 30 March Lovable's metadata and favicon were replaced, and another developer merged the first pull request.

Keeping the screens meant the first month went into what sat behind them, not into rebuilding pages that already existed.

The first day: secrets out, the deploy ours

Two files changed on the way in. The generated app's repository had a committed .env holding the Supabase project's id, URL and publishable key. We left it out of the import and did not read its values.

A publishable key is not a leaked password. Supabase's guide to API keys calls it safe to expose in a web page, because it only reaches what Row Level Security allows. Whoever relies on such a key is relying on the database's policies, so those policies are part of what gets taken over.

The second file was a vercel.json, added in the import, so the frontend was set up to deploy from our repository from its first commit.

Move the users, keep their old ids

The users lived in the old PostgreSQL database, and the new backend kept them in MongoDB. From 26 March each user record carried the id it had in the old system, first as legacySource and from 6 April as legacyUserId. The migration script reads a plain-text PostgreSQL dump table by table, and maps every old id to a new one, so profiles, social sign-ins and enrolments that pointed at a user by the old id still find them. Recipes followed on 11 April.

Keeping the old id costs one field. Dropping it turns every later import into a matching problem.

Remove before you add

Two removals came in the first three weeks. On 9 April the integrations module came out, with its controllers, serializers and media models: 1,751 lines, replaced by about 480 lines of direct uploads to S3. On 12 April the live ranking API was switched off "to prevent MongoDB overload", and a static placeholder took its place: 827 lines out.

Switching off the live ranking was a choice of which failure to accept: a ranking page that stopped updating, rather than a database that stopped answering everyone. A feature that can take the database down is the first thing to turn off in a takeover. The same arithmetic runs through MVP development cost, counted in days: what a first version leaves out is cheaper than what it builds.

The old app kept moving

The generated app's repository did not stop when we imported it. Lovable syncs a project with GitHub in both directions, as its GitHub integration describes, and the repository took 414 more commits by 14 May 2026, every one by Lovable's bot: recipe pages, filters, photos for later rounds. Of the 1,124 file versions those commits produced, 4 appear anywhere in our repository's history. From 26 March there were two codebases, and only one of them was ours.

In a takeover, the old repository has to be frozen, archived or formally handed over on the day of the import. Otherwise changes keep landing where the new team is not looking.

The part that takes months

Wiring the frontend to the new backend took a day. Taking the database calls out of it has taken six months and is not finished. The source files that reference Supabase:

The first twelve days removed 21 of them, and the next five months another 16. The generated app's 47-file supabase folder is still in the repository. Each remaining reference is a screen that still reads the old data directly, and it can go only when the new backend serves what that screen needs.

What we still owe it

The old backend had a build workflow, a test workflow and 64 test files. The new code has none of that. The backend has no tests on any branch, and its one workflow, added in September 2026, deploys the QA branch after installing its dependencies and checking each file's syntax, with no tests in between. The frontend's only test file asserts that true is true.

The missing tests are the largest debt in this takeover. A note about it that left them out would be describing a different project.

A checklist from this takeover

Each item is one of the sections above:

1. Start the new backend before the old frontend arrives.
2. Import the screens as they are, and change them later.
3. Leave committed .env files out, and read what each key can reach.
4. Give every migrated record its old id.
5. Switch off any feature that can take the database down.
6. Freeze, archive or hand over the old repository on the day of the import.
7. Count what is left to remove, and keep counting.
8. Write down what is missing, tests first.

Easinvy's project rescue page describes how we take on a project like this one. The counts above were read from the platform's repositories on 10 November 2026.