What 35 Years of Delphi Development Didn't Teach Me About Pricing

In 1991, I released a DOS program called Zilch, written in Turbo Pascal and priced at $29.95.

Thirty-five years later, that product has evolved into Debt Blaster, a Windows application built with Delphi FMX. Along the way, the tools changed, the platforms changed, the way software is distributed changed, and the market changed.

One thing apparently did not.

I can still get the price wrong.

Original DOS version of Zilch Standard

Blunder #1: I Priced the Software From My Side of the Desk

When I released the Delphi FMX version of Zilch Standard, it was not a minor upgrade.

I moved from a proprietary file system to a SQLite database. I went from a hard-coded 640x480 screen to a resizable, fluid layout. I moved from Windows-only VCL to cross-platform FMX, with Windows first and macOS distribution planned. I added light and dark themes.

Going from VCL to FMX was a major investment in time.

At the same time, the things I used to build and sell software were getting more expensive. Delphi cost more. FastReport cost more. FastSpring cost more.

So I raised the price of Zilch Standard to $69.95.

From my side of the equation, the decision made sense. I had invested a lot more into the product, the product was substantially better, and my costs had gone up.

That was the problem.

I was looking almost entirely at my side of the equation.

Sales still came in at $69.95, and for a while that seemed to support the decision. What I did not catch was who was making those purchases.

They were existing customers.

People who already knew ZilchWorks, already knew the software, and already understood what they were getting were willing to pay $69.95 for the new version.

What I was not seeing were new customers buying the software at that price.

I missed that distinction because sales were not zero. I saw purchases and treated them as evidence that the price worked.

Then came the Microsoft Store.

I was already at $69.95, so I arbitrarily added another ten dollars and submitted Debt Blaster at $79.99.

There was no competitive study behind that extra ten dollars. Microsoft was going to take a commission. Delphi cost more. FastSpring cost more. Groceries cost more. Haircuts cost more. Magazines cost more. Everything around me seemed to cost more.

And I believed I had built a life-changing tool.

So I figured it was worth $79.99.

Once again, I was doing the calculation from my side of the desk.

Microsoft disagreed.

They rejected the price, and I complained - loudly and publicly - on Reddit and in Delphi user groups. After all these years as an independent developer, I did not particularly enjoy someone else telling me what I could charge for software I had created.

Eventually, I lowered the price to $69.99 and resubmitted it. Microsoft accepted it, and after the disappointment of the $79.99 rejection, that approval felt like a victory.

Debt Blaster went live in the Microsoft Store at $69.99, and I was thrilled. I celebrated.

I thought I had won.

I hadn't.

This was the email I received. I had to log in to actually see the "Price Rejected" message.

Blunder #2: I Confused Price Approval With Price Validation

Microsoft accepting $69.99 didn't mean the market accepted $69.99. I had already made the mistake of treating purchases by existing customers as evidence that the price worked. Now I was in danger of treating Microsoft's approval the same way.

Neither one answered the question that mattered: would a new customer, comparing Debt Blaster with everything else available, choose to pay $69.99?

Not:

What do I think Debt Blaster is worth?

But:

What will customers reasonably pay when they compare it to everything else available?

My development costs mattered to me, but they didn't matter to the customer. The market doesn't know what Delphi costs, what FastReport costs, or how many hours I spent writing, testing, debugging, and refining the software. Nor should it.

Customers have debt, they want a plan, and they compare the available solutions to decide whether mine is worth the price I'm asking. That led me to an important distinction:

My costs determine whether I have a viable business. They do not determine market value.

Once I accepted that, I had another problem: if $69.99 wasn't right, what was?

$59.99? $49.99? $39.99?

I could have picked another number and tried again, but by then I had already done enough guessing.

So I Stopped Guessing

Because this is 2026, I had something available to me that I certainly didn't have in 1991: ChatGPT.

What started as a few questions about competing debt payoff products quickly turned into a structured research project. With ChatGPT helping me organize the research methodology and write the SQL, I built a SQL Server database called:

DebtBlasterMarketIntel

Instead of relying on a few Google searches or competitors I happened to know about, I began collecting normalized competitive data.

I tracked things such as:

• Competitors
• Individual price observations
• Features
• Permanent free offerings
• Paid offerings
• Trials
• Account requirements
• Advertising
• Platform availability
• Which features were free
• Which features required payment

I researched 15 competing products and compared them with Debt Blaster, including Debt Free, Debt Payoff Planner, Undebt.it, Undebt.it+, Vertex42, YNAB, and others.

