The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Seven education providers work inside one platform, each signing in at its own domain and appearing under its own name. Timetables, exams, students, guardians, payments and reporting all live in the same place.
Visit the site →Seven institutions sit behind Vipkurum: egitakademi.com, ozdilakademi.com, mergenkampus.com, edebiyatuzem.com, dekaakademi.com, turkcefm.com and statuakademi.com.tr. Each one is a private education provider, a test-prep center, a distance-learning center or a school, running its own students, its own timetable and its own payment records. The requirement here ran against the grain of packaged software: keep one platform behind the scenes, and let every institution stand in front of it under its own name. That also changes what onboarding means. Bringing another provider in is a definition, not an installation. The question cropping and optical mark tools were built under the same roof.
We go through how the work runs today and what you expect from the software; the scope comes out of that.
We decide what the system is made of and where its information is kept.
We draw the screens and the flow before any code, and start building once you have approved them.
We write and hand over the software so another team could carry it on.
Sign-in happens at the institution's own address, and its student, guardian and payment records stay inside that boundary; they do not surface next door.
Timetables, classes, branches, exams and payments live in one data model; teachers, guardians and administrators reach each record at their own permission level.
Institutions build their own lessons, tests, questions and exams, and define the assessment type themselves, so European and Turkish criteria sit in one infrastructure.
Announcements, messages and notifications move inside one institution; invoices, payments and analytics reports draw only on that institution's own data.
React drives the panel interfaces and a React Native (Expo) app reads the same Laravel application; MySQL and MongoDB hold records, Redis carries the cache.
| Challenge | Result |
|---|---|
| Buy an off-the-shelf panel and the institution ends up wearing the software's brand | Every institution signs in at its own address and appears under its own name |
| No student, guardian or payment record may ever become visible to a neighbouring institution | A record from one institution never surfaces inside another |
| Teachers, students, guardians and administrators all open the same timetable with different rights | One timetable, opened by a teacher, a guardian and an administrator at their own level |
| Assessment rules written into the software cannot hold European and Turkish criteria side by side | Institutions define the assessment type of an exam without waiting on code |
Our own workshop software, built around the car on the ramp. A work order, the parts it consumes and the invoice it produces run as one chain, and the accounting side hangs off that same record. Maintenance history lives on the plate and chassis, so it travels with the car.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
Tell us how the work runs today and we will look at which step could move into software.
