The person who can finish your application is a developer or team that takes it over. Taking over means they accept full responsibility for what your previous developer left: the code, the servers and accounts it runs on, and the work still to be done.
That is a different job from building a new application.
What does it mean to take over an application?
Taking over means a new developer or team accepts full responsibility for an existing application. That covers the code, the infrastructure (the servers and accounts the application runs on), and the development still to come.
From the day they start, one person or team answers for the whole application. That includes the parts they did not build.
How is taking over different from building a new application?
When you build a new application, you make every decision yourself. When you take one over, you first have to learn the decisions another person made.
When one person builds a new application, every decision is theirs, so the whole application follows how they think. That includes:
- the architecture, which is how the parts are organized
- the naming conventions, which are how things are labeled
- the design patterns, which are standard ways of solving common problems
- the libraries and frameworks, which are ready-made code the application is built on
Some of these are shared across the industry: design patterns, libraries and frameworks. A developer who already knows them can recognize them in your application.
That does not remove all the work. Libraries and frameworks are not always used the way they were meant to be. A developer who knows both can still lose time working around how they were used improperly.
Everything else is unique to the person, team or company that built the application. That includes the architecture, the naming conventions, and how the libraries were used. Someone taking over has to learn all of that first.
They also have to be comfortable working in code that may lack a clear architecture, consistent names or standard design patterns. The code may also use libraries more or less than the work calls for. Working in that kind of code is part of taking over an application.
What is a code review, and why does it come first?
A code review is a careful read of the existing code. It is the first step, because it gives you and the person finishing the work the same picture of what exists.
The report from a review is written so that you can read it without a technical background. It answers these questions:
- What is finished and working?
- What is broken?
- What was planned but never built?
- Can the code be changed safely, or is it fragile?
- What are the realistic options, and what does each one involve?
You do not need to understand every detail. You need to understand what each option means for your money, your time and your risk.
What should you gather this week?
Get control of every account the application depends on, and make a copy of everything. Do this before anyone changes anything.
Make a list and check who holds each item:
- The domain name. This is your web address, such as yourcompany.com. If it lapses, the site can go down.
- Hosting. This is the service where the application runs. Check whose name and whose payment card is on the account.
- The database. This is where your customer and business data is stored.
- The code repository. This is the online folder where the code and the history of every change are kept.
- Outside services. These include payments, email sending and maps.
If your developer is still reachable, you can ask for each transfer in one email, so you have it in writing. If not, most providers have a process for changing the account owner. It usually takes time, so start early.
From now on, you can set up every account in your company's name. Then one person leaving cannot strand the application again.
Should you finish the application or start over?
I can't tell you that without seeing it. The answer depends on what is in the code, and the only way to learn that is to look.
These are the questions that decide it:
- How much of the application already works?
- Can the code be changed without breaking other parts?
- Is the technology the application is built on still supported?
- Is there a record of what the application is supposed to do?
Often the answer is in between. You keep the parts that are sound and rebuild the parts that are not. That is why the review comes first.
What questions can you ask while you interview people?
You can ask each person the same list of questions and compare the answers. You do not need to judge the code yourself.
- Do you have references I can speak to?
- How much will it cost?
- How long will it take?
- Have you worked with the technology my application is built on?
- What do you need from me to get started?
- What will I receive at the end of the code review?
- Will the code and the accounts stay in my company's name?
- Who will do the work, and can I speak to that person?
What will it cost and how long will it take?
I can't give you a number without looking at the application. Cost and time depend on what the review finds.
The main drivers are:
- how closely the frameworks and libraries are used the way they were meant to be used
- how well the code is organized, so a developer can quickly tell which files do what
- how well things are named, so the words you use to talk about your business match the words used in the code
Complexity slows down delivery. Code that is not well organized or named takes longer to understand and change, and that is still true when developers use AI coding assistants (software that helps write code), because they also struggle with code that is hard to follow. This is why craftsmanship matters.
After a review, a range and a plan become possible. Before it, any number is a rough idea.
What is the next step?
If you want a second opinion on what you have, book a free 15-minute call with me. Tell me what the application is meant to do and what state it is in. I will tell you what I can and cannot say without seeing it, and what I would do first.