Image of an early DebtBlasterMarketIntel competitor pricing result set. Debt Blaster was still priced at $69.99 when this research began.

I wasn't trying to build the world's greatest database of debt payoff software. I was trying to answer one practical question:

What price makes Debt Blaster look like the right amount of software for the job?

That question changed everything.

What the Data Told Me

Debt payoff math is heavily commoditized. Snowball calculations, avalanche calculations, payoff forecasts, spreadsheets, free calculators, inexpensive apps, and subscription products are all easy to find.

Debt Blaster still has differentiators that I believe matter: Dial-A-Date, one-off payment modeling, month-by-month planning, privacy, offline operation, local data, no account requirement, and a one-time purchase instead of another subscription.

But those advantages didn't erase the competitive reality.

$69.99 was too high.

Not because Debt Blaster was bad software, because 35 years of development history had no value, or because Microsoft had rejected $79.99.

It was too high because, in the actual competitive market, that price made it harder for customers to say yes. The evidence kept pointing toward a different number.

$39.99

Vertex42 had a $39.95 one-time Pro Commercial Use price, while several subscription competitors reached roughly $50 after a few years of use. Other products cost substantially more over time, but they often gave customers a much lower initial entry point.

Against that landscape, $39.99 felt like a much more natural fit for Debt Blaster:

• One payment
• No subscription
• Local data
• Offline operation
• No Debt Blaster account required
• Deeper planning workflow

At that price, Debt Blaster looked like a reasonable amount of money for the job it performs, so $39.99 became the regular price.

Blunder #3: I Should Have Done the Research First

I built the product, tested it, prepared the Microsoft Store listing, created the screenshots and marketing pages, and got the software into customers' hands. I also decided what I thought it should cost.

Only after all of that did I seriously research the competitive market and ask what comparable products were charging.

That was backward.

The market research should have helped shape the pricing decision before I ever submitted $79.99 to Microsoft, not after $69.99 failed to perform the way I expected.

That sequence was backward.

The competitive analysis shouldn't have been something I did only after $69.99 underperformed. It should have been part of the pricing decision before I ever submitted $79.99 to Microsoft.

I had spent plenty of time thinking about the product itself: what it could do, how it should work, how it should look, and how to get it into the hands of customers. I knew how to write the code, test it, package it, build the website, create the store listing, and ship the finished product.

What I hadn't done with the same discipline was study the market before deciding what to charge.

I had treated pricing almost as the last step: build the software, decide what it feels like it's worth, put a price on it, and see what happens. The competitive research taught me that pricing deserved the same kind of deliberate work I would put into designing a feature or debugging a difficult piece of code.

After 35 years, I knew a lot about building and shipping software.

I was still learning how to price it.

Then I Looked Back at 1991

Once I settled on $39.99, I thought the pricing project was finished. Then the 35th anniversary came into view, and I started thinking about how to mark it in a way that actually meant something.

That took me back to the original Zilch release in 1991 and its price: $29.95.

Thirty-five years later, after all the debate over $79.99, $69.99, and finally $39.99, the answer to the anniversary promotion was sitting right in front of me.

1991: $29.95
2026: $29.99

Four cents apart and thirty-five years apart.

That became the promotion. Not a random discount, but a price with a reason behind it and a direct connection to where the product began.

Back to Where It All Began

The regular price of Debt Blaster is $39.99. And for the rest of 2026, the 35th Anniversary Special is: $29.99. 

The original Zilch sold for $29.95 in 1991. Thirty-five years later, Debt Blaster is $29.99 for the anniversary. In between, Turbo Pascal became Delphi, DOS became Windows, Zilch became Zilch Standard, and Zilch Standard became Debt Blaster. Thirty-five years of development separate the original Zilch from today's Debt Blaster, but the anniversary price is almost exactly the same.

The Part Where I Admit Microsoft May Have Done Me a Favor

There is some irony in all of this. Microsoft rejecting $79.99 didn't tell me what the correct price was, and Microsoft accepting $69.99 didn't validate that price either. Even the disappointing sales at $69.99 only told me that something wasn't working - not what the answer should be.

They were signals. The research gave those signals context.

When Microsoft rejected $79.99, I complained. When Microsoft accepted $69.99, I celebrated and, at the time, genuinely thought I had won.

Looking back, Microsoft hadn't validated $69.99 any more than it had proven $79.99 was wrong. The rejection simply forced me to reconsider my position. Then the market forced me to reconsider it again.

