Your Custom Application Is Slow and the Staff Hate Using It

Start by finding out why it is slow and what exactly frustrates people, because the answer decides everything. Most slowness comes from a small number of causes in the database, and most frustration from a small number of screens. Both can often be fixed without a rebuild. A rebuild is the right call only when the application’s foundation, its technology or its database design, cannot support what the business now needs.

Signs this is your problem

• Staff wait for screens to load, many times a day.
• People keep their own spreadsheets to avoid using the system.
• It was fast when it was new and has slowed down as data grew.
• Certain reports are run only at night because they freeze everything.
• New hires take weeks to learn it.
• You hear “I hate this system” more than once a week.

Where slowness usually comes from

• The database has grown. Queries that were instant with a thousand records crawl with a million.
• Missing indexes. The database is searching every row because nobody told it how to look things up quickly.
• Screens that load too much. A page fetches every record when the user needs twenty.
• Reports running against live data. One heavy report slows everyone else down.
• An undersized or badly configured server. The cheapest fix, when it is the cause.
• A design that does not scale. The rarest cause, and the only one that points to a rebuild.

Guessing is expensive. Measuring takes a few days and tells you which of these you have.

Why people hate using it

“Hard to use” nearly always means something specific. Ask the people who use it all day and you will hear things like:

• Too many clicks and screens to do one common task.
• The same information typed in more than once.
• Error messages that do not say what is wrong.
• No way to search for what they need.
• Work lost when the screen times out.
• It does not match how the job is really done any more.

These are design problems, and they are fixable one screen at a time. The screens used most get attention first.

Tune, redesign or rebuild

Tune. Fix the slow queries, add indexes, move reports off the live database. Often the largest improvement for the least money.

Redesign the worst screens. Keep the database and the business logic, and rebuild the handful of screens that cause most of the pain.

Rebuild. When the technology is out of support, the database design is fighting you, or the business has changed too much for the old shape to fit. The old system then becomes the specification for the new one.

We will tell you which of the three we would choose, and why.

How Keene Systems handles it

1. We measure. Which screens and queries are slow, and how slow.
2. We sit with the people who use it. And write down what actually gets in their way.
3. We fix the biggest problems first. Usually a short list that delivers most of the improvement.
4. We give you a plain recommendation on the rest. Tune, redesign or rebuild.

The next step is a short, no-pressure conversation. Book a call with Lance Keene or use the form on this page.