PTE Nepal: the website, Android app and backend behind an exam-prep company

PTE Nepal coaches students for the PTE Academic and PTE Core exams. It writes for students outside Nepal too, with pages for India and Bangladesh and for Nepali students in Sydney, Melbourne, London and Toronto. The business runs on content: weekly prediction lists, score calculators, booking guides and an enquiry form that leads to coaching.

The site started in January 2026 as a single static HTML page. That was enough to exist. It was not enough to publish a steady stream of articles, run a student portal, send email or support an app. The work since then has replaced that page with a platform that can.

The website is a Next.js 16 and React 19 application, built as a static export and served from Firebase Hosting. A static export means every page is plain HTML on a CDN, with no page server to fall over when a prediction list is shared widely. The build also optimises images, generates a social-share image for each article and pulls Nepal Rastra Bank exchange rates, so the approximate prices shown in other currencies are refreshed with every build.

The site is more than a blog. It carries a free assessment and enrolment flow, pricing, a PR points calculator for Australian visa subclasses 189, 190 and 491, a PTE Core CLB calculator for Canada, country pages for India and Bangladesh, a test-booking guide, scholarships, a student dashboard and a staff admin.

PTE Sprint is the Android app, listed on Google Play as PTE Sprint: 1-on-1 PTE Coach, package com.ptesprint.app, and published under the Lattice Nepal organisation account. It is written in Flutter and is at version 1.6.0. The plan for the first version listed three features: a weekly prediction alert sent by region, a coach tab with regional pricing and an intake form, and share links tagged by source. Sign-in with the same account as the website, and instructor chat, were later moved into the launch release. The plan says, in so many words, no AI scoring, no mock tests and no question banks, now or later. It gives the app's job as proof, community and price, not lead count.

Behind both sits a FastAPI backend with PostgreSQL, Firebase sign-in shared by the website and the app, rate limits on public endpoints and transactional email. Access is decided by named roles (student, teacher, support, moderator, admin) checked in one place, not by a scatter of true-or-false flags.

The server's setup is kept as code, so it can be rebuilt from the repository. Backups run on a schedule and are copied off the server, certificates and exposure are checked daily, and alerts go out only when something needs a person.

The weekly prediction batch publishes itself. A daily job collects the source, checks it, creates the week's articles, verifies them on the live site and records the batch so notifications can go out. When a new list appears, the chain runs to completion without a human.

App releases go to Google Play in stages, 20%, then 50%, then 100%, with at least 48 hours at each step to watch for problems. No package can be added to the app until it has a recorded security review. The version number has one source, and the upload step refuses a build whose number does not match it.

Content has its own gate. Regulatory facts, such as visa points and score requirements, live in one file that writers take them from, and a check blocks any change that contradicts it. Before the gate went live in May 2026, all 156 published articles were checked against Pearson and government sources, and 564 corrections were applied.

We publish only numbers anyone can check, with the date they were taken. Speed and stability come from Google's own tools: real-visitor data from the Chrome UX Report and a lab test from PageSpeed Insights, both public for any site.

Visitors come from well beyond Nepal: Singapore, the United States, Australia, India and Canada are among the largest sources of traffic. We do not quote the client's private traffic, enquiry, enrolment or revenue figures, and we have no app install or rating numbers to report.

Most of it comes down to doing a few dull things early. Each is cheap to set up in the first weeks and expensive to retrofit after the first incident.

• Start static. A static export on a CDN is fast and cheap, and leaves the API to do only the work that needs a server.
• Keep facts in one place. If visa points or fees appear in 150 articles, put them in one file and check articles against it before they go live.
• Automate the weekly job first. Whatever you publish every week should run itself, with a check on the live site at the end.
• Write down what the app will not do. PTE Sprint's plan rules out AI scoring, mock tests and question banks, now or later.
• Roll out in stages. A 20% release with 48 hours of watching costs two days, and a bad build reaches a fifth of users instead of all of them.
• Back up off the server. Backups that live on the same machine are not backups.

The parts, as they stand in October 2026.