Finally, the competitive research made me stop defending what I thought the software should be worth and start looking at the evidence of what the market would actually support.

The Software Can Be Right While the Price Is Wrong

That may be the biggest lesson I took from this. When something you've built doesn't sell the way you expected, it's easy to assume the product itself must be the problem. Sometimes it is, but sometimes the product is fine and something else is getting in the way.

The message can be wrong. The audience can be wrong. The distribution can be wrong.

The price can be wrong.

In my case, it was. Changing the price didn't diminish the value of the work or somehow make Debt Blaster less capable. It simply clarified where the product fit in the market and made the offer easier for customers to understand and accept.

Your Cost Is Not Your Value

Delphi still costs me what Delphi costs me. FastReport still costs what FastReport costs. The tools and services I depend on are still more expensive than they used to be.

None of that changed when I lowered the price of Debt Blaster.

What changed was my understanding of what those costs meant. They are part of running my business, but they are not the customer's pricing formula.

The customer decides whether the value they receive is worth the amount I'm asking them to pay.

That's a different calculation from what it costs me to build the software, and it took me a while to separate the two.

I Was Also Mixing B2B and B2C Thinking

There was another distinction I had missed.

Delphi, FastReport, FastSpring, and the other tools and services around my business live in a business-to-business world. A professional developer or company can look at the price of a tool and ask whether it saves time, supports revenue, improves productivity, or makes the business more capable.

Debt Blaster is a consumer product. The person trying to get out of debt is not evaluating my development platform or calculating my return on investment. They are spending their own money and comparing Debt Blaster with the other ways they can solve the same problem.

I had allowed the pricing behavior of the B2B software world I buy from to influence how I thought about the B2C software I sell.

Those are different markets with different buying decisions.

The price of my business tools helps determine whether I can afford to keep building software. It still does not determine what a consumer product is worth in the market.

Thirty-Five Years Later, I'm Still Learning How to Ship Software

In 1991, I was trying to write useful software and convince someone to pay $29.95 for it. Thirty-five years later, I'm still trying to write useful software and figure out what someone will pay for it.

A lot happened in between. Turbo Pascal became Delphi, DOS became Windows, software distribution moved to the Internet and app stores, and now I'm using ChatGPT to conduct competitive research and storing the results in SQL Server.

The technology changed dramatically. Apparently the learning part didn't.

I got the price wrong. I complained when Microsoft rejected $79.99, celebrated when it accepted $69.99, and then had to accept that the market was giving me a different answer. Instead of guessing again, I did the research and changed my mind.

The regular price of Debt Blaster is now $39.99.

And through the end of 2026, the 35th Anniversary Special is:

$29.99

And somehow, after all that time, I ended up four cents away from where I started.

Sometimes you have to travel a long way to find your way back.

Enjoy!
Semper Fi
Gunny Mike
https://zilchworks.com
https://debtblaster.com

Delphi Tip of the Day: Use Beyond Compare Lite Before Accepting AI Code Changes

ChatGPT can be a huge time saver when working with Delphi code.

But that does not mean you should blindly paste AI-generated code into your project and hope for the best.

Here is a simple habit that helps: compare the before and after files first.

Delphi includes a copy of Beyond Compare Lite, and it is easy to overlook. On my machine it is located here:

C:\Program Files (x86)\Embarcadero\Studio\XX.X\bin\

Replace XX.X with your installed RAD Studio version folder.

Recently, I asked ChatGPT for a complete drop-in replacement for a Delphi form that contained a TStringGrid. The goal was simple:

Save and load the grid column widths from the existing config.ini file when the form loads and closes.

ChatGPT gave me the full updated unit. Before replacing my working source file, I opened the original file and the new file in Beyond Compare Lite.

Beyond Compare Lite showing the original Delphi source file on the left and the ChatGPT-modified version on the right.

That made the review much easier.

Instead of hunting through the entire unit by hand, Beyond Compare Lite showed me exactly what changed. In this case, I could quickly see the new private fields, the new load/save methods, and the places where the form startup and shutdown logic had been modified.

That matters.

AI-generated code can be useful, but you still need to own the change. A file comparison tool helps you answer the important questions:

What did it add?
What did it remove?
What did it touch?
Did it change anything I did not ask for?
Does the change make sense before I compile it?

Beyond Compare Lite does a fantastic job of making those differences visible.

It is one of those tools that ships with Delphi but can be easy to forget about. If you are using ChatGPT, Copilot, or any other AI coding assistant, this little utility becomes even more valuable.

My rule of thumb is simple:

