Money X  ‣  Blog provides knowledge to help you build healthy habits for your business

Multi-sided markets are not difficult because they involve many users. They are difficult because each side has different incentives, risks, and units of value. For SmartKid a project helping children build skills, discipline, and goal - oriented thinking, this is a practical lesson as the team moves into MVP delivery.

This article shares practical insights from mentoring SmartKid at FPT University, one of the projects I had the opportunity to work with during Summer 2026. You can explore more at the Money X Projects section. The goal is not to diagnose an idea on paper, but to help the team identify the right assumptions to test, build a sufficiently small MVP, and generate real data for decisions in the next phase. These principles also apply to other EdTech projects, parent-child platforms, education marketplaces, and multi-sided business models.

• What is a multi-sided market?
• SmartKid: a project with multiple “customers”
• The core tension: children use it, parents pay
• Which side should you validate first?
• A six-week MVP plan for SmartKid
• Metrics to track: do not just count downloads
• Validating pricing and the revenue model
• Common anti-patterns
• Implementation-phase checklist

A multi-sided model creates value for two or more groups of participants, but does not necessarily charge every group. Facebook is a familiar example: users create attention and behavioral data, while advertisers pay to access that attention. The value created by users and sold to another side is often called a derivative asset.

The key point is that users are not always the paying customers. In a multi-sided model, users may “pay” through time, participation, content, data, learning outcomes, or their ability to connect with others. Commercial customers pay to access or benefit from that value. That is why the value users bring to Facebook’s business model still appears in the Revenue Streams box above.

Startup teams therefore cannot answer “Who is our customer?” with one broad statement. They need to define every side clearly: who uses the product daily, who makes the decision, who pays, who recommends it, who may become a distribution channel, and who benefits from the outcome.

1. What value does each side receive? Do not describe features; describe the outcome they want to achieve.
2. What must each side give up? Money, time, setup effort, trust, or a change in behavior.
3. Which side’s value is converted into revenue from which other side? This exchange rate needs early validation.

SmartKid aims to help children develop habits, self-management skills, and goal-oriented thinking every day. In the initial concept, parents pay for and help set up the system; children interact regularly with tasks, rewards, progress, and gamified experiences. The project also considers schools or education providers as potential future distribution channels or customers.

SmartKid should therefore not be viewed simply as “an app for children.” It is at least a three-sided model:

Projects like SmartKid must address a fundamental risk: parents and children are different segments with different definitions of success. Parents want measurable progress; children return because the experience is engaging, they feel autonomous, the rewards matter, or there is a social element.

This is a common situation in children’s EdTech: daily users do not hold the wallet, while the people holding the wallet do not directly use the product. If the team optimizes only for children, SmartKid may become an enjoyable game that parents do not see as valuable enough to pay for. If it optimizes only for parents, the product may feel like a task board that children quickly abandon.

For example, a streak can encourage a child to open the app every day, but it does not automatically prove that the child is learning a skill or building a habit. Similar to a Duolingo routine triggered by daily reminders, users may complete tasks merely to preserve a streak, while the actual learning outcome remains limited.

• For children: small tasks, immediate feedback, a sense of ownership, clear rewards, and visible progress.
• For parents: less nagging, visibility into what their child has done, recognizable progress, and a simple family ritual they can sustain.
• Shared value: a positive behavior that takes place in real life, not only through taps on a screen.

The MVP design principle for SmartKid should be: one action by a child must create useful evidence for a parent; one response by a parent must improve the child’s experience. If those two loops do not connect, the product will solve only half the problem.

We recommend that multi-sided models clearly separate the user side and the customer side on the BMC or Lean Canvas, then identify the riskier side to validate first. In many models, the user side is riskier because users create the valuable asset that customers may later be willing to pay to access.

For SmartKid at the MVP stage, the practical interpretation is: do not begin by building a fully developed ecosystem for schools, experts, and parents. Start with the smallest behavior loop between children and parents, then prove that this loop can persist over time.

1. Do parents experience enough pain to act? The question is not “Do they agree that life skills matter?” but “Have they tried to teach this before, where did they fail, and do they want to change their approach?”
2. Do children come back? Measure behavior on day 8 and day 30 instead of relying on positive first-day reactions.
3. Are parents willing to maintain their part of the process? For example, approving tasks, confirming rewards, or checking a weekly report.
4. Will parents pay or place a deposit? A financial commitment, even a small one, is far more valuable than “I would use it if the app existed.”
5. Are schools truly a distribution channel? Validate this only after receiving sufficiently strong signals from pilot families.

For this project, the most dangerous assumption is not “Is the app useful?” It is whether parents see the problem as urgent enough to change behavior. This must be answered through interviews about past behavior, not surveys about future intentions.

An MVP is not a miniature version of the final product. It is the fastest way to test the riskiest assumption through real behavior. For SmartKid, the team does not need to build an AI-enabled app, a complex achievement system, a children’s social network, or a school dashboard immediately.

Find at least five parents who have tried to teach their children about money, habits, chores, saving, or self-management but encountered difficulties. Prioritize evidence of past behavior: what they did, how long it took, what caused them to stop, and what alternatives they have paid for. Do not pitch the idea during interviews, because the goal is to understand the real story and pain.

Questions should focus on the most recent time the problem occurred, what parents tried, what happened afterward, what disappointed them most, and how they define success. Do not ask, “Would you use an app like this?” That question produces compliments, not evidence.

Do not broadly choose “parents with children aged 6–14.” Select a group with a specific context and trigger event, such as parents of children aged 7–10 who must remind their children to do chores every day and have tried reward charts or allowances but could not sustain them for more than two weeks.

