When is it Time to Rebuild Your App?

Subscribe to Our Blog

The reincarnation decision

Whether it’s from age, functionality or neglect, all software eventually reaches its end of life. When we approach custom software with a client, we normally will evaluate several factors before deciding whether our engagement will be simple support, light rebuild or even a complete ground up reincarnation. Here are some of the factors we consider:


Cost is the factor that clients are interested in hearing our thoughts on; But it’s also one of the most difficult things to estimate. We’re firm believers in continuous improvement, but in order to get to a minimum viable product to be able to improve on, sometimes it will cost more to fix an existing app versus starting again from scratch. Our considerations on cost then steer towards:

  • Is it going to cost more in the long run to get
    to where we want to be if we must tread through an existing legacy application
  • Knowing what we know now about the necessary
    functionality, how difficult would it be to start over?
  • Is there an opportunity to improve the quality
    of all features and the database contents through a ground-up rebuild?


Age is the next factor we look at. This can lead to numerous issues in custom software, as the older an app gets, the higher likelihood that it has somehow been fragmented in some way from the original design and vision.

  • When was the app first developed? Who developed
  • Has it been converted from very early versions
    of platform software, like FileMaker version 7 or older?
  • When was the last time the app received minor and
    major updates? Who developed those changes? How were those updates requested
    and documented?
  • Has the software been updated by many developers
    over time, or just one?


Functionality assessment is an important part of the decision as well. If there are many functions of the software that are not working properly, then it may be an easy choice to start fresh and develop new functions that work. Unused functions can clutter the app and also become dangerous dependencies during future changes.

  • Do users frequently complain that functions
    don’t work properly?
  • Do users complain that performance is slow?
  • Does analysis
    show a lot of items in the UI and schema that are broken?
  • Is there a lot of functionality that sits there
    being unused?


Data is one of the last things we consider, but also the most important. After all, most of the apps we develop have a pretty major database component underlying the interface.

  • What are the current backup and record archiving
  • Are there orphaned records in sub tables where
    parent records were deleted?
  • Does the data schema represent performance
    minded design (reducing index, calculation and summary fields)?
  • Are there tables that are not in use (zero
  • Are there fields that are duplicated, redundant,
    poorly named?
  • When was the last time the app was compacted?

After considering factors like these, it’s time to make the
choice! Sometimes it’s ok to choose to just provide basic support to keep
things up and running. Other times it makes sense to approach a new project.
It’s an exciting prospect that can also make many people nervous. Documenting
and researching a system to make an informed decision on how to proceed is a
great first step.