Never accept a full-file AI replacement without comparing it first.

Compare it. Review it. Then compile and test it.

AI can help write the code.

Beyond Compare Lite helps you keep your hands on the steering wheel.

Enjoy!
Semper Fi
Gunny Mike
https://zilchworks.com
https://debtblaster.com

Delphi Tip of the Day: Folding Code

 Every once in a while, I run into one of those small Delphi features that makes me wonder, “Why haven't I been using this more?”

Code folding is one of those features.

I was reminded of this during
a recent ChatGPT coding session

It does not make your code run faster. It does not fix bad logic. It does not magically turn a messy unit into clean architecture. But it does make the Delphi editor easier to work in, and when you spend a lot of time moving around in the source code, that matters.

I was reminded of this during a recent ChatGPT coding session while working in Delphi 13.1.

We were not doing anything glamorous. We were not building some grand framework or rewriting the whole application. We were doing the kind of careful work real programmers do all the time: find this section of code, replace it with that section of code, compile, test, and move on to the next small change.

In other words, it was surgical coding.

ChatGPT would tell me something like, “Find this method,” or “Replace this block,” or “Add this procedure right below that one.” That works fine when the unit is small. But once the source file starts growing, finding the right place in the code can turn into a scroll hunt. You move up, move down, pass the section you were looking for, scroll back, and hope you do not paste the new code in the wrong place.

That is when folding code started looking a lot less like an editor gimmick and a lot more like a practical navigation tool.

I created a simple test form with one button so I could slow down and look at how Delphi handles folded regions and folded methods. Nothing fancy. Just a small, controlled example where I could see what happens when the editor shows the code as an outline instead of one long strip of source code.

The lesson was simple: when you are making careful, targeted edits, folded code helps you find the right operating table before you pick up the scalpel.

unit Unit1;

interface

{$REGION 'Interface Comments'}
// ============================================================================
// Interface comments go here
// ============================================================================
//
//
// ============================================================================
{$ENDREGION}

uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs,
  FMX.Controls.Presentation, FMX.StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$REGION 'Implementation Comments'}
// ============================================================================
// Implementation comments go here
// ============================================================================
//
//
// ============================================================================
{$ENDREGION}

{$R *.fmx}

procedure TForm1.Button1Click(Sender: TObject);
begin
  //
  // Button1 Click Code Goes Here
  //
end;


end.

What Is a Delphi Region?

A Delphi region starts with {$REGION ...} and ends with {$ENDREGION}.

For example:

{$REGION 'Interface Comments'}

// code or comments go here

{$ENDREGION}

The text inside the quotes becomes the folded label in the editor. In this example, Delphi shows the folded section as Interface Comments.

That may not seem like much in a small unit, but once a source file grows, these regions can act like road signs. Instead of scrolling through everything line by line, you can collapse the sections you do not need and keep the overall structure visible.

The Before Picture

Nothing Folded

This first screenshot shows the unit with nothing folded.

In a tiny example like this, it is not a big deal. Everything fits on the screen, and there is not much to hunt for. But that is not how real Delphi projects usually stay. A form starts simple, then a few more event handlers get added. Then a few helper methods show up. Then some temporary test code appears. Before long, you are scrolling through the file trying to find the one method you need.

That is where folding starts to earn its keep.

Folding the Regions

Regions Folded

In the second screenshot, the two comment regions are folded.

The code is still there. Nothing has been removed. Delphi simply collapses those sections so they take up less room in the editor.

This is one of the things I like about folding code. It lets me get things out of the way without deleting anything. Sometimes I want those big comment blocks. Sometimes they are helpful. But when I am working on a method, I do not always need to see them.

Folding lets me say, “Not now. Stay there, but get out of my way.”

That is useful.

Folding Regions and Methods

Regions & Methods Folded

The third screenshot shows both the regions and the method body folded.

At this point, the source file starts to look more like an outline. You can see the major parts of the unit without seeing every line inside each part.

That is probably my favorite use of folding. It helps me move around in the source file without getting pulled into the details too soon. When everything is expanded, every line competes for attention. When sections are folded, I can scan the shape of the unit first, then open only the part I need.

For someone like me, that matters. I do not “picture” the code in my mind. I work better when the structure is visible on the screen. Folding code gives me a simple way to make the editor show the structure instead of forcing me to mentally hold it all together.

Customizing the Folded Code Color

Delphi also lets you customize the way folded code looks in the editor.

You can find this under:

Tools > Options > Editor > Color

