A Pre-First-Customer Checkup Service for Solo-Built Work Tools

Testing, not screens, is now taking the time

A small service can now repeatedly test whether a solo-built product is ready for a real business to use: permissions, payments, and separation of customer records. Payouts, which operates enterprise payment services, said that after using Replit, the time from an idea to a production deployment fell from months to one to three days.

Formula Bot, built with Bubble, also began as a first product made over a weekend. Bubble says the service grew to one million users, although that is the platform company's own claim. The published figures describe changes in build time rather than total development cost, but reducing work that once took months to days or a weekend materially changes the cost of trying an idea for a small team.

The problem is that a working screen is different from a service that a real business can use with confidence. Records must not mix across customer companies, and employees, administrators, and accounting staff need different levels of access. South Korea's standards for personal-information security measures require access rights to be limited to what is necessary for work and records of granted or changed permissions to be kept for at least three years.

Payments do not end with adding a button. In consumer transactions, buyers must be able to review and correct the product and price before payment. Contract and payment records must each be retained for five years, while consumer complaint and dispute-resolution records must be retained for three years. You also need to test whether payment success, failure, duplicate requests, cancellation, and full or partial refunds change service access in exactly the same way they should.

When a feature sends work documents or customer information to artificial intelligence, it must also explain where the data goes and how long it is retained. The Personal Information Protection Commission (개인정보보호위원회), South Korea's data-protection authority, advises checking whether inputs are used for training, policies for storing and deleting chat records, whether work materials may be entered, and permissions for connections to external services. What has become cheaper is making screens; repeated testing and keeping evidence still take human time.

What to do before accepting the first customer

Assume one person spent a year building a service for a window-installation business with 12 employees. The service combines lead management, on-site estimates, work orders, card payments, and monthly income and expenses. Its maker completed the screens and functions alone with AI-assisted tools.

The business may currently write an address received by phone into an estimate file, repost a confirmed job into a group chat, and enter the payment result again into an accounting file. While moving the same customer name and amount three or four times, an address can be omitted or a worker can see an outdated estimate rather than the latest one. The new service can reduce this movement to a single entry.

But before entering the first business's real records, create two test businesses. After logging in as Business A, changing the number at the end of an address or forwarding a shared link must not open Business B's estimates, attached photos, or customer phone numbers. Repeat the same actions for each role to confirm that the owner, site manager, accounting staff member, and external contractor each see only the screens they need.

Test what happens when an employee leaves or an external contractor's work ends. Immediately after disabling the account, check that already-open screens and downloaded links are also blocked, and retain a record of who granted or revoked access and when. Hiding a menu on screen is not enough: the server must reject a direct address or another person's document number.

Do not test payments with only one successful card transaction. Reproduce, in sequence, a double click on the payment button, a card approval that does not activate the membership entitlement, two arrival notices from the payment company, and cancellation of a monthly subscription. The test passes only when the same money is not charged twice and, after a refund, both access status and the invoice change together.

Draw the route customer information takes on one page. Follow it from user input through the work service, file storage, text-message provider, payment company, AI provider, backup, and deletion, and record what information remains at each point and for how long. Also check whether customer documents are configured not to be used for general AI training, and whether they are transferred abroad or can be viewed by operators abroad.

The work that remains with people is also clear. Setting refund rules, agreeing each employee's work scope, and matching the privacy policy and contract terms to actual operations do not finish automatically. That is why a pre-first-customer checkup service is more realistic when it starts as a package of test accounts, execution steps, result screens, the person responsible for fixes, and retest dates, rather than a product that claims to take over every responsibility.

How overseas services have handled testing

Sweden's Lovable lets individuals and businesses create web-based work tools through natural-language instructions and charges subscriptions and usage fees. It uses Stripe for payments and says it verifies payment flows in a separate test environment before deploying to production.

Stripe said Lovable supports more than 125 local payment methods across more than 150 countries, and that Link, its fast-checkout feature, accounts for 58% of transaction volume. This is an example of Lovable's payment operations, not evidence that every service built with Lovable automatically has safe permission controls and separated customer records.

OpenAI, a United States company that provides conversational AI services to individuals and businesses for a monthly subscription, had an error in March 2023 involving a mechanism for quickly retrieving stored information. The error allowed some users to see other users' chat titles, and OpenAI confirmed that payment-related information may have been exposed for 1.2% of paid subscribers active during a specific nine-hour period.

OpenAI temporarily shut down the service and changed it to conduct additional checks that the user making a request matched the user whose information would be returned. The case shows that separating businesses by an identifier in a database is not enough: user matching must be checked again in temporary stored information and payment screens.

PullString, a United States platform, helped businesses create and deploy voice apps and conversational services. Before its formal launch, it conducted private testing through HackerOne, where external security researchers looked for problems from an attacker's perspective.

HackerOne said it handled 18 reports over four days in the private stage and 223 reports over three days after the public launch. At the time, HackerOne proposed an initial reward budget of US$10,000 to US$20,000 for small companies, or about KRW 14 million to KRW 28 million under the source's conversion assumption. External review did not become nearly free in the way screen-building did; the case also required people and time to quickly fix the issues found.

Four things you could build from this

1. A launch-rehearsal package for field-service businesses

• This service follows estimates, work orders, photo sharing, and payments from start to finish, preserving failed steps and screenshot evidence.
• It is for someone who built a work tool alone for a plumbing, window-installation, or cleaning business with five to 20 employees.
• As screens have become faster to build, testing the real work sequence for each industry has become a new bottleneck.
• The first screen shows an industry selection, user roles, and test steps from a customer inquiry through a refund.

2. A checker for records opening across businesses

• It creates two test businesses and repeatedly changes document numbers, shared links, and file addresses to check whether another business's records can be opened.
• It is for a solo builder who wants to sell the same service to multiple academies, clinics, or construction businesses.
• One person can now make screens for several companies, but separating records by company is easy to miss through one or two visual checks.
• The first screen shows login details for the two test businesses and a list of customer records, estimates, and attachments to inspect.

3. A subscription-payment failure practice space

• It runs payment success, failure, duplicate clicks, automatic renewal, cancellation, and full or partial refunds, then records whether service access changes correctly.
• It is for a maker of appointment-management or membership-management software about to charge its first monthly fee.
• Connecting a payment window has become easier, but exceptions where money and access entitlements diverge still need to be reproduced several times.
• The first screen shows the payment scenario to test, expected result, actual result, and next retest date.

4. A customer-information movement map and reviewer connection

• It maps the route customer information takes through storage, text-message providers, AI providers, and backups, then sends it to a privacy or security reviewer.
• It is for a maker of a small work service that wants to use AI to summarize consultation recordings, contracts, or site photos.
• As external features become faster to add, data routes that even the maker does not know about multiply.
• The first screen uses cards asking about collected information, receiving companies, storage country, retention period, and training use.

What to check in 30 minutes today

Call one person who built a work service alone. Before they load the first customer's data, ask them to show screens or records testing separation of records between businesses, payment failure, and blocked access for departing staff. If they cannot produce evidence for even one of the three within 30 minutes, or must rerun the same test manually, a service that bundles pre-launch checks and evidence may be worth building first.

Why this matters where you are

Check whether a tool built for multiple customer businesses can show evidence that one customer's records cannot open for another. Check whether payment exceptions and offboarding access are tested, rather than only described in the product. Retention rules, payment methods, and applicable privacy requirements will differ by market, but the operational need to test permissions, records, and payment states remains visible in each example.