Shahria EmonTaking over a software project from another developer is usually sold as slow and risky. On Project Nexus, I took over a milestone that had been demoed with 6 of its 12 acceptance criteria. I spent one long day on it, and the client approved the milestone the next day. The system was briefed for 12,000 members and went live with 56,000.
This article is for founders whose project is stuck, whose developer left, or whose last demo did not match what they paid for. It covers what actually went wrong on Nexus, what I did in that one day, what to collect at handover, and how to decide between a takeover and a rebuild.
What does taking over a software project involve?
Taking over a software project means a new developer inherits the existing code, servers and promises, then keeps building without starting over. A good takeover audits what exists against the signed scope, tests the assumptions the architecture depends on, fixes what blocks the current milestone, and only then adds new work. The goal is continuity, not a fresh start.
Most failed takeovers skip the audit and start writing code on the first day. The new developer then builds on top of problems nobody has named yet.
The Nexus takeover: what looked done and what wasn't
Project Nexus is a CRM for a Vantage forex IB network, plus a Telegram bot that checks every channel member against it. The CRM syncs the whole IB network every 20 minutes, and the bot decides who is allowed to stay.
On paper, it looked almost done. The previous developer had built all seven backend checkpoints: config, data model, broker integration, sync, rules engine, Telegram bot and wiring, with unit and integration tests. They had also solved the hardest problem on the project. The broker's partner portal blocks direct requests with Cloudflare and a CAPTCHA, and they got live data out of it by driving a real browser and replaying the portal's own requests. That is strong engineering, and I'll always say so.
Underneath, the milestone was off the rails:
- The status note said 10 of 12 acceptance criteria were done. The demo video showed 6.
- The whole Telegram side was built and demoed on a group. The signed spec said channel.
- The three quality gates between building and demoing (regression, code audit, security audit) had never been run.
The milestone came to me to redo because the demo did not cover what the contract asked for.
Login, member CRM, kicked list, rules enforcement, bot messages, IB network and the partner view.
Walkthrough of the real interface with demo data. 30 seconds, no sound.
The real blocker: one untested assumption
The client caught the first problem before anyone else. She watched the demo and wrote back: "This is a group, ours is a channel. The channel should NOT display who has been accepted or removed."
In a Telegram group, every member sees "X was accepted" and "X was removed". That was exactly what she did not want.
The root cause was one confident, untested belief: that a Telegram bot cannot remove someone from a broadcast channel. Every architecture decision rested on it. So I didn't argue it. I tested it.
I set up a real test channel and made live Bot API calls. The bot received join requests, messaged the person privately, approved and declined requests, and removed and unbanned members. Subscribers saw nothing. Moving to a channel turned out to be a configuration change, not a rebuild.
The second blocker: work that existed but could not be shown
I built a table mapping every acceptance criterion to a demo scene. That table is what exposed "6 of 12".
Six of the criteria were rule behaviours: no trade, low balance warning then removal, balance recovery, leaving the IB, multiple accounts, and the dry run. You cannot show those on camera unless you can put test members into those states and shorten the timers. There was no tooling for that. The code worked. Nobody could prove it worked.
What I did in one day
The git log puts it at roughly 05:30 to 21:40 on 12 July 2026. In order:
- Assessed the real state. Mapped all 12 criteria to scenes and checked each one end to end, instead of trusting that it looked done.
- Built the missing demo tooling. Scene commands that stage test members into each rule's state and run the real rules engine with compressed timers. No faked steps.
- Fixed what rehearsal surfaced. The bot was pre-verifying people on /start, which the spec does not require (I checked the spec before changing it). Removal messages were lost because the queue didn't finish sending before the process exited. An "apply" command silently did nothing. A cleanup step was wiping the removal log the final scene needed.
- Ran the three skipped gates. Regression passed 95 of 95, typecheck was clean, and the code audit caught a client-facing defect in the bot's welcome message straight away. The security audit found no leaked secrets.
- Recorded the full demo covering all 12 criteria.
- Wrote an evidence-backed review of the first attempt, commit by commit.
- Ran the live channel test against the real Telegram API, and recorded a short follow-up on a real channel: a bystander subscriber sees nothing while members are admitted and removed, and removals happen on the engine's own schedule, not by a manual kick.
The client approved Milestone 1 the next day, 13 July: "It's approved and closed out to please proceed with M2."
How long does a software project takeover take?
Getting one stuck milestone approved can take a single focused day, as it did on Nexus. A full takeover takes longer, because the hidden gaps only show up when you audit the whole contract, not just the current milestone. Budget a few days to a few weeks before new work ships at full speed.
On Nexus, the hidden gaps were real. Before starting Milestone 2, I ran a traceability audit of all 52 signed requirements against the acceptance criteria. 14 were covered by nothing. Eight of those were real, unplanned work that nobody had known about, including Owner versus Support permissions, Telegram membership tracking, pagination, and an audit log model that nothing ever wrote to.
That is the part of a takeover founders rarely hear about. The milestone in front of you is the visible problem. The requirements nobody mapped are the expensive one.
What to hand over when you switch developers
If you are switching developers mid-project, collect these before the old developer is fully gone:
- Repository access with full history. Not a zip file. The commits show what was tried and abandoned.
- Server, hosting and domain logins, including the email account they are registered to.
- Every API key and third-party account. Payment gateways, broker portals, bot tokens, cloud storage.
- The database, or at least a recent backup.
- The signed scope, even if it lives in a chat thread.
- Proof the quality gates ran. Test results, audit reports. On Nexus there were none, and that was the first warning sign.
- A known bugs list. Ask the old developer directly. Most will tell you.
Red flags when hiring someone to take over
- "We need to rebuild everything" before they have read the code. On Nexus, rebuilding would have thrown away the best work on the project.
- No questions about your signed scope. If they don't ask what was promised, they can't tell you what is missing.
- A fixed quote before an audit. A fixed price on unknown code is a guess.
- Vague blame on the previous developer. Good engineers name the actual problem and give credit where it is due.
Take over or rebuild?
My rule: rebuild when the engineering is wrong, take over when the process is wrong. If the core architecture can carry what the product needs, keep the code and fix how it is built and verified. If the core itself is the limit, rebuild it, starting with the hardest module.
On Nexus, the code was good and the hardest problem was already solved. What had failed was verification: gates skipped, a load-bearing assumption never tested, and "coded" confused with "demonstrable". So I kept the code and redid the process. One real API call settled in under an hour what a rewrite would have taken weeks to work around.
Scrumo, our project management app, was the opposite case. Its core could not handle deep nesting and live rollups, so I rebuilt the core from an empty repo in seven days. Load time dropped from 20 to 40 seconds to under one second. Same question, different answer, because there the architecture itself was the limit.
How it ended
Milestone 2 grew from 10 acceptance criteria to 17, on a dashboard that did not exist yet, two days before the demo date. We shipped all 17 on time without weakening a single quality gate. The client closed the contract with a 5-star review, and Nexus now handles 56,000 members, 4.7 times the original brief, at about 1.8 ms per account check.
The biggest cost of a bad milestone is not the rework day. It is trust. A client who has already caught a demo that doesn't match reality gives you less room next time. That is why every removal in the follow-up video had to happen on the engine's own schedule.
If your project is stuck right now
Get the repository, the logins and the signed scope into your own hands today, even before you pick a new developer.
If you want a second opinion on whether your project needs a takeover or a rebuild, message me on WhatsApp. I'll read the code and tell you honestly which one it is. The full Project Nexus case study covers the technical side of the build.