Case study

The app was finished. Nobody could fix it.

Arise Academy inherited a data collection application from a university project team. When the course ended, so did the support. We took the application over, corrected the defects, and gave the staff back nearly four work weeks a year.

Client: Arise AcademyCustom application takeoverDefects resolved in about a day
150 hrs
of staff time recovered per year, across a ten-month reporting cycle
30 min → 0
per student. Reports are no longer built by hand at all
< 5 min
to produce the monthly report for the entire student group

What they were dealing with

Arise Academy received a data collection application built by a student team at South Dakota State University. It was built as a course project. When the course ended, the team ended with it, and the application arrived too late in the year for staff to pilot it and find the flaws before they needed it.

The defects were not exotic. Codes inside the reporting logic were wrong, so the reports would not run. Once staff started using the tool in earnest, they found more. Every one of them was fixable in an afternoon by someone who could read the code. There was nobody left who could read the code.

So the application sat there, complete and unusable, while staff went back to the manual process it was built to replace. That process took 30 minutes per student, across more than 30 students, every month.

“The SDSU team’s course was complete, and they no longer could or would work on it. They did not get it to us in time to pilot and find the flaws.”
Brooke Maday · Special Education Teacher and Educational Leadership Intern · Arise Academy

What we did

We did not rebuild it. Most of the original work was sound, and the failure was concentrated in a small number of specific defects plus the absence of anyone to correct them. Rebuilding would have cost more, taken longer, and produced the same orphaned tool on a longer timeline.

Instead we read the code, corrected the report logic, worked through the defects staff found in real use, and stayed available for the next one. Each reported issue is confirmed against what the staff actually wanted before the change ships.

Before

  • Reports would not run, because the codes were wrong
  • 30 minutes per student to assemble reports by hand
  • About 15 hours of staff time every month
  • No one available to make a change of any size

After

  • Reports run for the whole student group in under 5 minutes
  • Roughly 150 hours a year returned to staff
  • Reported defects corrected in about a day
  • Changes confirmed with staff before they ship

In their words

“We have found minor flaws, and within a day, Tyler fixes the code. This was the change we needed for data collection, and we are excited to use it this school year.”
Brooke Maday · Special Education Teacher and Educational Leadership Intern · Arise Academy

Why this matters outside a school district

Substitute a job shop and the shape does not change. A co-op student builds a scheduling tool. A retiring planner leaves behind the workbook that sets safety stock. A VAR writes a custom screen during the ERP rollout and moves on. The work is real and the tool is useful, right up until the person leaves and the tool stops changing while the business keeps moving.

We wrote up the full pattern, including what it costs and the four questions to ask about anything you depend on.

White paper

When the Builder Leaves

What happens to the systems your operation runs on after the person who built them is gone.

Request the white paper →

Have a system nobody owns? The diagnostic covers the tools your planning runs on, not just the plan.

Book a Planning Diagnostic →