A narrow segment helps the team understand one problem more deeply, communicate a clearer message, and reduce the cost of finding initial users. Marketplaces and multi-sided models often need to begin with a sufficiently focused niche to create liquidity or a successful experience before expanding.

Instead of developing the full app, run a “human-supported MVP” with 10 families. The team can use Google Forms, Zalo, Notion, Canva, or a simple landing page to create a seven-day challenge and track results.

• Each child receives one or two small tasks daily, such as preparing school items, recording an expense, or completing a household chore.
• Parents confirm completion through one simple action or a short message.
• The team sends daily or weekly feedback and progress updates.
• At the end of the week, parents receive a short report: what was completed, which days were missed, and suggestions for the following week.

A Concierge MVP allows the team to see which parts genuinely need automation. A sound rule is: build with code only after an action has repeated often enough and the team understands why users need it. The “manual first, automate later” approach is also commonly used to solve the launch problem in multi-sided models.

Do not only ask, “Did your child like it?” Measure:

• How many children complete at least three tasks in the first week?
• How many children return on day 8 without a personal reminder from the team?
• How many parents still confirm tasks or view reports after two weeks?
• What are the specific reasons families stop participating?

A child enjoying the product on first use is a positive signal, but it is not yet evidence of product-market fit. SmartKid needs to prove a sustainable behavior loop in which children participate and parents continue to see their effort as worthwhile.

Instead of presenting “Freemium + Subscription” as a broad concept, create a specific offer. For example: “A 30-day program to build children’s self-management habits, with daily tasks and weekly reports for parents: VND 79,000 per month,” or an annual plan with a discount.

The price is not intended to maximize revenue at the beginning. It helps the team learn whether the proposed value is strong enough. SmartKid has been advised to define specific pricing early, rather than leaving the revenue model as “freemium + subscription.”

After six weeks, the team should meet based on evidence rather than intuition. If parents do not participate consistently, reduce the work required from parents before adding features for children. If children leave after the first week, revisit the tasks, rewards, and age fit before spending money on advertising.

Downloads, likes, or people saying “That is a great idea” do not answer whether SmartKid can become a sustainable product. In a multi-sided model, the team needs a metric set for each side and one metric that captures the connection between them.

A suitable North Star metric for the MVP could be: the number of families completing at least three parent-confirmed behaviors each week. This metric forces the team to care about both sides: children must act, and parents must confirm.

In a multi-sided model, the “exchange rate” between value created and revenue must be clarified early. When value created by one group of users becomes revenue from another customer group, the startup needs to validate that exchange rate rather than treat it as a given.

For SmartKid’s B2C model, parents are both decision-makers and payers. This makes the model simpler than advertising or a marketplace, but three different questions still need validation:

1. Willingness to pay: Will parents pay after experiencing the value?
2. Retention: Will they continue paying after the first month?
3. Unit economics: Is the cost of acquiring a new family lower than the profit value that family generates?

• Offer a real paid plan, not only a pricing survey.
• Invite 10 pilot families to join at an early-adopter price in exchange for in-depth feedback and early access.
• State clearly what they receive: program, duration, reports, support level, and cancellation policy.
• Do not treat “free forever” as a success signal; free measures curiosity, not commercial value.
• Record reasons for declining payment: no visible results yet, price too high, lack of trust, the child does not enjoy it, or parents lack time.

If parents say the product is useful after the pilot but do not want to pay, that is not failure. It is data that helps the team identify the gap between “useful” and “worth paying for.”

Teams can easily become absorbed in building a polished app, AI features, leaderboards, an expert marketplace, or school dashboards. But if parents do not sustain setup after two weeks, every expansion layer behind it becomes meaningless.

In a multi-sided model, virality does not replace core value. “Architecting for or relying on virality” is an anti-pattern in multi-sided-model validation: first establish a clear valuable behavior and an early-adopter group that genuinely needs the product.

“That is a great idea,” “children need this skill,” or “I would use it if the app existed” are subjective signals. Stronger signals include parents describing a real failure, agreeing to let their child join a pilot, taking time to set up, returning in week two, referring others, or paying. SmartKid’s guidance recommends asking about past behavior rather than asking users what they would do in the future.

When a BMC or Lean Canvas only says “parents with children aged 6–14” or “children and parents,” the team will not know whom to interview, which message to optimize, or which metrics to track. Separate at least “children as users” and “parents as decision-makers/payers” directly on the Canvas.

First-month revenue may come from curiosity, promotions, or personal networks. What determines long-term health is how many families continue using the product, continue receiving value, and continue paying in later months.

SmartKid does not need to “prove the project will succeed” as it enters the MVP phase. The team only needs to clarify the largest risks with small, fast, and real evidence. This checklist should be completed before investing in extensive feature development.

• Complete the BMC or Lean Canvas, clearly separating children as users, parents as payers, and schools or partners.
• Conduct at least 5–10 interviews with parents who have relevant past behavior.
• Select a narrow early-adopter segment and a specific trigger situation.
• Run a 7–14 day pilot with 10 families using a Concierge MVP.
• Measure child return rate, parent continuation rate, and the number of real-life behaviors confirmed.
• Make a specific offer with a real price to validate willingness to pay.
• Record every reason for dropping out, declining payment, or failing to complete tasks.
• Create a technology roadmap only after identifying which behavior loop needs automation.

A final message for the SmartKid team and other student projects: entrepreneurship does not begin with completing a product. It begins with finding an assumption that could make the entire model wrong, then designing the fastest possible way to test it. If SmartKid helps a small group of families sustain one positive real-life habit, the team has built a far more valuable foundation than an MVP packed with features that no one returns to use.

This is a practical perspective drawn from mentoring SmartKid during its preparation stage. As the project moves into delivery, the most important goal is not to build faster, but to learn faster from real users.