Bytevancer SMS — the school management platform
Run your schoolon software thatnever pretends.
Admissions, fees, attendance, exams, payroll and the family portals around them — for schools, academies and colleges anywhere. Every institute gets a database of its own, every rule is the school’s own setting, and where something is not ready, the screen says so.
API-first · PostgreSQL 17 · a separate database for every school
Counted from the codebase
Figures re-verified August 2026
69
Modules built
each with an API and a screen
368
API endpoints
337 school · 31 platform
505
Unit tests
1,978 assertions, under a second
14
Isolation tests
two live PostgreSQL databases
27
Documents studied
from a working school
1
Database per school
yours alone, from day one
Nothing here is projected or rounded up. No invented customers, no “trusted by 500 schools” — the product is new, and says so.
The first week
From an empty database to a working office
No implementation project, no consultants. Registration is reviewed by a person — and once your school exists, the path to a running office is the software's own.
Register — a person reads it
No signup button provisions anything. We check the institute exists and telephone you; approval creates a PostgreSQL database that is yours alone, your web address, and the administrator account whose password you chose.
tenant_<uuid> — created at approval
Bring your students in
Import from the spreadsheets your office already keeps, mapping your columns to ours on screen. Custom fields carry whatever your forms record that our defaults do not.
import · column mapping · custom fields
Hand out the logins
Bulk-create portal logins for parents, students and teachers, then print the credential slips — three to a row, cut and hand out at the gate. Nobody types four hundred passwords.
bulk logins · printed slips
Set your rules
Pass mark, grade bands, late fine, session dates, the words on screen. The defaults come from a real school's verified practice; every one is your setting, not our constant.
settings · per school, never global
The first fee run
Fee structures and concessions once, then vouchers for everyone. Collection at the counter posts to each child's ledger; receipts are numbered, and a mistake is reversed — never deleted.
vouchers · ledgers · numbered receipts
The daily rhythm
Attendance each morning, a timetable the system refuses to double-book, homework and notices that publish when you say. The office stops living in registers it cannot search.
attendance · timetable · publish
How it behaves
Three mechanisms competitors get wrong
A school system is judged on its worst day — a disputed voucher, a leaked result, a message that never arrived. These are the rules built for those days.
Fees & money
Arithmetic you can defend at the counter
A fee voucher is a document a family may dispute, so the maths is built to be argued with. It lives in small, pure, unit-tested classes — asserted against three real vouchers from the school we studied.
- Money is exact integer paisa — never a floating-point number
- Payments allocate to the oldest charge first, so no month settles twice
- Receipts reverse, never delete — a gap in the serials is an audit signal, kept
- Concessions stack by rule and cap; late fines run as a batch you control
Exams & results
Results arrive when you announce them
Staff see marks the moment they are computed. Families see nothing until the school presses publish — and homework and notices follow the same rule. No family learns a result from the software before they hear it from you.
- Pass marks and grade bands are your settings — the 40% default is a real school's, not a law
- One failed subject fails the child — the rule families actually hold schools to
- Ranking, merit lists, fail analysis, the annual gazette — computed, printable
- Datesheets and admit cards print two to a page with a cut line
Communication
Two-way with families, on the record
Real conversations between the office and each family run inside the product today — they need no SMS gateway, which is why they are the one messaging feature that never shows a caveat.
- One thread per family — opening it again finds the same thread
- A participant is a staff member or a guardian, never a student
- Internal staff notes are excluded from the family's view in the query itself
- Outbound SMS is built end to end and says plainly when no gateway is connected
The catalogue
The whole school, A to O
81 modules are working or awaiting your configuration today, and the catalogue says plainly which is which — including the ones that are honestly not built.
Four seats
Built for each person at the school
The same records, four very different jobs. Each seat sees what its work needs — and structurally cannot see what it does not.
The counter jobs come first: fee collection against each child's own ledger, a visitor book that doubles as the fire register, the telephone and postal logs, and the school store's counter — where a sale and a free textbook issue are different transactions, because only one takes money. Global search is one keystroke, and nothing at the desk can be deleted, only corrected on the record.
A teacher's login reaches their own classes and nobody else's — the pickers themselves are narrowed, so the software never offers a class it will refuse. The register belongs to the class teacher; marks, homework and syllabus belong to the subject teacher. Homework set for the whole class is one record, not four copies that drift apart, and a child excused from it is left out of the average rather than punished with a zero.
Expected against collected and the recovery percentage, defaulters with phone numbers, fail analysis by subject, syllabus coverage measured two honest ways — of the whole plan, and of what was due by now. The audit trail answers who changed what; the health page even catches a scheduler that was never installed. Office roles hold the explicit all-classes permission, so scoping teachers never locks the head out of their own school.
Each family signs into a private portal: dues, attendance, homework, study material, and results the moment the school publishes them — for their own children and no one else's. A guardian's account is not a staff account and cannot become one; another family's child simply does not exist as far as it can see. Getting started is a printed credential slip, not an app-store hunt.
Safeguarding
Guardrails in the structure, not the settings
A rule a hurried administrator can switch off is not a rule. These live in the schema, the queries and the gates — where no checkbox reaches.
Parents are never staff
Guardians authenticate as guardians. A parent's login satisfies no staff permission — enforced at the gate, on every route.
Another family's child does not exist
Portal queries resolve children through the guardian's own record, so a wrong guess is indistinguishable from a number that was never issued.
Messages go to adults
A thread participant is a staff member or a guardian — the schema cannot address a child, so the rule cannot be misconfigured away.
Reads are logged, not just writes
Whenever our own staff so much as look at your institute's data, it lands in a log with no edit and no delete — 'who looked at our records' has an answer.
Photographs lose their metadata
Uploads are re-encoded on arrival, which strips EXIF — including the GPS position of the family home a phone camera quietly embeds.
The public form keeps nothing it shouldn't
Online admission is off by default, takes no file uploads, and stores no IP address. Its reference number is deliberately unlike an admission number.
Engineering
Proof, not promises
The claims a vendor cannot fake: what is tested, what the database itself refuses, and what happens when things go wrong.
Tested where it hurts
The arithmetic that costs real money or decides a child’s result — fee lines, arrears carry-forward, payment allocation, concession stacking, grading, ranking — lives in pure classes with no database behind them, asserted against three real vouchers from the school we studied.
505 tests · 1,978 assertions · under a second
The line that cannot be crossed
Fourteen isolation tests provision two real PostgreSQL databases as two schools and try to reach one from the other — before every release, and after any change near the boundary.
Backups that prove they restore
Nightly, every school: a real PostgreSQL dump plus CSV any spreadsheet opens in thirty years. Weekly, the newest archive is restored into a throwaway database and every table is compared against live — from the database’s own catalogue, not a hand-kept list that could quietly check less than it claims.
02:15 backup → Sunday 03:30 restore-verify → compared
Rules the database itself enforces
A validator alone leaves a gap between the check and the write, so the invariants that matter are constraints too: the timetable’s clash rules are partial unique indexes, a library copy can hold one open loan, and the store’s stock arithmetic cannot express a negative shelf.
Unknown is an answer
An unpriced bus stop is not a free one; a vehicle with no capacity entered is neither over nor under; a syllabus with nothing due yet is not 100% on schedule. The system reports “unknown” rather than guessing “fine”.
Health that hears silence
The health page distinguishes a scheduler that broke from one that was never installed — the single most common reason a “nightly job” turns out never to have run — and prints the exact line to fix it.
Leave whenever you like
The whole school exports at any time — every dataset as CSV, plus the real dump. Your data was never ours to keep, and no export request goes through us.
Anywhere
Proven where school software has it hardest
This product was built and verified against South Asian schools — fee arithmetic families dispute at a counter, bilingual printed documents, daylight screens and inexpensive Android phones. A system that holds up there holds up anywhere, and it is API-first for exactly that reason.
- Every business rule is a per-school setting — pass marks, grade bands, fines, terminology, session dates
- Documents print bilingual English–Urdu, set in Nastaliq — the script Urdu readers actually read
- Dates are typed day-first the way clerks worldwide write them, and refused when impossible
Two honest limits, so this section cannot oversell: the school-side fee ledger renders amounts in rupees today, and the interface is English. Platform plans carry a proper ISO currency code — the pricing page shows whatever the billing system sends.
ہر دستاویز، پرنٹ کے لیے تیار
“Every document, ready to print.” — the same sheet, two scripts, one Ctrl+P.
Straight answers
What we’ll tell you before you ever pay us
Where the product depends on a decision only you can make, it says so — on this page and on its own screens. A job reporting “247 messaged” while contacting nobody is worse than no job at all.
No SMS gateway is bundled
You connect your own SMS provider. Until you do, every messaging screen says plainly that nothing is being sent — there is no green “sent” tick that isn’t true.
Online fee payment isn’t built yet
It waits on a payment-provider decision, not on code. Fees are collected at the counter and recorded exactly, with receipts you can defend.
Off-site backup is storage you control
The nightly job, retention and weekly restore-verification are built in. You point them at storage you own — we think a school should hold its own backups.
No native apps yet
The parent, student and teacher portals work well in a phone’s browser today. Apps are the next stage of the build, sequenced after the portals proved the API — which they now have.
No customer logos to show you
The product is new. It was designed by studying a working school’s system and its 27 printed documents — but we would rather show you test counts than invent a testimonial.
That is the house rule: when a screen cannot yet do its job, it says so on the screen — in words, not a grey icon.
Questions
Asked before signing, answered before selling
Every answer holds to the same rule as the product: say what is true, including the parts that are not finished.
Yes — structurally, not just by promise. Each school's records live in their own PostgreSQL database, created when the school is set up. Before every release we run fourteen isolation tests that provision two real databases with different schools' data and try to reach one from the other. And whenever Bytevancer's own staff access your institute — even just to look — it is written to a log that cannot be edited or deleted.
The messaging modules — bulk messages, templates, absence alerts, delivery logs — are built end to end. What is not yet in place is an SMS provider: that is a connection your deployment makes, not code to be written, and until it is made every messaging screen says so plainly. Two-way conversations between the school and families work today, because they happen inside the product and need no gateway.
Not yet, and we will not pretend otherwise. Online payment waits on the choice of a payment provider — a wallet, a gateway, a bank — which is a commercial decision, not a technical one. Today fees are collected at the counter and recorded against a proper per-student ledger, with numbered receipts that are reversed rather than deleted.
The product is API-first and every business rule is a per-school setting: pass marks, grade bands, fine amounts, session dates, even the words on screen ('grade' for 'class', 'stream' for 'section'). Two honest limits, stated rather than hidden: the school-side fee ledger renders amounts in rupees today, and the interface is English with Urdu carried on printed documents. Platform plans carry a proper ISO currency code, and the pricing page shows whatever the billing system sends. If those limits matter for your institute, tell us at registration — that is exactly what the review call is for.
The parent, student and teacher portals are live and work well in a phone's browser. Native apps are the next stage of the build — the product's own catalogue sequences them after the web portals have proven the API, and that point has now been reached. We would rather tell you that than put a store badge on this page early.
Every school's database is backed up nightly, kept to a retention policy, and — this is the unusual part — automatically test-restored into a scratch database with every table compared, so the backup is proven restorable rather than assumed to be. One honest caveat, which the backups screen itself shows: pointing backups at off-site storage is a deployment step, and until it is done a backup protects against mistakes but not against losing the machine.
Your data is yours. You can export it in full at any time — CSV files any spreadsheet can open, deliberately, because CSV will still be readable in thirty years, alongside a real PostgreSQL dump that can restore a working system. There is no lock-in by hostage-taking; if we keep your school, it should be because the product earns it.
Yes — they are per-school settings, not our opinions. The defaults ship from a real school's verified practice (a 40% subject pass mark, for instance), and your school sets its own. The same goes for terminology: if you say 'grade' and 'stream' rather than 'class' and 'section', the system says it with you.
Urdu is carried where families will meet it: the school's name, students' and guardians' names in both scripts on records and printed documents, and message templates in Urdu and English — set in Nastaliq, the script Urdu readers actually read. Terminology is adjustable per school. We are careful not to overclaim here — see the comparison page, where one competitor's full-interface Urdu toggle is credited honestly.
Nobody yet — we would rather tell you that than invent a testimonials page. The product was designed in depth against one real school: Bismillah Educational Complex in Chiniot, whose existing system and 27 printed documents we studied field by field. That school is a design reference and, we hope, a first customer — it is not a client, and nothing on this site is an endorsement.
Plans and their limits are defined on the platform and shown from the live system rather than printed here, where they would go stale. Subscription billing is entirely separate from your school's own fee collection — the two never mix.
Registration
Put your school on it.
Registering is free and reviewed by a person. Approval provisions a PostgreSQL database of your school’s own — and if you ever want to leave, the whole-school export goes with you. Your data was never ours to keep.
tenant_<uuid> — created at approval, yours alone