Finish or restart a stalled software project?

Your team can keep working while you choose. Keep the records people trust, the parts they already use, and the logins the company holds. Then finish the half-built software, restart it, adapt a tool you have, or stop.

You get the work out of one person’s head and off spreadsheets so the team can run it. One person should not have to spend the evening babysitting software. The rest of the team should be able to run the jobs.

We help owners, operations managers, and the teams who do the work. This guide is for blue collar businesses. Byte Bot is based in Clearwater and works with companies across Tampa Bay. The initial fit conversation is free, and you do not need a plan.

A build stalls when the developer leaves, the vendor stops, or only half of it ships. You choose to finish or restart after you see what to keep. Oasis Pavers & Pools faced that choice in St. Petersburg. The office used a partly completed system, and the reports were hard to trust.

What should you keep from half-built software?

Keep the data people trust, the parts they use, and a list of who holds each login.

A stalled software project can still hold what the business needs. Write those things down before anyone quotes a restart. Oasis kept QuickBooks, which it used for invoicing and payments. The office could still check its job records in the old system.

At Oasis, the people who moved each step knew those rules. A lead, a contract, and a payment request were parts of the same job. Different people were responsible for each one. Record those rules, even when no document exists.

Also record who can log in today. Include the code, the server, the database, the domain, and each service the system calls. Prefer a company email and a company card for each account. A password list the company controls is safer than one password on one laptop.

If the developer left, secure the accounts before you look for a new team. Do the same when the vendor stopped work. What to do when your developer is gone lists the accounts to collect first.

A new team can start from the running system, the code, and the people who use it. You can start without the original builder. Oasis’s COO at the time showed us the old system, screen by screen, before the later build.

When is a restart cheaper for a stalled software project?

A restart can cost less when little of the build matches the work and staff already do that work by hand.

Look for these signs before you treat a restart as the cheaper path. Several of them were true in the Oasis office.

Owner Brian Godden said each lead was entered twice, once in a color-coded spreadsheet and once in the system. That let the office compare the two records. He told us, “it’s functional, but it’s not recording that accurately.” Brian’s COO said she compared the system’s quarterly reports with the paper records. She found differences.

Contracts went out through a separate signing tool and were marked signed by hand afterward. Reception checked flood zones on the FEMA website, then rebuilt the same disclaimers in Dropbox for each contract. The screens that existed were not the work the team did all day. When people redo the work by hand every day, the build is not saving anyone time yet, whatever the quote says.

Brian worked with three developers on earlier versions of the office system. He said none of them visited the office. One rewrite was quoted at four weeks and took a year and a half. That rewrite was earlier work, before Byte Bot’s project with Oasis.

Brian’s COO also managed the software work. She said she spent hours each week explaining the business to developers and testing what came back. When a change did not fit, she said the answer was often that it fell outside the scope. A short quote does not show the real cost. These facts are from one project, and they do not show that a restart costs less for every company.

When should you finish the half-built software?

Finish when people already run part of the day on the system, and the missing work is small and named.

Finishing is the better path when these points are true.

In this case, software project recovery means finishing the path the team already uses. You can leave the other work on the tools the team has now. Read the system with the people who use it. Change one small piece at a time. Keep a backup. Open the backup to confirm the records.

Oasis did not match that shorter path. The published account does not describe one small, named gap. Leads, contracts, and the handoff to the next person were still the daily work. Reception assembled documents into a paper folder, the customer signed at the office, and reception scanned the pages. A missed folder put the next step at risk, such as the start of permitting.

The later rebuild kept the office path and removed crew scheduling from the plan. The office began to use the new system on August 10, 2026. The team kept refining the reports after launch, and the case study does not report a return on investment. If your unfinished list is one named report, finish that report.

What does rebuild vs refactor mean?

A refactor keeps the behavior the team uses, and a rebuild replaces the system.

People ask about rebuild vs refactor when a software project stalls. Use the two words this way.

A refactor keeps the work the screen already does. The code gets clearer, so the next change is safer. The team should not have to learn the day again.

A rebuild replaces that system. You move the records and teach the work again. A rebuild can drop a rule that exists only in the old screen. Learn those rules before choosing a rebuild.

Oasis replaced the office system and kept QuickBooks for invoicing and payments. The new system handled leads, contracts, and payment requests. It connected those records to QuickBooks. A refactor keeps the old screens, and Brian could not rely on the reports coming out of those screens. His concern was how each feature fitted the tasks of other people in the office.

An abandoned software project can need either path, depending on what staff still use and what they still redo by hand.

Can you adapt the tools the team already uses?

A tool you already have, or a product you can buy, is often enough for part of the work.

A packaged tool is usually the better choice, unless a real gap sits in a process worth keeping. Try one customer job in the tool. If the tool completes that job, use the tool. Train the team, or change who does the next step. You can leave the half-built software alone.

Keep the tools that already do one job well. Often the cheapest fix is a change in a tool you already pay for. Oasis kept QuickBooks for invoicing and payments, and the new office system connected to it.

You can buy a product, but the search can fail. Brian said he spent at least forty hours evaluating one platform. He found it too complex for the daily work. He later paid a consultant $2,500 to find a product that Oasis could rent each month and leave. She did not find one that fit Oasis’s work.

A previous service for signatures raised its price to about $1,000 a month. Brian did not want to depend on a service that he could not easily leave. The Oasis case study records the search and what the office did next.

When should you not build?

Stop when the team can run the work with the tools it has, or when the half-built plan does not match the jobs.

Sometimes the answer is do not build. That can be the right choice for the business. Stop when a spreadsheet or a packaged tool removes the stall. Stop when a change in who does the next step removes it. Stop when the unfinished list is a wish list and the crew is not blocked today.

Stop when one person is babysitting software that the rest of the team does not need. You can still get hours back each week without a new build. Name the repeated entry, the report someone rebuilds by hand, and the handoff that waits on one person. Fix those in the tools you have when that is enough.

Oasis still needed a system that its current tools did not provide. The paper folder carried the records and the instruction to the next person. The product search did not find a tool that fit the work. Your own first look can still end with do not build.

How can a new team take over the software project?

A new team starts with access to the system and a written record of the daily work.

To take over a software project, collect three things. Collect a copy of the code that the company controls. Collect the logins. Record who holds each one. Then sit with the two or three people who use the system most. Have them show a normal day, including the steps they work around.

Oasis began with two long calls before the build contract, with Brian, his COO, and Thommi from accounts. We recorded how a job moved from the first lead through contracts and payment. You need that record before you choose to finish, restart, or stop.

Ask for a fixed price for that first look. Ask for a list of what you will receive. Ask for a written answer that you can keep and show to another team.

The first conversation with Byte Bot is free, and you do not need a plan. Firm Price is a flat $2,500 paid first step, with a fixed build price within 10 business days that holds for 90 days.

You can do this work without the original developer. You need access to the system and its code. You also need time with the people who use it. If the builder is available, one hour with them helps.