Skip to content

An app for your coaching institute: Classplus, AppX or a custom build?

A cash payment at reception should unlock the right batch. How to test Classplus, AppX or Graphy against your real process before paying for custom software.

A fee paid at reception should unlock the right batch. Illustration; the logos mark the platforms discussed.
In this article9 sections
  1. What the named platforms advertise
  2. Write the process before the feature list
  3. Use the same demonstration with every vendor
  4. Compare cost over the same period
  5. Data ownership needs a working export
  6. Security and content protection are separate questions
  7. When a custom build earns its place
  8. Make the next decision with a sample batch
  9. Sources

Imagine a student paying for a batch at the front desk, opening the institute's app that evening and finding the course locked. The staff member knows the payment arrived. The app does not.

That failure says more about the software you need than a row of screenshots showing your logo on a phone. An institute's app has to agree with the people admitting students, collecting fees and teaching them.

For a standard course business, I'd evaluate an existing platform before commissioning software. Classplus, AppX and Graphy already advertise tools for branded learning products. A custom build becomes worth investigating when your teaching or administrative workflow has requirements those products can't demonstrate, or when the contract doesn't give you the control you need.

SituationEvaluate firstWhat would change the decision
Recorded courses, live classes and standard testsA managed teaching platformFormats or permissions it can't demonstrate
Several offline batches with fee instalmentsA platform with a demonstrated offline workflowRepeated manual reconciliation or unsupported fee rules
Individual mentorship with evaluator allocationA platform demo against the exact processAssignment, review and payout rules it can't support
Courses work well, admissions follow-up doesn'tKeep the teaching software; fix admissions separatelyNo workable export or integration
A distinct product with a maintained development budgetCustom discovery and a prototypeA platform meets the same needs at an acceptable cost

That is our buying framework. It is not a claim that any named platform lacks those capabilities.

What the named platforms advertise#

The comparison below uses official vendor pages checked on 4 October 2026. It summarises advertised products, not a hands-on test. A sales page doesn't establish reliability, support quality or suitability for your institute.

PlatformWhat it advertisesVerify in your demo and quote
ClassplusBranded Android app, website, admin portal, courses, live classes and online testsOffline enrolment, fee rules, export, renewal terms and usage limits
AppXBranded websites and apps for courses, test series, webinars, memberships and communitiesYour teaching format, developer-account control, data export and full running cost
GraphyCourse-selling tools, branded apps and live classes; integrations vary by planTransaction charges, app inclusion, concurrent classes and the plan needed for APIs

Classplus displayed about $316 for a one-year plan and about $421 for two years at the check date (converted from its rupee prices). Those are advertised offers, not a quote. Get tax treatment, renewal pricing, payment charges and any fair-use conditions in writing.

AppX's demo page advertises one-time pricing and asks for a custom quote, without a numeric price. "One-time" should prompt questions about hosting, video delivery, upgrades and future changes.

Graphy's pricing page showed a Launch section at about $263 a year plus a 10% transaction fee per sale or about $0.11, whichever is higher (converted from its rupee prices). The same page also contained an about-$21-a-month, annually billed section. Treat that mismatch as a reason to request a dated written quote, and don't build a contract price by combining sections.

None of this tells you which vendor is best. It tells you what to clarify before paying.

Write the process before the feature list#

Take a real batch and follow it through your institute, using test records so no student information is exposed:

  1. EnquiryWho responds, and where does the record live?
  2. EnrolmentA course, a batch or a deposit?
  3. AccessWhen can they open lessons, submit work or book a session?
  4. ChangeA cancellation or a batch transfer.

Those details show whether a platform matches your business. "Payments supported" doesn't answer whether a cash payment at reception unlocks the correct batch without a second staff entry.

For a mentorship product, write down who assigns an evaluator, what happens when that person declines, how a submission receives feedback and how staff resolve a disputed evaluation. If your process needs a new workflow, ask the vendor to show it rather than declaring it impossible from a brochure.

I'm more interested in the receptionist completing an ordinary task correctly than in an extra animation on the student dashboard. The task is what you'll repeat all year.

Use the same demonstration with every vendor#

Prepare a short script of the situations that create work for your staff. Here is an example:

  1. Add a student who paid offline and enrol them in the correct batch.
  2. Record a part payment and show what the student can access.
  3. Move that student to another batch without losing their records.
  4. Publish a lesson and check access from the student's phone.
  5. Start overlapping live classes with the staff accounts you intend to use.
  6. Submit an answer file, return feedback and find the previous submission.
  7. Cancel an enrolment, record the refund and remove the right access.
  8. Export that student's enrolment, payment and learning records.

