Başarı Platformu — Coaching and Study Tracking
Explore the strategy, design, and development that power each project. From concept to launch, we deliver tailored digital solutions that solve real-world problems and drive measurable success.
A coaching institution's work lives in the week: the programme a coach writes for a student, what the student actually studied, what the exam result says about which topic to repeat, and the conversation between coach, student and parent. Spreadsheets and messaging apps carry that until they stop.
GG Tech Teknoloji built Başarı Platformu for Sinan İpek Akademi: a multi-tenant platform where an institution runs its own coaches, students and parents on a single data model of 101 entities.
The build ran 19 weeks and shipped with 201 test files. It is live at basariplatformu.com.
Industry
Education / Coaching
Service
Multi-tenant platform development
Technology
Next.js 16, React 19, Prisma, PostgreSQL, Redis
Timeline
19 weeks
Industry
Education / Coaching
Service
Multi-tenant platform development
Technology
Next.js 16, React 19, Prisma, PostgreSQL, Redis
Timeline
19 weeks
One Model, Four Panels
Four roles use the same system and see four different products.
The student sees this week's programme, sends the daily study report with a mood entry, follows a calendar and messages their coach.
The coach has the widest panel — 71 pages — for writing programmes, reading reports, tracking performance at acquisition level, analysing exam results, keeping private notes and recording parent meetings.
The institution manager runs coaches, students and admissions. The system administrator manages institutions, contracts, legal texts and announcements across all of them.
Underneath sits one PostgreSQL schema of 101 models. Tenancy is not four copies of the software; it is one model that knows which institution a record belongs to.
Key Features
- Weekly programme and daily report: The coach writes the programme lesson by lesson; the student reports at the end of the day what was actually studied, with a mood entry beside it. The gap between planned and done is the coach's material for next week.
- Performance at acquisition level: Progress is tracked per topic and per acquisition rather than per lesson, so "weak at maths" turns into a named list of acquisitions to repeat.
- Exam analysis against the curriculum: Results are read against the curriculum rather than as a score: which acquisitions cost points, and which topics the next programme should carry.
- Real-time messaging: Coach, student and parent talk inside the platform over Socket.io with a Redis adapter, so conversations hold across more than one server instance.
- The institution's paperwork, in the same system: Admissions, digital contracts, legal texts, announcements, popups, support tickets, SMS and email — the operational side an institution runs, next to the academic side.
- Background jobs and delivery: Report generation, notifications and SMS run as BullMQ workers with their own board, keeping slow work off the request path. 225 route handlers are covered by 201 test files.
Why Multi-Tenancy Was Decided First
The platform is built to carry more than one institution, and multi-tenancy is the kind of decision that cannot be retrofitted cheaply: every table, every query and every permission check carries it. It was drawn into the data model at the start, across 101 entities, and 101 migrations later the model still holds — one institution's coach cannot see another institution's student, because the model does not allow the question rather than because a filter was remembered.
How We Solved the Problem
Client & Context
Client: Sinan İpek Akademi
Sinan İpek Akademi coaches students and tracks their study week by week. It wanted its own platform instead of a spreadsheet-and-messaging workflow — one that other institutions could also run on.
The Problem
The weekly programme, the daily study report, exam analysis and parent communication lived in separate tools that knew nothing about each other. Nothing linked what a student was told to study with what they studied and what the exam then showed. And a workflow built around a single institution does not open to a second one without being rewritten.
Solution & Mobile Features
We built a multi-tenant platform on a single data model. Programme, report, mood, acquisition-level performance and exam analysis are joined records rather than separate files, so a coach reads the week as one story. Four roles get their own panel over the same model, and each institution's data is isolated by the model itself rather than by a filter someone has to remember.
Tech Stack & Architecture
Technologies:
Architecture: One Next.js application carries both the public site and the four panels: 163 pages and 225 route handlers. The data model is split across 27 Prisma schema files that merge into a single PostgreSQL schema of 101 models, versioned by 101 migrations. Real-time messaging runs on a Socket.io server with a Redis adapter; slow work runs on BullMQ workers in a separate process with their own board.
Our Process
- 1
Data model first: the tenancy boundary and 101 entities drawn before any panel.
- 2
Authentication and roles: student, coach, manager and administrator, each isolated in its own panel.
- 3
Programme and reporting: weekly lesson-by-lesson programmes, daily study reports, mood entries.
- 4
Performance and exam analysis: tracking at topic and acquisition level, results read against the curriculum.
- 5
Messaging and calendar: real-time conversation over Socket.io with Redis, role-based calendars.
- 6
Institution operations: admissions, contracts, legal texts, announcements, support tickets, SMS and email.
- 7
Delivery: BullMQ workers, Docker, and 201 test files covering the route handlers.
Results
Başarı Platformu is live at basariplatformu.com. An institution runs its coaches, students and parents in one place; a coach sees the programme, the report and the exam result against the same student; and another institution can join without a second copy of the software.