Building a platform before understanding delivery can hide the hardest parts of a service. Thora Vietnam’s proposed pilot approach starts with one useful outcome, some manual coordination, and explicit review. It is a way to learn what should eventually become software, while keeping the initial commitment understandable.
Define one outcome and its boundary
Consider an illustrative request-triage pilot: take a small set of approved sample requests, suggest a category and draft a response for review. The pilot does not send replies or update customer records automatically. The example describes a possible experiment, not a completed Thora Vietnam engagement.
Agree what is included, what is excluded, who reviews the result and when the experiment ends.
Keep the manual work visible
A founder can manually collect inputs, review drafts and prepare the handover while the core hypothesis is uncertain. Explain these steps to the customer. Do not describe a human-operated service as an autonomous system.
Manual work also reveals requirements: which information is missing, where judgment is needed, and which exceptions cannot be handled with a simple rule.
Measure the whole delivery effort
Track the time needed to prepare inputs, check outputs, resolve exceptions and explain results. Comparing only model response time with the old process would miss most of the service. Record failure cases as carefully as successful examples.
Before beginning, agree which observations would justify a second pilot and which would make the offer unattractive. A small qualitative pilot does not establish broad market demand.
Automate a proven repeatable step
After reviewing the pilot, choose a repeatable step with clear inputs and checks. Keep ambiguous decisions with a person until there is a reliable way to evaluate them. This lets Thora Vietnam invest in coding and deployment around observed work rather than a speculative platform roadmap.
Choose the MVP that answers the uncertainty
For Thora Vietnam, the first MVP may be a service delivered partly by hand. A concierge test means the team performs the work manually to learn what a useful result requires. A mock interface can test whether the proposed output is understandable before integration exists. A limited coded path is appropriate when the uncertainty concerns technical execution. Tell participants what is manual and what is automated.
Choose one format because it answers a question, not because a prototype looks more complete. A diagram or demonstration cannot establish that the system will work reliably on unseen real cases.
Agree the pilot boundary and commercial question
Write the input, expected output, excluded cases and reviewer responsibilities before coding. For example, a proposed enquiry assistant could draft a response for approval while leaving sending and customer commitments to a person. This is a design example, not an existing Thora Vietnam customer deployment.
Alongside the workflow test, investigate the offer: would a buyer accept the stated scope, delivery conditions and price? A fixed-scope paid pilot is one possible test to discuss. A free demonstration can establish interest, but it cannot by itself validate willingness to pay. Record discounts, manual effort and any commitments so later pricing decisions have context.
Use a delivery gate before real-world use
A small pilot still needs a responsible operator. Before a participant relies on it, review access, failure handling and how to return to the previous process. Increase exposure only when the customer and operator can explain what has been checked.
- Prepare representative test cases, including missing information and exceptions.
- Separate draft output from actions that send messages or change records.
- Name the reviewer and define when work returns to the manual process.
- Record failures and support time without collecting unnecessary customer data.
- Agree a rollback step, a review date and the limits of the pilot.
Move toward repeatable delivery only after the pilot
If the same workflow helps again, turn repeated setup steps into a checklist: configuration, access checks, test cases, deployment and handover. Reuse code only when its assumptions still fit the next customer. Keep exceptions explicit instead of hiding them behind an apparently standard package.
A future service package should state what it includes, who operates it and how maintenance is handled. Repeated customer use and manageable delivery effort would support that next test. One successful demonstration would not.
Further reading
Background for the method; the Thora Vietnam workflow above is a proposed application.
Paul Graham — Do Things That Don’t Scale
