Preschool Communication Platform

When daily communication between a preschool and parents is spread across different channels, keeping track of information becomes increasingly difficult. Meal plans, weekly schedules, activities, announcements and actions expected from parents can easily be overlooked when they are shared through message groups or different communication methods. On the preschool side, tracking which parents have seen an announcement or completed a required action becomes an additional operational burden. Information related to a child's daily life needs to be available from a single, simple and reliable place.

This project emerged directly from a need I observed in everyday life. As the parent of a child attending preschool, I see how quickly it can become difficult to keep track of weekly schedules, meal plans, activities, announcements and occasional actions expected from parents when they are distributed across different messages. The goal is not to build another messaging application, but to create a simple product that makes the flow of information between preschool and parent more structured, traceable and action-oriented. I also want the initial validation to come from real usage rather than assumptions.

Because the system works with information related to children and parents, data security and privacy are fundamental design constraints. From a privacy and KVKK perspective, unnecessary data should not be collected, users should only be able to access the children and class information they are authorized to see, and sensitive content should not be stored without a clear need. The scope of the first version is deliberately limited: instead of digitizing every school operation, the goal is a small MVP focused on solving the daily communication problem. Mobile usage needs to be fast and understandable, parents should be able to reach relevant information within a few steps, and preschool staff should be able to use the system without creating additional operational overhead.

Give parents a single place to access daily and weekly information related to their child. Make weekly activities, meal plans and schedules easy to follow. Prevent important announcements from getting lost in message traffic. When necessary, track whether a parent has seen a piece of information. Clearly show actions expected from parents and track their completion status. Keep content publishing as simple as possible for preschool staff. In the first phase, validate the product through approximately 30 days of real usage with a single class, then expand the scope based on actual needs.

The product is being designed as a mobile experience that prioritizes the information parents need in their daily routines. The main experience highlights the schedules, activities, meals and announcements that matter for the current day or week. Content created by the preschool is associated with the relevant class or users so that it is shown only to the right people. Informational content is separated from content that requires an action from the parent, allowing users to distinguish what they need to do instead of seeing only a stream of information. Read status and action status provide feedback to the preschool and aim to reduce manual follow-up such as asking whether everyone has seen a message. The core product flows and scope are already defined, and development is actively continuing.

The mobile client is being developed with React Native. The system is built around a data model that separates concepts such as users, children, classes, content and actions. Content types such as activities, meal plans, schedules and announcements are intended to share a common publishing model while remaining customizable for their specific needs. Authorization will be enforced not only in the application screens but also at the service layer; preventing a parent from accessing data belonging to another child or class is one of the fundamental security rules. The backend is positioned as an API layer independent of the mobile client. The architecture is designed to avoid unnecessary service and infrastructure complexity during the initial pilot while still allowing expansion to additional classes and institutions later.

I defined the product idea, scope and core user problem based on my own experience. Alongside product management and technical leadership, I am responsible for the architectural decisions, data model and development process. Deciding which capabilities belong in the first MVP and which should be postponed is particularly important to me; the objective is not to maximize the number of features, but to create a small and understandable product that people actually use. During development, I use AI-assisted development tools as part of the engineering process while keeping architectural, product, security and quality decisions under my own control.

Mobile: React Native / TypeScript

Backend: API-based service architecture

Identity and access: Authorization based on roles and user context

Data model: Relationships between institution, class, child, parent, content and actions

Content: Weekly activities, meal plans, schedules and announcement models

Tracking: Read status and user actions

Security: Minimum data collection, access restrictions and a KVKK-focused data approach

Development: AI-assisted development with a controlled code review and checkpoint process

Focus the first version on the everyday needs of preschool–parent communication instead of building a comprehensive school management system. Limit the MVP to activities, meal plans, schedules, announcements, read status and required actions. Validate the first version with a single class and a 30-day pilot rather than a large user base. Avoid collecting child and parent data simply because it may be useful later; store only what is necessary for the product to work. Build the mobile client with React Native to maintain a single codebase. Keep file and photo features, which would increase both scope and data-security requirements, outside the first phase. Avoid unnecessary scale and infrastructure complexity until real product usage demonstrates a need for it.

One of the main challenges is building the correct authorization model behind a user experience that should feel extremely simple. A parent must only be able to access information associated with their own child and class, while permissions for preschool staff need to be limited according to their responsibilities. The presence of children's data increases the importance of even small development mistakes. Another challenge is protecting the MVP boundary against the temptation to add features too quickly. Messaging, photo sharing, payments, attendance and development tracking could all be added, but including them in the first version would make it harder to validate the core problem. Keeping content entry simple for preschool staff without turning the parent's screen into information overload is another important product-design balance.

The project is under active development, and a significant part of the core product scope has already been defined. User roles, core data relationships, weekly activities, meal plans, schedules, announcements, read status and the action model form the foundation of the MVP. React Native was selected for the mobile application, and the boundaries of the first version have been established. The next major goal is to make the core flows work end to end and prepare the product for approximately 30 days of real-world use with a single class. After the pilot, decisions about additional features will be based on actual usage and feedback rather than assumptions.

Solving a small problem that emerges from everyday life depends more on defining the right scope than on the number of features. Although dozens of capabilities could be added to a preschool application, the product's initial value comes from a few fundamental flows: making sure the right information reaches the right parent at the right time and ensuring that required actions are not lost. When children's data is involved, security and privacy cannot be technical features added later; they need to shape the data model from the beginning. Validating the product through real usage with a small group is more valuable than building a large system based on assumptions. The core approach is therefore to create a small, reliable product first and expand it in a controlled way as real needs emerge.