We build student information systems that bring admissions, enrolment, class placement, timetabling, attendance registers, marks, report cards, parent communication and instalment tracking together on a single record. It is designed around your institution's own calendar and your own fee policy; you do not have to fit into the mould of an off-the-shelf package. The source code and the data belong to the institution.
In an educational institution, student information never sits in one place. The enrolment form lives in a folder, the instalment plan in an Excel file in accounts, absences in the class register, parent communication in WhatsApp groups, and the timetable in a spreadsheet on the deputy head's computer. Each of these works on its own; the problem appears when they have to be brought together. When a parent rings to ask how many days their child has been absent, three separate places have to be checked. The list of students with overdue payments is compiled by hand in the middle of the month and is usually incomplete. At the end of term, marks for report cards and progress reports are collected teacher by teacher. None of these jobs is difficult on its own; but when they all fall in the same week, the administrative team spends weeks doing nothing but assembling data.
Two mistaken expectations make this harder. The first is expecting a system that will replace the official record. In institutions under the Ministry of National Education, a student's official registration, marks and absences run through e-Okul, the ministry's national school records system, and stay there; we do not build a system that replaces e-Okul, and we do not claim that we will. The second is the assumption that off-the-shelf school packages fit every institution. The term structure of a course centre and the year-group structure of a private college, the parent communication of a nursery and the guidance process of a secondary school are nothing alike. An off-the-shelf package tries to force them into a single mould, and the institution ends up adapting its own way of working to the software. That is precisely the case for custom development: your own calendar, your own fee policy, your own reports.
A student information system, SIS for short or OBS as it is commonly called in Türkiye, is the administrative backbone of the institution. It holds the whole of a student's relationship with the institution on a single record: from application to enrolment, from class placement to the timetable, from the attendance register to marks and report cards, from the fee plan to collection. It is important to separate this from a learning management system. The LMS is where content lives: lesson materials, homework, online exams and progress tracking are there. The SIS knows who is a student, which class they are in, how many days they have been absent and where their balance stands. The two systems do not replace one another; the right design is to hold student and class information in the SIS and pass it across to the LMS.
We do not start the roll-out in a single move, but at the point where the institution is losing the most. In most institutions that is either collection tracking or parent communication. The parent portal is the most visible part of the job: when absences, marks, announcements, payments and meeting requests all run from one place, the scattered message traffic in groups largely ends and every notification is recorded. Student data is also children's data; who can see which information, how long data is retained and what happens to a graduating student's record are defined from the outset. The source code and the data belong to the institution; if you later want to continue with another team, you are left with a working system and its documentation.
Institutions running several stages, from nursery through to secondary school, under one roof. Transitions between stages, sibling discounts, ancillary services such as transport and catering, and a different report card structure for each stage are where off-the-shelf packages struggle most. In these institutions, most of the administrative load is concentrated in the re-enrolment period.
Institutions without fixed terms, where a student may start on any date during the year. Group occupancy, catch-up lessons, level progression and a mixed upfront-and-instalment payment structure are the real problem here. Holding class numbers and teacher timetables together also makes unfilled places visible.
Institutions where parents expect information during the day. Keeping records such as arrival and departure times, naps, meals and daily development notes in order and passing them to the parent through a single channel both reduces the communication load and prevents the misunderstandings that come from passing things on verbally.
Organisations running several locations under the same brand. Branches manage their own students and collections while head office needs a consolidated view. Branch-level permission separation, a shared fee policy and comparative occupancy reporting are usually the first reason these organisations start a roll-out.
Every step, from the initial enquiry form through to the contract, runs in a single flow. The prospective student pool, meeting notes, enrolment paperwork and missing-document tracking are gathered on the same record. Automatic lists and reminders are produced for the re-enrolment period; who has renewed, who is undecided and who has left becomes visible as a number.
Students are placed into classes according to stage, level and capacity. When the timetable is prepared, teacher clashes, room availability and weekly teaching load are checked. When the timetable changes, the affected teachers, classes and parents are informed automatically; who made the change is recorded.
The register is taken in the classroom on a tablet or a phone; lateness, authorised absence and medically certified absence are distinguished. When absences pass a defined threshold, an alert goes to the parent and to the guidance team. Termly absence reports are produced at the press of a button, so there is no retrospective trawl through registers at the end of the year.
The exam calendar, mark entry and the weighted average calculation are configured according to the institution's own regulations. Each teacher enters the marks for their own subject, and report cards and progress reports are produced from the same data. Written comment fields can be tied to templates, so end-of-term report writing takes minutes rather than hours.
Parents see absences, marks, announcements, payment status and meeting requests in one place. Notifications go out through the app, SMS and email, and who saw what and when is recorded. Teacher-parent meetings are tied to appointments; promises made verbally turn into a written record.
Per-student fee plans, sibling and early-enrolment discounts, bursary rates and instalment schedules are defined. Overdue payments are listed automatically and reminders are sent. Online collection and a virtual POS can be connected; an export or an integration is built to feed your accounting package, so data is no longer entered a second time.
Bus routes and student assignments, meal preferences and allergy notes, club and activity records are all attached to the same student card. These records are linked both to charging and to parent communication; the problem of information held in separate lists failing to match disappears.
Stages, the term calendar, the fee policy, the report card structure and the way you communicate with parents are mapped on site. Which task actually eats the time is identified together with the administrative team. This step usually takes two to four weeks, and it is here that the scope is settled.
Excel files and, where they exist, records from the old system are migrated. Duplicate student records, missing parent details and inconsistent fee plans are weeded out at this stage. Migrations carried out with dirty data always produce mistrust from the first month onwards, which is why the clean-up is not skipped.
Enrolment, class placement, timetabling and attendance go live. We start with a single stage or a single class. Entry screens for teachers are kept simple; an attendance screen nobody uses gives exactly the same result as an attendance screen that does not exist.
Mark, absence and announcement notifications are opened up to parents, and fee plans and online collection are connected. During the pilot the old method runs in parallel for a while. Notification frequency and content are adjusted according to the first feedback from parents.
Wherever possible the switch is timed to the start of a term or half-year; switches made mid-year double the administrative load. The system is handed over to your team and frequent tasks are written down. After that, updates and improvements continue under maintenance and support.
No, and we do not promise it. e-Okul, the Ministry of National Education's national school records system, is a closed system and does not offer institutions an open, general-purpose integration interface. Official marks, absences and registration continue to be entered in e-Okul. What we do is put the internal way of working in order and make sure the data to be entered into e-Okul comes out accurate, tidy and in ready-made lists. This does not end double entry completely, but it reduces it considerably.
They do different jobs. A student information system manages enrolment and administration: who is a student, which class they are in, how many days they have been absent, where their balance stands. An LMS manages learning itself: lesson content, homework, online exams, progress. In practice most institutions need the SIS first, because the administrative chaos is the more pressing problem. If the two are to be used together, student and class information is held in the SIS and passed across to the LMS; managing the same list in two places is not sustainable.
Yes, and we do not recommend changing your accounting package. Collection and invoice information is passed across by API, by file transfer or through e-Fatura (Turkish e-invoicing) integration, depending on the method your package supports. Student- and parent-level detail stays on our side, the financial record stays on the accounting side. Which method is possible becomes clear once the version of the package and its integration support have been examined; we do not give a firm commitment before discovery.
Not every parent will download an app, and that has to be accepted from the start. That is why we do not tie the portal to a mobile app alone: the same information opens on the web and through a link sent by SMS. What increases use is not the number of features but having the three or four things a parent genuinely wants to know on the first screen. We watch usage rates during the first term and, if they stay low, simplify the notification flow and its content accordingly.
Student data is children's data and is handled with more care. With role-based access control, a teacher sees only their own class and the guidance team only its own remit. Access to fields such as photographs, health notes and contact details is restricted separately. The records keep who viewed what and when, and the retention period and the fate of graduated students' records are defined from the outset. Privacy notices and consent processes are prepared with the institution's own legal advisers, and the system is made to fit them.
A single student record running from application to enrolment and re-enrolment; class placement and a timetable with clash checking; mobile attendance registers and absence reports; production of marks, report cards and progress reports; a parent portal with a notification and meeting log; fee plans, instalment tracking and collection lists. The source code, the database and the deployment documentation belong to the institution; you are not locked into any tool, or into us.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We build laboratory information management systems that run every step on a single record, from the moment a sample is received through to the certificate of analysis: barcoded sample tracking, a method library, instrument connections, specification checks, staged approval and an audit-ready record structure.
Details →We bring the chain of quote, project, time record, milestone claim and invoice together on a single record. In agencies, consultancies, engineering practices and software firms, who spent how long on which job, resource utilisation and project profitability become visible while the work is still running, not once it has finished.
Details →We do not replace your hospital information management system; we build an operations layer that runs alongside it. Appointments and resource utilisation, treatment plan tracking, reminders, consumable and implant stock, the patient journey in health tourism and the management dashboard all come together in this layer. The source code and the data stay with you.
Details →We take the company's paperwork out of folders and personal computers and move it into a single archive. Every document's version, who may see it, which approval it passed through and how long it will be kept are defined in the system; the document you are looking for is found in seconds rather than minutes, and its history can be evidenced in an audit. A DMS manages the document itself; ECM covers the process and the content that flow with it.
Details →We build a system that produces a contract from a template, puts it through approval and signature, and — once it is signed — tracks effectivity, renewal, the notice period for termination and the parties' commitments. Contract lifecycle management (CLM) is exactly that: not storing a file, but managing the contract's lifetime. A contract whose term has run out does not quietly extend itself because nobody noticed.
Details →We build an arrangement in which faults and requests arrive through a single record rather than through a messaging app, a corridor conversation or a phone call. Every request is prioritised, has a clear owner and a measured resolution time. We run the same structure not only in IT but also for human resources, administrative affairs and maintenance requests. That is what enterprise service management (ESM) means.
Details →
