A Separate Service Can Handle the Launch Operations for Apps Built in Text

The people making apps and the people operating them are beginning to split apart

Book information affiliated with the Korea Publication Industry Promotion Agency, a public body for Korea’s publishing industry, introduces the case of Kim Jae-seong. In his 60s, when he was not yet comfortable typing, he studied generative AI, built a website and mobile app, and released the app in an app store. This account is based on the author’s own introduction; the app’s name, user count, and revenue have not been disclosed.

The Korea Information Society Development Institute found that people in their 60s who use generative AI have a relatively higher share of use for conversation. Across all generative AI users, 13.5% had experience paying for it. That suggests people in their 60s can access a workflow of giving instructions in writing and receiving responses. It does not mean they are necessarily building apps themselves.

In real-world cases abroad, people without development experience are describing the screens and behaviors they want in writing and producing working apps. There are overseas cases of apps being built through natural-language implementation instructions.

But Apple reviews every submitted app and update. A privacy policy must explain what information is collected, why it is collected, and when it is deleted, and must be linked both in the app store and inside the app. If user information is sent to an external AI service, the app must disclose what is sent and why, and obtain permission.

Google Play also requires a privacy policy and a Data safety form, including for apps that collect no information. In Korea, the Personal Information Protection Act requires operators to set a purpose for collection and a retention period. Under the Framework Act on the Development of Artificial Intelligence and the Establishment of a Foundation for Trust (인공지능 발전과 신뢰 기반 조성 등에 관한 기본법), which took effect on January 22, 2026, services using generative AI must also disclose that fact in advance.

What a person who knows jazz needs is not a development team

Imagine a retired music teacher, age 67, who selects jazz performance videos, adds listening notes, and sends them to a club. Today, he sends video links in a messenger app, writes down song titles and performers in notes, and copies the same information again into notices for the next meeting.

He does not want to build a huge video service. A small app where members can open recommended videos, leave listening notes, and check the date of the next meeting would be enough. The problem is not the screens. It is not knowing how to handle video rights, member information, record deletion, and password-reset inquiries.

This hypothetical case assumes that app creation and operations are handled together.

Tools for building apps through written prompts change this bundle of work. The retired teacher can describe a first screen with “today’s video,” “one-line listening note,” and “next meeting,” then immediately see a working draft. He can also change text size and button names as if continuing a conversation.

A first version becomes simpler if it leaves out sign-up and video uploads. It can show only public video links and commentary written by the operator, while storing personal listening notes only on the user’s device. This greatly reduces the personal information the operator holds.

Human judgment still remains. An operator who knows jazz needs to check whether a video can be introduced, correct errors in AI-generated song descriptions, and respond to complaints. For sensitive topics such as health or sobriety, it also cannot be handed over automatically to distinguish situations that need to prevent harmful advice and direct people to specialist organizations.

The piece that can be separated here is “launch operations preparation.” Instead of rebuilding the app, this work completes the list of collected information, the privacy policy, app-store submission fields, test accounts, paths for deleting accounts and records, and support-response wording. The work can be considered complete when all six match the actual app and work as intended.

The boundary shown by earlier services

Luca Capone of Italy first used development tools at age 49. He had worked in security and had no previous development career. Using an AI creation tool, he built PairHabit, an app for couples to track habits together, and wrote that App Store review was especially difficult.

PairHabit launched as an iPhone app in June 2026. Up to three habits are free, while the paid version costs about KRW 6,700 a month or about KRW 53,600 a year. It does not yet have enough public user reviews or disclosed revenue. It is a case where one person reached a designed, paid release, while market validation remained a separate question.

Carrie and Andrew in the United States started Everything Spiritual from their combined 12 years of sobriety. They moved meditation, emotional-support materials, and meetings into an app so that people who found it difficult to visit could also use them, using Passion.io, a tool for building apps without coding.

They said they considered existing options with operating costs of about KRW 1.06 million per month or custom-development costs of about KRW 79.63 million. But they already had more than one million social media followers, so this cannot be read as a case where users gathered simply because an app was made. Specific app revenue has not been disclosed.

Adam Frater, a fitness instructor in the United States, rebuilt Calxthenics on Passion.io after struggling with changes and operations for a custom-built app. He bundled exercise sequences, repetition counts, nutrition materials, and progress records into a one-time fitness course.

Passion.io’s own case study states that the app had more than 10,000 users, monthly revenue above about KRW 66.4 million, and creation-tool costs of about KRW 390,000 per month. These figures have not been independently verified. Still, the case shows an app being used to turn existing materials into a course with sequence and records, rather than to create new exercise videos.

Four services that can be separated out here

1. A first-app launch companion service

• What it does: Takes a completed app and finishes Apple and Google submission fields, the privacy policy, test accounts, and deletion functions with the operator.
• Who uses it: Instructors in their 60s or community organizers who built a hobby app through written prompts but stopped at the app-store registration screen.
• Why now: More people can make screens themselves, but creation tools do not take responsibility for review and privacy.
• First screen: After entering an app name, the user sees the preparation status of four areas: “review information, privacy, deletion, and support.”

2. A review tool that reduces the personal information an app collects

• What it does: When the operator describes app functions, it shows what information goes where and identifies parts where sign-up or data storage can be removed.
• Who uses it: An instructor at a local cultural center building their first app for reservation lists or club records.
• Why now: AI creation tools can easily add login and data-storage functions, while operators may not understand the result.
• First screen: It asks, “What do users enter in this app?” and presents choices including name, photo, location, and health records.

3. A usability testing group for users in their 60s

• What it does: Real users aged 60 and over try signing up, making a first record, deleting it, and sending an inquiry. The service returns the points where they got stuck through audio and screen recordings.
• Who uses it: A solo operator who made a fitness, medication, or local-information app for their parents’ generation.
• Why now: App drafts can be made quickly, but a creator working alone may struggle to spot small text and unfamiliar error messages.
• First screen: It asks for the app address to test and tasks such as “sign up,” “leave a record,” and “delete a record.”

4. An operations inbox that gathers post-launch inquiries

• What it does: Collects app-store reviews, email inquiries, bug reports, and deletion requests in one place, then organizes only the order in which they need answers.
• Who uses it: A coach running a fitness course or sobriety-tracking service alone and finding it difficult to open several management screens every day.
• Why now: The time needed to make an app has fallen, but user support and data-deletion work still remain human work after launch.
• First screen: It shows “inquiries to answer today, deletion requests, bugs, and app-store reviews” in order of urgency.

Why this matters where you are

Tools may make it easier for more people to create app screens, while review, privacy disclosure, deletion, and user support still remain operational work. Check which of these responsibilities apply in your own app stores and market. If you build or support small apps, map every piece of user information to where it is stored and how it can be deleted before adding more features.

What to check in 30 minutes today

Look at the app you want to make from its first screen to its last and write down every piece of information a user enters. If there is even one item for which you cannot immediately write the storage location and deletion method beside it, you need a launch-operations review service. If the core function still works without collecting personal information, that scope is worth trying as a first version.