Product pressure
What the business needed to make true before the next stage of growth.
Back to Case Studies
Case Study
ChatTeach
EdTech Marketplace
From informal matching to a two-sided learning marketplace.
Zyvor partnered on ChatTeach to design a mobile marketplace connecting students and teachers through jobs, bids, profiles, chat, interviews, engagement decisions and payment requests — with a distinct journey for each side.
Clearer next actions for both sides.
Industry
Education Technology / Marketplace
Services
Product Strategy, UX, Mobile Product Development, Backend APIs
Engagement
Product engineering with strong architecture
Timeline
August 2023 – January 2024
Product type
Two-sided learning marketplace app
Case study structure
Overview
What this engagement was about.
Zyvor partnered on ChatTeach to design a mobile marketplace connecting students and teachers through jobs, bids, profiles, chat, interviews, engagement decisions and payment requests — with a distinct journey for each side.
Delivery path
How strategy, design, and engineering stayed connected through the engagement.
Operating model
The decisions that kept ownership, state, and next actions clear for the team.
Outcome lens
Why the work was sequenced for trust, scale, and a reusable foundation.
Challenge
Matching screens were not enough for a two-sided product.
Students and teachers move through discovery, bidding, communication, interviews, engagement and payment-related actions. If those states are implicit, each side loses confidence in what happens next.
Product pressureState gapsNext action
Signal
Post a Job
Context
Every next action belongs to a state.
Learner job posting workflow for creating learning requirements.
Business problem
A learning marketplace only creates value if both sides can complete a relationship, not just browse profiles.
User problem
Students and teachers need different mobile journeys, but they still have to agree on the same job, bid and engagement state.
Operational limitation
Chat, interviews and payment requests cannot sit outside the marketplace object if activity history is going to make sense.
Product limitation
Without a state-driven lifecycle, mobile screens show different versions of the same relationship.
What was breaking
The friction points that made the old approach expensive to keep.
Chat disconnected from job or bid context
Payments introduced without a clear engagement state
Inconsistent views of the same relationship
Activity history that cannot explain a decision
Unclear next action after a bid or interview
Strategy
Model the relationship, then design the two apps.
If jobs, bids, interviews, chat and payment requests share one lifecycle, students and teachers can have different interfaces without losing trust in the product.
Define each stage from job posting to engagement history
Give students and teachers separate views of the same state
Tie communication and payment actions to the marketplace object
Keep notification-ready workflows aligned with state changes
Solution
A collaborative, end-to-end partnership.
Zyvor designed the marketplace states first, then built student and teacher experiences, real-time communication and backend APIs around those states.
Discover
Mapped student and teacher journeys from job posting through bidding, chat, interviews and payment requests.
Define
Specified the shared lifecycle, accept/reject states and the events that should trigger notifications.
Design
Created role-specific mobile flows that always expose a clear next action.
Build
Implemented the mobile product, reusable backend APIs, chat, interviews and activity tracking.
Launch / Scale
Left a reusable foundation for marketplace growth without rewriting the engagement model.
Strategy — Key Decisions
States first. Screens second.
These are the choices that shaped the product — not a gallery of what shipped, but why the work was sequenced this way.
One shared marketplace lifecycle
Jobs, bids, invitations, interviews, chat and payments only stay coherent if they belong to one object.
Separate student and teacher experiences
Each side needs a different mobile journey, but not a different version of the truth.
Explicit accept/reject engagement states
The product has to make the decision visible, or neither side knows whether the relationship is live.
Chat and interviews inside the workflow
Communication without marketplace context becomes another disconnected thread.
Payment requests tied to engagement
Money actions need a prior engagement state, or the marketplace becomes informal and hard to trust.
Design
A mobile experience that always shows the next step.
Students should be able to post a learning need and move through bids, chat and interviews. Teachers should be able to bid, communicate and request payment without losing the job context.
Marketplace confidence comes from explicit state. If the next action is unclear, the two-sided product feels unfinished.
Dashboard as an activity surface, not a marketing home
Job posting and bidding as primary marketplace verbs
Profiles and trust information close to engagement decisions
Accept/reject and payment request screens that change the lifecycle
Trust, clarity and accessibility
Both sides should see the same relationship, even if the UI differs
Activity history should explain how a decision happened
Notifications should follow state changes, not generic app noise
Post a Job
Learner job posting workflow for creating learning requirements.
Teacher bid
Teacher-side bidding workflow inside the learning marketplace.
Public chat
Communication experience supporting student and teacher interaction.
Development
From lifecycle model to a working mobile marketplace.
The product was implemented as a cross-platform mobile application with REST APIs, real-time chat, push notifications, payment workflows and activity tracking on a cloud-backed marketplace core.
Mobile product
Cross-platform student and teacher experiences over shared marketplace states.
Workflow backend
Reusable APIs for jobs, bids, interviews, engagement decisions and history.
Realtime communication
Chat and notification-ready events connected to the marketplace object.
Commercial actions
Payment requests and activity tracking as part of the engagement lifecycle.
Key Features
The parts of the system that mattered.
Student experience
Post learning needs and move through bids, chat and interviews.
Teacher experience
Discover jobs, bid, communicate and manage engagement.
Job posting
Learning requirements captured as marketplace objects.
Bidding
Teacher-side commercial response inside the job context.
Chat
Conversation tied to the relationship, not a generic inbox.
Interviews
A governed step between interest and engagement.
Engagement decisions
Accept or reject as explicit marketplace state.
Payment requests
Money actions that only make sense after engagement.
Outcome
A marketplace both sides can actually complete.
ChatTeach became a structured two-sided mobile marketplace with clear student and teacher flows, connected chat and interview journeys, and explicit engagement states.
Clearer student and teacher flows
Each side has a distinct journey without splitting the marketplace into two products.
Connected communication
Chat and interviews sit inside the job and bid context.
Explicit engagement
Accept/reject and payment requests change the lifecycle instead of living off to the side.
Reusable growth foundation
The state model can support future marketplace expansion without rewriting both apps.
Technology
Stack used on this product.
The tools that supported delivery — chosen for the product shape, not as a generic stack list.
Cross-Platform Mobile Application
REST APIs
Relational Database
Real-Time Chat
Push Notifications
Marketplace Workflow Logic
Payment Workflows
Activity Tracking
Reporting
Cloud Services
Key Takeaways
What made this engagement successful.
Start with the state diagram
Two-sided mobile products work when both interfaces render the same lifecycle.
Keep communication in context
Chat without a job or bid attached becomes noise and loses commercial meaning.
Make every next action explicit
Users lose confidence when they cannot tell whether to wait, reply, accept or pay.
Tie money to engagement
Payment requests need a prior decision, or the marketplace feels informal.
Related Case Studies
More stories like ChatTeach.
B2B Marketplace
Alahdeen
From disconnected wholesale channels to a shared B2B marketplace.
Verification / RegTech
Mohesr Degree Platform
From fragmented verification handoffs to one controlled operating model.
Care Services Website
Salvus Care
From a confusing care directory to an accessible path families can follow.
Next step
Have a similar challenge?
If this story feels close to the pressure in your product, the useful next step is a conversation about the problem — not another gallery of screens.