Founder case study
Alibaba: Define the first transaction before building a marketplace
A sourced Alibaba case study and a practical worksheet for identifying a marketplace's first customer task and transaction barriers.
A marketplace idea can sound compelling while leaving a basic question unanswered: what must happen for the first useful transaction to take place? A long feature list does not answer that question. Alibaba's documented history offers a starting point for examining customer groups, transaction steps and the order in which a business expands.
What the company records establish
Alibaba's official introduction states that the group was established in 1999 by 18 people led by Jack Ma, a former English teacher from Hangzhou. The founders' stated aim was to help small businesses participate more effectively in trade through the internet.
Its 2019 Hong Kong listing document, in the corporate history section on printed page 165, records the 1999 launch of Alibaba.com and the predecessor of 1688.com. The same timeline places Taobao Marketplace in 2003 and Alibaba Cloud in 2009. These are corporate records of distinct services launched over time, rather than evidence that every new marketplace should reproduce the same sequence.
Our analysis: start with a transaction map
The transferable question is narrower than “How do we build the next Alibaba?” Ask which group needs to find which other group, what information each side lacks and what action creates value. A directory, a lead-generation service and a transaction platform can all connect businesses, but they have different responsibilities.
For example, a hypothetical directory of specialist repair providers may only promise to help users identify a suitable provider. If it also promises booking, payment protection and dispute resolution, the operating requirements change substantially. Write down the promise before adding features or describing the service as a full marketplace.
A first-transaction worksheet
Complete this table for one specific use case. Keep facts, assumptions and unresolved questions in separate notes.
| Transaction step | Question to answer | Your evidence or next test |
|---|---|---|
| Find | Who is searching, for what, and when? | [A recent example from the intended audience] |
| Evaluate | What information makes an option comparable? | [Required fields and a real comparison task] |
| Trust | Which claims must be checked before proceeding? | [Verification method and what remains unverified] |
| Contact or commit | What exact action counts as progress? | [A reply, accepted request, booking or other defined event] |
| Complete | Who delivers the promised outcome? | [Clear responsibility and confirmation] |
| Resolve | What happens when the parties disagree? | [An honest description of your actual support scope] |
Choose what to build next
Review the map with people on both sides. A supplier's desire for more inquiries and a buyer's desire for reliable options can point to different priorities. Test the connection between them instead of optimizing one side in isolation.
- Pick a narrow starting group. Define the category and situation tightly enough that you can identify actual participants.
- Document the current process. Ask how the most recent transaction happened, including work done outside your product.
- Locate the blocking uncertainty. Missing information, unavailable supply and lack of trust require different responses.
- Define your responsibility. Do not imply verification, guarantees or protection that the service cannot provide.
- Review completed outcomes. Visits and inquiries matter, but they do not automatically demonstrate that customers reached the promised result.
Limits and sources
This is an editorial framework, not a legal or payment-system specification. Services involving transactions must investigate the obligations relevant to their actual operations. A large company's later product portfolio does not validate a new founder's expansion plan.
Sources: Alibaba's official introduction and its 2019 listing document. We have removed unsupported bankruptcy framing, exam anecdotes and unattributed quotations. The transaction worksheet and analysis are FounderType's own work.