MourkTherapy

A practical platform for Greek therapy and special-education centers, combining daily operations with official EOPYY certificates and secure subscription onboarding.

Comment

Inspiration

MourkTherapy started from a place that became very important to me.

For about seven months, I worked in an occupational-therapy and special-education center. I saw how much care the therapists and staff gave to children and families, but I also saw how much time disappeared into administrative work. Appointments changed constantly, payments had to be checked, documents had to be prepared, and the same information was often written more than once.

Many of these processes were spread across paper notes, Excel files, messages, and separate tools. The people were doing their best. The problem was that they did not have one system designed around the way a therapy center actually works.

That experience stayed with me. I wanted to create something that could help not only one center, but other small therapy and special-education centers facing the same problems. I also wanted it to be affordable, because a useful system should not be available only to large organizations with large budgets.

So I started building MourkTherapy independently from home, using what I had learned from real daily work. MourkTherapy is part of Mourk, my independent software project. It is not owned by the center where I worked, but that experience gave me the reason to begin.

What MourkTherapy does

MourkTherapy brings the daily operation of a therapy or special-education center into one connected application.

It is not one dashboard shared by everyone. Administrators, secretaries, therapists, and clients have different needs, so each role has its own focused experience. An administrator can organize the whole center, a therapist can see their schedule, assigned clients, and earnings, and a client can follow appointments, documents, and their balance.

The platform includes:

  • appointment and calendar management;
  • clients, therapists, specialties, assignments, and invitations;
  • general prices, client-specific prices, discount rules, and therapist payouts;
  • payments, balances, receipts, and operational statistics;
  • diagnosis PDFs and supporting client files;
  • OCR assistance for extracting structured information from diagnosis documents;
  • administrator review before preparing certificates;
  • EOPYY-related certificate and monthly-document workflows;
  • subscription management and secure therapy-center onboarding.

The goal is not to replace people or remove human control. It is to reduce repeated work, make important information easier to find, and give the team more time to focus on therapy and the people they support.

What existed before Build Week

MourkTherapy existed before OpenAI Build Week.

Before the submission period, I had already built the main React and Firebase application, the role-based areas, appointment and member management, financial workflows, document handling, and the core therapy-center environment.

I do not want to present the entire product as something created during one week. This submission focuses on the extensions completed during the official Build Week period, supported by dated commits and Codex sessions.

What I added during Build Week

During Build Week, I used Codex with GPT-5.6 to extend and strengthen the existing product.

The biggest visible change was a complete redesign of the public MourkTherapy experience. I wanted a visitor to understand the product without reading long or generic marketing text. I rewrote the Greek content, simplified the page, explained the different roles more clearly, and created a more direct path from discovering the product to choosing a plan and opening a therapy center.

That redesign also uncovered technical problems deeper in the journey. A selected plan needed to survive login, registration, email verification, browser navigation, and checkout. A successful Stripe return needed to belong to the correct account. Center creation also had to remain safe if a request was interrupted or subscription information arrived later than expected.

The Build Week work therefore included:

  • preserving plan selection through authentication;
  • validating Stripe checkout return states;
  • protecting actions when the signed-in account changes;
  • verifying subscription access before center creation;
  • attaching subscriptions to centers safely;
  • recovering after interrupted center creation;
  • preventing duplicate or stale actions;
  • improving keyboard, modal, mobile, and accessibility behavior;
  • expanding automated tests for edge cases and regressions;
  • improving EOPYY certificate saving and presentation.

How I built it

MourkTherapy is built with React and Firebase. It uses Firebase Authentication, Firestore, Cloud Functions, Stripe, and supporting frontend and backend utilities.

Because the application is connected from end to end, I could not review each change in isolation. I repeatedly checked the complete journey: the public page, authentication, billing, center creation, user roles, appointments, finances, and documents.

How I used Codex and GPT-5.6

I used Codex with GPT-5.6 as an engineering partner throughout the work, not as a one-time code generator.

I brought the product idea, the knowledge from working inside a real center, the Greek wording, and the decisions about how each role should work. Codex helped me understand and move through the existing codebase, turn requirements into smaller tasks, implement changes, investigate difficult edge cases, and test the result.

In particular, Codex helped me:

  • work across the existing React, Firebase, Firestore, and Cloud Functions architecture;
  • implement frontend and backend changes;
  • investigate authentication, Stripe, and account-state edge cases;
  • create and expand automated tests;
  • review responsive and accessibility behavior;
  • perform security, dependency, and regression checks;
  • organize the work into a clear and reviewable history.

I also used ChatGPT to think through product direction, improve the public story, organize the submission, and prepare clearer prompts for Codex. AI made the process faster, but it did not decide what MourkTherapy should be. I reviewed the work and kept, changed, or rejected suggestions based on the real workflows I wanted the product to support.

Challenges

The hardest part was that MourkTherapy was already a large and connected application. A small change could affect authentication, billing, browser navigation, center access, or another user role.

For example, improving the landing page sounded like a visual task at first. In practice, it required checking the complete path from selecting a plan to signing in, paying, and safely creating a center.

Language was another challenge. English is not my first language, and the product itself is mainly for Greek professionals. I wanted the Greek interface to feel natural and respectful, not like generic marketing text or an automatic translation. I reviewed that wording myself because it represents the people and centers I want to support.

What I learned

This is my first hackathon, and it taught me that using AI well is not about asking for a complete product in one prompt. The most useful part was moving repeatedly between a real problem, a product decision, implementation, visual review, testing, and another round of improvement.

I also learned that my experience inside the center was valuable. The small details I observed—how appointments change, how payments are followed, how documents are checked, and how different roles need different information—became the foundation of the product.

MourkTherapy began because I saw good people losing time to fragmented processes. I want to turn that experience into a practical and affordable tool that can help more centers stay organized without losing the human side of their work.

What's next

My next goal is to keep validating MourkTherapy with realistic center workflows, improve onboarding and accessibility, and make the most repetitive tasks simpler.

I also want to listen to more therapists, administrators, and small center owners. My aim is to grow the product carefully while keeping the price approachable, so that a small center can realistically use it—not just admire it from a distance.

Built With

Share this project:

Updates