Every software product has a story behind it — the research trips, the disagreements, the late nights, the moments where everything almost fell apart. This is SchoolPak's story. We're sharing it not to impress you, but because we think the process matters as much as the product.

It Started With Frustration, Not Inspiration

SchoolPak didn't begin with a whiteboard session or a pitch deck. It began with a conversation — a headmistress in Kumasi describing how she spent three days every term manually computing report cards for 480 students. Her teachers were doing the same, in duplicate, on paper.

We had heard similar complaints before. School software in Ghana existed, but most of it was either too expensive, not adapted to Ghanaian curriculum structures, or simply clunky — designed for somewhere else and force-fitted here. We decided to build something from scratch, designed specifically for how Ghanaian schools actually work.

But first, we had to understand how they actually work.

The Research Phase: 12 Schools, 3 Regions

Before writing a single line of code, our team visited 12 schools — basic schools, JHS, and SHS — across Greater Accra, Ashanti, and Eastern Region. We sat with headteachers, classroom teachers, school administrators, and PTA chairs. We observed how they processed admissions, how results were computed, and how they communicated with parents.

What we found was eye-opening:

• No two schools use the same grading formula. Some follow the Ghana Education Service (GES) standard exactly; others had modified it over decades. Any system had to be flexible.
• Communication was almost entirely WhatsApp-based. Formal letters existed but were slow. Parents responded better to SMS and messaging apps.
• Data was everywhere except the computer. Attendance registers were paper. Fee receipts were handwritten. There was no single source of truth.
• Teachers distrusted technology that complicated their lives. Previous attempts at digitisation had failed because the systems required too much manual re-entry.
• Network connectivity was intermittent. Any solution had to work — at least partially — offline.

These weren't bugs to fix. They were the requirements. We wrote them all down and used them to draft our first proper specification.

Choosing the Tech Stack — And Why

With the requirements clear, the technology choice was straightforward. We chose Next.js for the frontend and Firebase for the backend. Here's why:

• Next.js gives us server-side rendering for fast initial loads even on slow connections, with the flexibility of a full React ecosystem. Role-based routing is clean and maintainable.
• Firebase Firestore handles offline caching automatically. Data syncs when connectivity is restored — critical for schools with patchy internet.
• Firebase Authentication simplified the multi-role login system (admin, teachers, parents, students) without building auth infrastructure from scratch.
• Tailwind CSS kept the UI consistent and responsive without a heavy component library we'd have to override constantly.

We deliberately avoided complex microservices. SchoolPak needs to be maintainable by a small team. A clean monolith — well-structured — is more reliable than premature distributed architecture for a product at this stage.

The GES Grading Algorithm: The Hardest Problem

The most technically challenging part of SchoolPak was not the database design or the authentication system. It was the grading algorithm.

GES prescribes specific grade boundaries for different subjects and levels. But the reality in schools is more complex: continuous assessment weights vary by subject and level, some schools add teacher discretion scores, and BECE preparation tracking requires longitudinal data across terms.

We went through four iterations of the grading engine. The first three failed edge cases — a student who missed an exam, fractional weights that didn't sum to 100, subjects with different CA/exam splits. The fourth version is what ships today: a configurable engine where each subject's weighting, rounding rules, and grade boundaries can be set per school and per level, defaulting to the GES standard but adaptable.

"The algorithm isn't glamorous code. It's a lot of conditionals and edge cases. But getting it right is what makes SchoolPak actually usable in real classrooms."

Getting it right required going back to three of our research schools and asking teachers to manually grade test data using their real procedures — then comparing against our output until both matched.

MoMo Integration: More Bureaucracy Than Code

Parents in Ghana pay school fees predominantly via Mobile Money. Supporting MoMo in SchoolPak was a business-critical feature. What we underestimated was how much of the challenge was bureaucratic rather than technical.

The code itself — connecting to the Flutterwave API, handling webhooks, reconciling payments — took about two weeks to build and test. The paperwork took six weeks. Business registration documents, bank statements, school partnership letters, integration approval. We learned that MoMo integrations in Ghana are a compliance exercise as much as a technical one.

We document this because if you're building a Ghanaian fintech product, plan for this time. Budget for it. It won't go faster by rushing the provider.

Beta Testing: The Feedback That Hurt

We ran a beta with three schools for one full academic term. This was humbling. Some things we thought were well-designed turned out to be confusing in practice:

• Teachers couldn't find where to enter mid-term scores — we'd buried it two levels deep in a navigation menu. We moved it to the dashboard.
• The parent SMS notification was firing for every single grade entry, flooding parents with messages. We added a "publish results" gate — notifications only send when the teacher marks a term complete.
• The attendance summary page was designed for a desktop. Most teachers were using phones. We redesigned the attendance module to be mobile-first.
• One school had a headteacher who was not tech-savvy. Their first-week experience was poor enough that they almost dropped out of the beta. We assigned them a dedicated onboarding session and rewrote the getting-started guide.

Every one of these issues was caught in beta — not in production. We are grateful for that.

What We Learned

Six things we would tell ourselves at the start:

1. Research is not a phase. It's a habit. Don't stop visiting schools once you start building.
2. Teachers are your real users, not administrators. Optimise for the people doing data entry every day.
3. Compliance takes longer than code. Start it first, not last.
4. Offline-first is not optional in Ghana. Build it in from day one, not as an afterthought.
5. A bad onboarding experience can kill an otherwise good product. Invest in your first-week experience as much as your features.
6. Iterate in public, not in secret. Schools that feel heard become your best advocates.

What's Next for SchoolPak

SchoolPak is live and being used in schools today. But it is not finished — good software never is. On our roadmap: a parent mobile app, WAEC/BECE result tracking and prediction analytics, multi-school district administration, and a curriculum resource library for teachers.

If you run a school and want to see SchoolPak in action, we'd be glad to walk you through it.

Book a SchoolPak Demo