Our work

Real-estate presale app listing collector

Select the regions and property types you need, and the tool scrolls each app list to the end and exports the listings to Excel. It reads the screen structure the app renders instead of capturing images of the screen.

Presale listings across two apps

Before

Staff opened the app and copied each listing by hand

After

Select region or type and run once · results in Excel

Run screen of the delivered automation dashboard. The title reads "자동 제어 대시보드 (v2.1)" (Automation Dashboard v2.1), with the app name blurred. The left sidebar has System Initialize and App Control buttons, and the main area is divided into three steps. Step 1 is system setup, Step 2 sets and opens the target region, with "경기남부" (southern Gyeonggi) selected, and Step 3 scans and collects the list. Below, the "자동 순회 수집" (Auto collection) panel shows 2 collected, a target of 6, and 33% progress in large figures, with the progress bar about one-third full. Beneath it are twelve timestamped log lines, including list scroll, no change detected, 2/6 collected, and coordinate tap.

To protect client information, these screens recreate the same features with mock data.

Client
Real estate presale agency
Industry
Real estate presales
Delivered
2026
Duration
2 weeks
Area
Workflow automation
  • App screen structure parsing
  • Full-list collection
  • Target selection screen
  • Progress display
  • Automated Excel output

Background

Presale information is held inside the apps. Sometimes the same data is not available on the web, and staff have to open the app and scroll through the list, checking each listing.

This project covered two apps. One is organized by region (15 regions) and the other by property type (apartments, officetels, and retail). Their screen layouts are different.

What we found

Staff opened the app, tapped each listing to view its details, and copied the fields they needed by hand.

The list keeps loading as you scroll, and the screen gives no sign of where it ends. Fifteen regions does not mean fifteen passes. It means one pass per listing. The next day, the work starts again from the beginning.

The problem

The problem was handling both apps with a single tool.

Adapting a tool built for one app to fit the other breaks the original. Building two separate tools means every fix has to be made twice.

What we built

  • Reads the screen structure directly — The tool does not capture the screen and recognize text. It reads the structure the app renders to locate each field, so it finds the same place even when fonts or resolution change
  • Select a target and run — Choose from 15 regions in one app or three property types in the other. There is one selection screen, and only the options change by app
  • Collects to the end of the list — The tool scrolls gradually and waits for items that have not loaded yet. A button that is not yet visible is not treated as a failure
  • Progress on screen — The current step and item count are shown. Without visible progress, a long-running job looks the same as a stalled one
  • The same screen as apps are added — Adding an app leaves the existing integration untouched; only the new app’s method is added alongside it. The screen and workflow stay the same for staff

Results

Select a region or property type and run the tool. It collects the full list and saves the results to Excel.

Related work is listed under App crawling.