Then scroll down to the Folded code element.

Delphi 13.1 Editor Color settings

I usually work in the Light theme, so I changed my folded code colors to something I could spot quickly without making the editor look like a warning sign.

My settings are:

Foreground color: Palevioletred
Background color: Mistyrose

That is just my personal preference. You may like something different. The important thing is that folded code should be easy to recognize. I want it to stand out, but I do not want it shouting at me all day.

Palevioletred on Mistyrose works for me. It is visible, but not obnoxious.

At least in my humble opinion.

Why This Helps

The real benefit of folding code is navigation.

When I am working in a source file, I do not always need to see everything. Sometimes I only need the interface section. Sometimes I only need the implementation section. Sometimes I want to hide temporary test methods so I can focus on the production code. Sometimes I want to collapse a group of helper methods because they are not the thing I am working on right now.

That is where regions can be helpful.

For example, you might use:

{$REGION 'Helper Methods'}

or

{$REGION 'Temporary Sample/Test Methods'}

or

{$REGION 'Initialization Code'}

The region names become little signposts inside the editor. When they are folded, they help you move around the unit faster.

Used carefully, code folding reduces visual clutter. Used carelessly, it can become clutter of its own. I would not wrap every tiny thing in a region just because Delphi lets me do it. But for logical sections of code, longer comment blocks, temporary test code, or helper methods, regions can make a unit easier to live in.

Final Thought

Code folding is a small feature, but it solves a real problem.

It helps you move around inside your code without scrolling through every line. It lets you collapse the parts you do not need right now. It turns a long source file into something closer to an outline.

And when you can see the outline, it is easier to find your way.

Sometimes the best productivity improvement is not a new tool. Sometimes it is just making the tool you already use a little easier to work with.

Share Your Colors With a Comment

Please share the foreground and background colors you are using for your Folded Code in the comments.

Enjoy!
Semper Fi
Gunny Mike
https://zilchworks.com
https://debtblaster.com

GOTCHAS!

As pointed out by SilverWarrior in the comments. Code errors lead to unfolded code from the error point on. There are two very quick ways to re-fold all the methods instead of toggling the ( - ) or ( + ) in the left margin.

Method Folding quick Steps

Mouse:         Right Click > Fold > Methods
Keyboard:    [ Ctrl ] + [ Shift ] (keep held down) press K then press M

Concrete by Day, Nero by Night: A Practical Light/Dark Style Pair for Delphi FMX

 One of the nice things about Delphi FMX is that you can change the look of an application without rewriting the application.

That sounds simple.

In practice, finding two styles that work well together can take some trial and error.

For Debt Blaster, I wanted a clean light theme and a clean dark theme. I did not want the application to feel like two completely different programs depending on the selected theme. I wanted the light and dark versions to feel related.

That is where the Concrete and Nero FMX styles came in.

The GetIt Package Manager

Both styles are available through the Delphi GetIt Package Manager.

In GetIt, I installed:

FMX Style - Concrete 1.0
FMX Style - Nero 1.0

The style files I am using are:

Concrete_Win.style
Concrete_macOS.style
Nero_Win.style
Nero_macOS.style

That gives me a light and dark style for both Windows and macOS.

Concrete and Nero styles installed from Delphi's GetIt Package Manager

Concrete for the Light Theme

The Concrete style gives the application a clean light appearance without making it look too flat or unfinished.

It works well for traditional business software because the controls are easy to read, the grid lines are clear, and the interface still feels like a desktop application.

For Debt Blaster, that matters.

This is not a game. It is not a flashy demo. It is software people use to enter real debt information, compare payoff plans, and make decisions.

The user interface needs to stay out of the way.

Concrete does a good job of that.

Debt Blaster using the Concrete FMX style on Windows.

Nero for the Dark Theme

The Nero style is a strong companion to Concrete.

It gives the application a dark theme without changing the basic structure of the screen. The same grids, menus, fields, buttons, and panels are still there. They just shift into a darker working environment.

That is what I like about this pairing.

Concrete and Nero feel like they belong to the same family.

One works well when I want a light application. The other works well when I want a dark application.

Debt Blaster using the Nero FMX style on Windows

Why I Like This Pair

The big win is consistency.

When I switch between Concrete and Nero, the application does not feel redesigned. It feels restyled.

That distinction matters.

A good style should support the application. It should not make the user stop and think, "What happened to the program?"

Concrete and Nero give me:

Light theme: Concrete
Dark theme:  Nero
Windows:     platform-specific style files
macOS:       platform-specific style files

