Modernize the software your business runs on. Nothing your people rely on breaks.
RTP Applied Sciences modernizes the old software a business runs on: the product you built years ago, the system someone built for you, or the platform you just bought. We watch how it is really used before we touch it, so the rules your people and customers depend on survive the rebuild.
Figure 1
Every rule gets a fate.
Thirty-six rules found in an old system, each one sorted on purpose: keep it, change it, or retire it. Three could not be settled from the code alone, so someone who knows the business decides.
- Keep
- 20
- Change
- 8
- Retire
- 5
- Not sure
- 3
An illustration, not client data. A real system has hundreds of rules. The ones nobody sorts are the ones that sink projects.
Every system has three versions.
Only the third one runs your business. A rebuild that copies the first two breaks it.
What the code does.
Years of rules, some on purpose and some by accident. The code cannot tell you which is which.
What its builders meant.
The spec, the manual, and whatever is left in one person’s head. Usually a decade out of date.
What your people actually do.
The spreadsheet beside the app. The step nobody clicks on a Friday. The re-keying a clerk does because the export is wrong. Small fixes, made for good reasons, that nobody wrote down.
Most rebuilds copy the first two versions and delete the third. There are five ways that goes wrong, and we have watched all five. Read the field note.
Who this is for.
Three kinds of company call us. They do not use the same words, so here are theirs.
The old product.
“Every release breaks something.”
A software company whose product was built years ago. Customers still pay for it, the biggest one just asked about the cloud, and the rewrite has been talked about for three years. The last quote came with a number nobody believed.
The system Bob built.
“It works. We just can’t touch it.”
A manufacturer, a distributor, a property company, any business that runs on something a contractor or a long-gone employee built. One person knows how it works, and that person is close to retiring. The insurance renewal just asked what the server runs.
The platform in the data room.
“Diligence flagged it.”
A company owned by investors, with a sale on the calendar. The technology section of the report is red, the board wants to know what happens if the fix goes over, and the sponsor wants one person who can tell them the truth, not a team.
Different words, same fear: something that works today breaks tomorrow, and the person who could fix it is gone.
How it works.
Five steps. The first one is the one nobody else does.
We watch before we touch.
A small recorder runs beside the old system for thirty days and logs which screens get used, which paths people take, and where the errors are. Two days shadowing your people fills in the rest. What comes out is a map of how the system is really used, and it always surprises the owner.
Every rule gets a fate.
Keep it, change it, or retire it. Each rule gets a harm rating: if we get this one wrong, who is hurt, and how fast would we notice. AI does the reading and drafts the ledger. A person decides every fate, two reviewers decide separately, and where they disagree the recording settles it.
We keep what makes it work.
Some of the workarounds are the process. The rebuild absorbs them instead of erasing them.
We change it while it runs.
Old and new side by side, a kill switch on every stage, and stages you can stop after and still be better off. The business never goes dark.
We keep watching after launch.
The recorder stays on, so you see the before and after as a number, not a feeling.
Start with an assessment.
Four to eight weeks, scoped before it starts. You come out knowing what you have, what your options are, and what each one costs, before anyone rebuilds anything.
The map.
Thirty days of how the system is really used, including the workarounds nobody knew about.
The rule ledger.
Every rule we can find: where it lives, why it exists, and its fate, with a harm rating and a confidence mark.
The options, compared.
Replace it in pieces, rebuild it, or run old and new side by side for a while. Each option with its risks and its effect on your people and your customers.
Effort, risk, cost and time.
With every assumption written down, so the next number is one you can believe.
A recommendation, and the order of work.
Our pick, the reasoning behind it, and a staged plan with a stop point after every stage.
If you go ahead: stages with your sign-off at every gate, and no open-ended billing. While the stages run, and after launch if you want, we can stay on part time as your fractional CTO.
Already rebuilt, and nobody here can read the result? Start smaller. A two-week audit puts the recorder on the old system and the new one side by side, lists every rule the rewrite dropped, and ends with one recommendation: keep it, fix it, or start over.
Field notes.
Why modernization goes wrong, from projects we were on.
The Five Failure Modes of Legacy Modernization
A systems-engineering failure, not a software one.
You Don’t Have Netflix’s Problem
Great engineers mitigate risk. They don’t chase it.
Have a system that has outlived its documentation?
That is exactly the conversation we want. Tell us what you are running, who depends on it, and where it hurts.