01Case study

Multi-Sided Education Lending Marketplace

A digital marketplace connecting borrowers, school partners, lenders, vendors and administrators through guided applications, automated matching and a shared operational system of record.

  • Next.js
  • React
  • Node.js
  • Express
  • MongoDB
  • Zoho One
  • Auth0
  • AWS
Multi-sided education lending marketplace borrower and partner experience
02Challenge

The problem

Education financing is a chain of handoffs between borrowers, schools, lenders, vendors and operators. The platform had to hide application complexity, enforce organization-specific access and keep credit, identity, documents, CRM records and referral data synchronized without exposing the seams to borrowers.

  • Collect detailed personal, education, employment, banking and credit information without making the journey feel like paperwork
  • Give each partner visibility only into the applications and activity belonging to its organization
  • Keep CRM, identity, credit, documents and marketing systems aligned in near real time
  • Match one borrower application against multiple lender eligibility models
  • Preserve partner and referral attribution throughout the lending funnel
  • Remove manual re-keying between application and lender systems
03Solution

How it was solved

Five purpose-built portals read from and write to the same underlying application model, with Zoho CRM acting as the operational system of record. Guided borrower workflows, lender-rule matching, referral routing and a dedicated API layer automated the handoffs between applicants, schools, lenders and internal teams.

04Evolution

Delivery path

  1. 01 · Discovery

    A borrower arrived directly or through a school or affiliate short-code link into a consistently branded financing funnel.

  2. 02 · Prequalification

    A guided form captured personal, education and income details and supported a soft credit check without affecting the borrower’s score.

  3. 03 · Application

    The borrower submitted one application rather than repeating the same information for each potential lender.

  4. 04 · Matching

    Configurable lender eligibility rules ranked suitable financing paths against the borrower and chosen program.

  5. 05 · Referral attribution

    School, vendor and affiliate context stayed attached to the application and synchronized into Zoho CRM.

  6. 06 · Lender handoff

    The selected lender received a structured application containing prequalification, program and partner context through a shared API contract.

05Architecture

Platform topology

Every role used the same application record while portal and API authorization limited what each organization could see or change. Zoho CRM anchored business records and referral attribution across product surfaces.

Borrower app   Partner portal   Lender portal   Admin / vendor
      \              |                |                /
       └──────────────┴────────────────┴───────────────┘
                              │
                              ▼
                    Next.js / React portals
                              │
                              ▼
              Node.js / Express partner & lender APIs
                              │
          ┌───────────────────┼───────────────────┐
          ▼                   ▼                   ▼
       MongoDB            AWS / S3           Auth0
                              │
                              ▼
          Zoho One / Equifax / SendGrid / partner APIs
06Product

Product surface

  • Borrower

    Guided prequalification, lender discovery and one application distributed to matched lenders

  • School partner

    Institution-scoped applications, students, billing and enrollment-linked referral leads

  • Lender

    Eligibility rules, approved partners, application documents, reporting and direct submission APIs

  • Vendor

    Structured onboarding through the operations pipeline and access to referral workflows

  • Administrator

    Network-wide applications, partners, lenders, vendors, reporting and exception handling

07Engineering

Technical highlights

  • Shared system of record

    Portal activity traced back to a consistent application and CRM record, so referral changes, eligibility updates and manual overrides propagated across the network.

  • Role-aware product surfaces

    Borrower, school, lender, vendor and administrator portals exposed focused workflows and organization-specific visibility over shared data.

  • Automated lender matching

    A single application was evaluated against configurable lender criteria, enabling borrowers to compare suitable financing options without duplicate entry.

  • Standardized lender handoff

    A dedicated API contract delivered complete application, program, prequalification and attribution context to approved lenders.

  • Referral integrity

    Dynamic partner links and CRM synchronization preserved school and affiliate attribution throughout the borrower funnel.

  • Operational delivery

    Reusable hooks, validation utilities, shared UI components and GitHub CI/CD supported a broad, integration-heavy platform.

08Integrations

Connected systems

  • Zoho CRM

    System of record for contacts, accounts, programs, submissions, applications and partner/referral attribution.

  • Zoho Bigin

    Managed the vendor onboarding pipeline from first contact through approved network participation.

  • Zoho Analytics & Marketing Automation

    Provided operational dashboards, reporting and lifecycle campaigns across borrower and partner journeys.

  • Auth0

    Identity, authentication and route-level access control across the role-specific portals.

  • Equifax

    Soft credit checks supported prequalification without impacting a borrower’s credit score.

  • AWS S3 & SendGrid

    S3 stored borrower and partner documents; SendGrid delivered transactional application and referral email.

09Scope

What the team delivered

  1. Contributed to five role-specific portals sharing one application record

  2. Developed guided borrower prequalification and application workflows

  3. Supported automated lender matching against configurable eligibility criteria

  4. Built partner and lender API paths that replaced manual application handoffs

  5. Integrated Zoho One, Auth0, Equifax, S3 and SendGrid

  6. Supported AWS delivery and automated GitHub CI/CD

10Services

Repos & services

Anonymized service family across the platform.

ServiceResponsibilityStack
Borrower ExperienceDiscovery, prequalification, application, matching and lender selectionNext.js, React, Tailwind CSS
Partner Operations PortalInstitution-scoped students, applications, billing and enrollment leadsNext.js, React, Zoho CRM
Lender Operations PortalEligibility configuration, partner access, documents, submissions and reportingNext.js, React, Node.js APIs
Network Operations ConsoleVendor onboarding, administration, oversight, reporting and exception handlingReact, Zoho One integrations
Partner Integration APIStandardized lender submission, application handoff and referral synchronizationNode.js, Express, MongoDB
11Outcomes

Results that matter

  • Centralized borrower, school, lender, vendor and administrator workflows around one application record

  • Replaced manual lender data re-entry with a standardized application handoff

  • Made lender onboarding primarily a configuration exercise rather than a bespoke integration project

  • Kept partner and referral reporting synchronized in Zoho CRM

  • Provided one consistent borrower journey across direct and partner-referred entry points

The represented platform included five production portals and more than ten external integrations, delivered through AWS infrastructure and GitHub CI/CD.

Multi-sided marketplace architecture, role-aware portals, lending workflows, partner APIs, CRM synchronization and cloud integrations.

12Boundaries

Scope & caveats

These implementation boundaries keep the public description technically honest.

  • Backend test coverage, shared frontend/API types and schema-driven decomposition remained ongoing investment areas.
  • API-layer access control required continued hardening as the partner network and portal surface expanded.
  • Claims describe a team-built platform and should not imply sole ownership of all portals or integrations.
13Visuals
Guided education-finance application and automated lender matching
School, lender, vendor and administrator portal architecture
15Next step

Need similar technical experience applied to your requirement?