That gives me a clean path for supporting both Windows and macOS without pretending one style file should handle every platform perfectly.

One Practical Lesson

FMX is cross-platform, but that does not mean every visual decision automatically behaves the same way on every platform.

For this reason, I prefer using the platform-specific style files:

Concrete_Win.style
Concrete_macOS.style
Nero_Win.style
Nero_macOS.style

That keeps the intent clear.

Windows gets the Windows style file.

macOS gets the macOS style file.

That is easier to understand, easier to debug, and easier to explain six months from now when I come back to the code and wonder what I was thinking.

Final Thought

If you are building a Delphi FMX application and want a clean light/dark style combination, Concrete and Nero are worth a look.

They are easy to install from GetIt, they work nicely together, and they give an FMX desktop application a more finished appearance with very little effort.

For me, Concrete and Nero are not just two random styles.

They are a practical pair:

Concrete by day.
Nero by night.

And for Debt Blaster, that pairing fits very nicely.

Enjoy
Semper Fi
Gunny Mike
https://zilchworks.com
https://debtblaster.com

Delphi 13.1 Install: The Android JDK Checkbox Trap

Android was selected, but the installer did not automatically select the required JDK and Android SDK/NDK options. This led to the Java JDK error later in the install.

I had recently posted to the FB Delphi Developer group that Delphi 13.0 IDE insight was not working. (See post here)

Marco Cantu responded and mentioned that it was working in his Delphi 13.1. So I decided to go and upgrade my version of Delphi to 13.1. 

I overlooked a small little detail that sent me down "install hell". I chose the Android platform but forgot to check off  Eclipse JDK and Android SDK.

Critical Technologies I failed to check off

The installer ran and gagged on the JDK missing. It gave me two error messages. One telling me the JDK was missing and s second one with a nice "Retry" button. 

So I installed the JDK and clicked Retry. And Delphi eventually installed successfully. This got me thinking. Why didn't this installer warn me that those unchecked boxes might cause an error during installation? I can't answer that.

The other annoying thing is the installer seems to "hang" when it's performing the "Installing" task. Not all the time but most of the time. I made me feel like the computer froze.

So I loaded the Getit Install Log into TextPad. One of the nice features of TextPad is it does not cause a sharing violation when a file is being actively written to. Ig gives you a nice message that says "The file has been updated. Would you like to reload the file?" This was my cheap way of watching what was happening and being comforted that the install was not hung.

ChatGPT Dashboard using the Getit Installation Log

Then I decided to have a little fun. I gave the Getit Installation Log and asked ChatGPT to turn it into a stand-alone HTML dashboard showing me what happened. It came out pretty cool. I asked ChatGPT to give me a blogger-friendly version of HTML I could past in. Below is my Delphi 13.1 installation dashboard.

Oh I almost forgot. After installing 13.1 the IDE Insight is working again. 

I went back and checked when the IDE Insight was working:

• Delphi 13.1 - Working
• Delphi  13.0 - Not Working
• Delphi 12 - Not Working
• Delphi 11.3 - Not Working
• Delphi  10.3 - Not Working
• Delphi 10.2.3 - Working

I guess we'll never know what happened between Delphi 10.2.3 and Delphi 13.1 that IDE Insight to not work. 

RAD Studio 13.1 GetIt Install Dashboard

A Blogger-friendly summary generated from the GetIt install log. This version is scoped to this post and uses inline styling so it should not disturb the Blogger theme.

Total elapsed

58m 54s

2:45:21 PM to 3:44:15 PM

Active installer time

41m 5s

Across 4 install attempts

Final successful run

26m 29s

After the JDK retry

Platforms selected

5

Android, iOS, macOS, Windows on Arm, Windows

Packages installed

27

Unique successful packages

Install story

The log shows 4 install attempts on 2026-04-25: 3 failed Android SDK/JDK attempts, followed by 1 successful run. This version includes macOS/OSX work done before the retry, so it does not disappear from the timeline.

Platforms selected

●Android

▯iOS

⌘macOS

ARMWindows on Arm

▦Windows

Process time - full current install sequence

Moving folders25m 22s

61.7% of measured time

Downloading7m 45s

18.9% of measured time

Extracting5m 39s

13.8% of measured time

Commands1m 40s

4.1% of measured time

Other / setup27s

1.1% of measured time

Completion markers7s

0.3% of measured time

Registry / environment5s

0.2% of measured time

Process time - final successful retry only

Moving folders18m 3s

68.2% of measured time