Mark each step as demonstrated, configurable, a paid addition or unresolved, and note any extra charge and who owns the workaround.

Ask a teacher and an administrator to perform the tasks. A vendor clicking through a prepared account proves less than your own staff doing the work on realistic records.

Compare cost over the same period#

A platform subscription and a custom-development invoice buy different responsibilities. One may include a maintained shared product. The other may give you code and a handover, with operations charged separately. Compare them over a period you can budget, with the same sales and usage assumptions:

Managed platform = setup + subscription + transaction charges
                 + paid additions + migration + staff workarounds

Custom system    = discovery and build + hosting and video delivery
                 + maintenance + future changes + migration
                 + payment and messaging charges + operations

A percentage fee deserves its own calculation. Suppose you make 500 sales at $20 each in a year: $10,000 in sales. At the 10% fee displayed in Graphy's Launch section, that is $1,000 in transaction charges, because each sale's percentage is above the minimum. The sales volume is invented; the percentage is from the vendor's page.

That amount excludes the subscription, taxes and other charges, and it doesn't prove a custom product would cost less. Ask which fee base applies, how refunds work and whether payment processing is extra, then compare against an actual custom quote that includes running the system.

Our build-or-buy article goes deeper into that decision. For WhatsApp reminders and admissions messages, see the WhatsApp API cost guide; messages shouldn't disappear into a vague "automation included" line.

Data ownership needs a working export#

Ask what you can take away when you leave. "Your data is yours" is only useful if you can get a usable copy.

Request an export during the evaluation. Check that it includes student identities, batch enrolments, orders, payment status, submitted files, feedback and progress where you need them. Open it and see how the records relate to each other. A contact list can't reconstruct outstanding instalments.

Also check ownership of the domain, app-store developer accounts, uploaded content and integrations. For a custom build, specify the code repository, infrastructure accounts, credentials and handover documents. For a platform, specify export rights, notice periods and migration support.

If the vendor closes, a payment fails or you decide to move, who can keep students learning? That is a fair question for an agency too.

Security and content protection are separate questions#

Content protection asks whether students can share paid material. Data security asks who can access student and staff records. A protected video doesn't answer whether every administrator can download the entire student list.

Ask for staff roles, named accounts, access logs and the deletion process, and check how backups restore a mistaken deletion. If students are minors, include age and guardian workflows in the product discussion and have your adviser review the duties. Our DPDP checklist outlines the engineering questions.

For lesson protection, ask the vendor to demonstrate its controls on the devices your students use: download behaviour, device limits and access expiry. Don't treat a claim such as "100% content security" as a guarantee against copying.

If you want a native app, include distribution and payment review in the scope. Apple's App Review Guidelines distinguish digital purchases, reader apps and different service models. Ask the provider to explain the rules for your course or mentorship flow and selling regions.

When a custom build earns its place#

Custom software deserves a closer look when the unsolved workflow is frequent, material and specific. Perhaps every evaluated answer needs an allocation process, an internal review and a record of revision. Perhaps batch access depends on a fee arrangement your staff can't represent in the shortlisted products.

Before committing, estimate the work the missing process creates: the task, who does it, how often and the mistakes that need correcting. Use numbers observed at your own front desk.

Then prototype that process, and decide how you'll judge it before a full build starts. A useful acceptance condition: an administrator records an offline payment and the right student access changes without a duplicate entry.

You may still keep the existing teaching platform. A small administrative tool can be easier to run than replacing courses, videos, tests and payments at once. Confirm the integration and export rights first.

Make the next decision with a sample batch#

Choose one batch, prepare the demo script and request itemised quotes. Keep unresolved points visible. If a platform meets the process and commercial requirements, buying it is a sensible decision. If it can't, you'll have a clear brief for custom work.

If you're choosing a coaching app, send us your batch structure, fee process and the workflow your current tools can't handle. We'll compare the demonstrated options and scope a platform integration or custom build around those requirements.

Sources#

Checked 4 October 2026. Prices are advertised observations, not contracts, and the platforms were not tested hands-on.

  • Classplus, branded-app offer: capabilities and the displayed one- and two-year offers.
  • AppX, product website and demo offer: products and the one-time-pricing claim, with no numeric price shown.
  • Graphy, pricing: plan descriptions and the transaction-fee structure, with conflicting sections on the retrieved page.
  • Apple, App Review Guidelines, sections 3.1.1 and 3.1.3.