Skip to content
DOiNhub

Finish what someone else started.

Plenty of what we build was started by somebody else. Bringing in a second engineer is a normal thing to do, and the first thing you get back is a straight answer about what you already own.

What usually arrives here.

Four shapes, and all of them are ordinary.

  1. A build that stopped partway

    The first half exists and works. The person who wrote it moved on, and what remains is a repository, some access, and a question about how much of it is worth keeping.

  2. An AI project that demos but does not ship

    It answers well on the three questions it was built against. Production means permissions, cost per run, and being right on the questions nobody rehearsed — which is a different engineering problem to the demo.

  3. Systems that were never introduced

    A CRM, a payment provider, a document store and a planning tool, each doing its job, none of them talking. The work is in the seams and in making the whole thing happen exactly once.

  4. Something running that nobody can change

    It works, it earns, and it has no documentation and one deploy path that only its author understood. Getting it back under control is its own project.

The first week is a read, not a rebuild.

Before anything is quoted, the system gets read. You are told what is there in words you can check against your own repository.

  1. 01

    The code

    What it does, what state it is in, what is genuinely finished versus scaffolded, and which parts a second engineer can safely touch first.

  2. 02

    The data

    The schema, what is actually in it, and whether the shape it has will carry where you are going. Data is the part that is expensive to change late.

  3. 03

    The keys and the permissions

    Which accounts hold what, what is on somebody else's personal login, and exactly what to ask for in a handover. This is usually the part that is missing.

  4. 04

    The path to production

    How it deploys today, what happens when it breaks at 2am, and what has to exist before it can carry real customers.

At the end of it you have a written read of your own system and an order of work, whether or not the build continues here. It is yours either way.

Work that arrived mid-flight.

Three of the systems on the work page were joined after somebody else had started, or built to replace something that had stopped.

An assistant rebuilt around the moment it failed

A media company's cited-answer assistant broke mid-sentence at a conference booth, in front of the room. Everything about how answers are produced was rebuilt around that: generated and checked in full before a word reaches the screen, four models across two vendors standing behind each other. Live since June 2026.

Read how it was built

Four vendor systems that would not cooperate

A wealth advisory firm's intake platform has no webhooks, its CRM rejects updates repeating what it already holds, and its document vault refuses to remove its own admin group. One intake now becomes a fully onboarded client across all four, exactly once.

Read how it was built

A business running on five inboxes

A studio's whole operation lived in WhatsApp threads, an overloaded file share and hand-typed invoices. One application replaced it: one thread per customer whichever channel they write on, a 16-stage pipeline, invoicing and portals on one schema.

Read how it was built

What you hold at the end.

  • The repository, under your account, from the first commit.
  • A written read of the system, in language you can hand to any engineer.
  • Every key and account in your own name, with nothing left on a personal login.
  • A deploy path that someone other than its author can run.

Questions people ask before they send anything.

The previous developer will not hand over access. Can you still help?
Yes. We work from whatever exists: a deployed URL, a database export, screenshots, invoices. The written read then includes exactly what to request in the handover and who to request it from, which is usually enough to unblock it.
What if the honest answer is that it should be rebuilt?
Then that is what you are told, in writing, with what a rebuild involves and what can be carried over from what exists. A restart is a legitimate answer and it is better to hear it in week one than in month three.
Is my code safe with you?
An NDA is signed if you have one. Access is read-only until there is a reason for more, and local copies are removed when the read is done unless the work continues.
How much of the existing work usually survives?
More than people expect. The parts that get replaced are usually the ones handling money, permissions or anything that has to happen exactly once, because those are where a first pass most often takes a shortcut that only shows up under real traffic.
Do you take over projects built with AI coding tools?
Regularly, and it is ordinary work. Generated code tends to be locally reasonable and globally inconsistent, so the read pays particular attention to how the pieces agree with each other rather than to any single file.
What does it cost?
The read comes first and the number comes after it, because a quote against an unread codebase is a guess. How that works is on the pricing page.

Send the repository, a login, or two paragraphs about where it stopped. A senior engineer reads it and replies within four hours, including weekends.

Or write to hello@doinhub.com.