Downloading5m 45s

21.7% of measured time

Commands1m 40s

6.3% of measured time

Extracting45s

2.8% of measured time

Other / setup7s

0.4% of measured time

Registry / environment5s

0.3% of measured time

Completion markers4s

0.3% of measured time

Install attempts

Session	Start	End	Duration	Status	Selected platforms	Root error
4	2:45:21 PM	2:50:27 PM	5m 6s	Failed	Android, iOS, macOS, Windows on Arm, Windows	Error when executing an action of "AndroidSDK" catalog. The action is "CheckJavaInstalled" (ID 22).
5	2:50:36 PM	2:53:06 PM	2m 30s	Failed	Android, iOS, macOS, Windows on Arm, Windows	Error when executing an action of "AndroidSDK" catalog. The action is "CheckJavaInstalled" (ID 22).
6	3:03:47 PM	3:10:47 PM	7m 0s	Failed	Android, iOS, macOS, Windows on Arm, Windows	Error when executing an action of "AndroidSDK" catalog. The action is "CheckJavaInstalled" (ID 22).
7	3:17:46 PM	3:44:15 PM	26m 29s	Successful	Android, iOS, macOS, Windows on Arm, Windows	None

macOS / OSX package detail

These packages were installed before the final JDK retry, which is why they can be missed if you only look at the final successful retry.

Package	Observed time	First seen	Last seen	Successes	Measured phase time
OSX and iOS Common Files Professional	7s	2:45:35 PM	3:04:08 PM	2	Downloading: 6s Moving folders: 1s
PAServer for OSX	10s	2:45:39 PM	3:04:14 PM	2	Extracting: 8s Downloading: 2s
OSX and Linux Common Files	2s	2:45:44 PM	3:04:15 PM	2	Extracting: 2s
OSX64 Common Files Professional	8m 56s	2:45:45 PM	3:09:05 PM	2	Moving folders: 7m 18s Downloading: 1m 38s
OSX Common Files Professional	13s	3:33:06 PM	3:33:19 PM	1	Downloading: 12s Installing: 1s
PAServer for Win64	17s	3:33:19 PM	3:33:36 PM	1	Extracting: 13s Downloading: 4s
Delphi macOS Professional	10s	3:40:15 PM	3:40:25 PM	1	Moving folders: 6s Downloading: 4s

Slowest package spans - full current install sequence

The horizontal position shows where the work happened within the overall timeline. Gaps may include error screens, retry time, user intervention, setup checks, and log entries that were not assigned to a named package.

PAServer for OSX5s

Session 4 • 2:45:39 PM to 2:45:44 PM

OSX64 Common Files Professional4m 6s

Session 4 • 2:45:45 PM to 2:49:51 PM

OSX64 Common Files Professional4m 50s

Session 6 • 3:04:15 PM to 3:09:05 PM

AndroidSDK1m 24s

Session 7 • 3:17:53 PM to 3:19:17 PM

Android Common Files Professional5m 9s

Session 7 • 3:19:17 PM to 3:24:26 PM

Core Common Files Professional4m 19s

Session 7 • 3:24:26 PM to 3:28:45 PM

Delphi Common Files Professional17s

Session 7 • 3:28:46 PM to 3:29:03 PM

IOS Common Files Professional4m 2s

Session 7 • 3:29:03 PM to 3:33:05 PM

OSX Common Files Professional13s

Session 7 • 3:33:06 PM to 3:33:19 PM

PAServer for Win6417s

Session 7 • 3:33:19 PM to 3:33:36 PM

Win64 Common Files Professional2m 51s

Session 7 • 3:33:36 PM to 3:36:27 PM

AdoptOpenJDK16s

Session 7 • 3:36:27 PM to 3:36:43 PM

Help Files Professional19s

Session 7 • 3:36:51 PM to 3:37:10 PM

Sample Applications17s

Session 7 • 3:37:10 PM to 3:37:27 PM

TeeChart Standard Professional24s

Session 7 • 3:37:28 PM to 3:37:52 PM

Delphi iOS Professional2m 18s

Session 7 • 3:37:57 PM to 3:40:15 PM

Delphi macOS Professional10s

Session 7 • 3:40:15 PM to 3:40:25 PM

Delphi WinArm Professional3m 48s

Session 7 • 3:40:25 PM to 3:44:13 PM

Errors and recovery

The repeated failure was the Android SDK action CheckJavaInstalled. After the JDK was installed, the retry completed successfully.

Error message	Count	Sessions
Error when executing an action of "AndroidSDK" catalog. The action is "CheckJavaInstalled" (ID 22).	6	4, 5, 6
A problem occurred during the process.	3	4, 5, 6

What was installed

Successful packages across the current install attempts.

Package	Successes	Failed/incomplete	Observed time	First seen	Last seen	Measured phase time
InterBase Redist	2	2	4s	2:45:26 PM	3:04:02 PM	Extracting: 6s Downloading: 4s
Windows and Android Common Files	2	0	0s	2:45:26 PM	3:03:56 PM	n/a
LivePreview	2	0	2s	2:45:33 PM	3:04:04 PM	Extracting: 2s
Roboto Fonts	2	0	2s	2:45:34 PM	3:04:05 PM	Downloading: 2s
OSX and iOS Common Files Professional	2	0	7s	2:45:35 PM	3:04:08 PM	Downloading: 6s Moving folders: 1s
PAServer for OSX	2	0	10s	2:45:39 PM	3:04:14 PM	Extracting: 8s Downloading: 2s
OSX and Linux Common Files	2	0	2s	2:45:44 PM	3:04:15 PM	Extracting: 2s
OSX64 Common Files Professional	2	0	8m 56s	2:45:45 PM	3:09:05 PM	Moving folders: 7m 18s Downloading: 1m 38s
AndroidSDK	1	3	1m 32s	2:49:51 PM	3:19:17 PM	Extracting: 4m 42s Installing: 1m 14s Downloading: 10s
Android Common Files Professional	1	0	5m 9s	3:19:17 PM	3:24:26 PM	Moving folders: 4m 23s Downloading: 46s
Core Common Files Professional	1	0	4m 19s	3:24:26 PM	3:28:45 PM	Moving folders: 3m 12s Downloading: 1m 3s Installing: 4s
Delphi Common Files Professional	1	0	17s	3:28:46 PM	3:29:03 PM	Downloading: 13s Moving folders: 3s Installing: 1s
IOS Common Files Professional	1	0	4m 2s	3:29:03 PM	3:33:05 PM	Moving folders: 3m 18s Downloading: 43s Extracting: 1s
OSX Common Files Professional	1	0	13s	3:33:06 PM	3:33:19 PM	Downloading: 12s Installing: 1s
PAServer for Win64	1	0	17s	3:33:19 PM	3:33:36 PM	Extracting: 13s Downloading: 4s
Win64 Common Files Professional	1	0	2m 51s	3:33:36 PM	3:36:27 PM	Moving folders: 2m 15s Downloading: 36s
AdoptOpenJDK	1	0	16s	3:36:27 PM	3:36:43 PM	Extracting: 10s Downloading: 4s Installing: 2s
AndroidSDK-NDK	1	0	4s	3:36:43 PM	3:36:47 PM	Installing: 2s Downloading: 1s Extracting: 1s
Fonts	1	0	4s	3:36:47 PM	3:36:51 PM	Installing: 3s Extracting: 1s
Help Files Professional	1	0	19s	3:36:51 PM	3:37:10 PM	Downloading: 17s Moving folders: 1s Installing: 1s
Sample Applications	1	0	17s	3:37:10 PM	3:37:27 PM	Extracting: 13s Downloading: 3s Installing: 1s
TeeChart Standard Professional	1	0	24s	3:37:28 PM	3:37:52 PM	Moving folders: 17s Downloading: 6s Installing: 1s
Delphi Android Professional	1	0	4s	3:37:53 PM	3:37:57 PM	Downloading: 2s Moving folders: 1s Installing: 1s
Delphi iOS Professional	1	0	2m 18s	3:37:57 PM	3:40:15 PM	Moving folders: 1m 46s Downloading: 31s Installing: 1s
Delphi macOS Professional	1	0	10s	3:40:15 PM	3:40:25 PM	Moving folders: 6s Downloading: 4s
Delphi WinArm Professional	1	0	3m 48s	3:40:25 PM	3:44:13 PM	Moving folders: 2m 49s Downloading: 58s Installing: 1s
Delphi Windows Professional	1	0	2s	3:44:13 PM	3:44:15 PM	Extracting: 1s Installing: 1s

How the timing was calculated

Durations are estimates inferred from timestamp gaps between log entries. A package duration runs from the first logged action for that package through its success marker. Installer housekeeping, retry gaps, error screens, registry updates, file copies, and command execution can create visible gaps in the timeline.

Enjoy
Semper Fi
Gunny Mike
https://zilchworks.com
https://debtblaster.com