Overview
YiroInc Academia is an education and professional services platform built around two connected experiences: a public-facing website and a custom internal platform. The public site was built with WordPress, giving visitors a place to explore YiroInc's services, resources, articles and store, while keeping content easy for the team to manage. The core platform was built with React and connected to WordPress through a custom REST API, providing role-specific experiences for customers and a central system for the YiroInc team to manage the services and operations behind them.
The Problem
YiroInc Academia’s services were being managed across several disconnected processes. Customer information, service requests, payments and follow-ups were difficult to track in one place, while users had limited ability to manage their own requests or see what was happening after making an enquiry or payment. This created extra manual work for the YiroInc team, slowed down service delivery and made it harder to maintain visibility across customers, orders and ongoing requests.
Approach
I approached the project as two connected experiences: a public-facing website for discovery and content, and a separate application for customers and internal operations. WordPress was kept for the public site because it gave the YiroInc team an easier way to manage pages, articles and store content. The core platform was then built separately with React and connected to WordPress through a custom REST API. This made it possible to keep the public website flexible for content management while giving the portal the structure needed for role-based experiences, service workflows and administrative operations.
Development
Building the Public Website I built the public-facing website with WordPress and Elementor, giving YiroInc Academia a central place to present its academic, exam and corporate services, publish articles and updates, and showcase products through its store. WordPress also gave the YiroInc team control over day-to-day content management, allowing pages and content to be updated without depending on the development of the core platform. Building the Role-Based Portal The core platform was built as a React application with tailored experiences for Academic users, CFA and FRM candidates, and Corporate clients. Instead of building separate applications for each user type, I used the authenticated profile type to control dashboards, navigation, available actions and profile information. CFA and FRM candidates are further distinguished by their exam level or part, allowing the experience to adapt more specifically to them. Building the Custom WordPress API To connect the portal to the backend, I developed a custom REST API within WordPress rather than relying on traditional WordPress pages and templates. The API handles authentication, profiles, resources, products, orders, payments, tutoring, consulting, procurement, notifications and administrative operations. Custom database tables were also introduced for application data that did not fit naturally into WordPress's existing content model. Authentication and Account Management The platform supports email and password authentication alongside Google Sign-In, with authentication tied to each customer's profile type. I also built profile management and account closure into the platform. Closing an account anonymises the customer's personal information while preserving historical records such as previous orders and payments that the business may still need. Building Resources and Paid Access Resources can be published for different audiences, including Academic users, Corporate clients and specific CFA or FRM candidates based on their level or part. For paid resources, I built an entitlement system that separates purchasing a resource from having access to it. Access is granted only after the associated payment has been verified and the order fulfilled. Orders and Payment Processing Since YiroInc Academia accepts bank transfers, I built the ordering process around its existing payment method rather than introducing a separate online payment gateway. Customers can place an order, view bank details and upload proof of payment. Administrators can review the submission, verify it or reject it with a reason. If rejected, the customer can upload a new proof of payment without creating another order. Building the Tutoring Workflow CFA and FRM candidates can request tutoring directly through the portal based on their exam and level or part. Administrators can review requests, assign tutors and reassign them when necessary. Once matched, the candidate receives the tutor's details, while changes to the assignment are reflected in the platform and communicated automatically. Building the Admin Platform Rather than using the standard WordPress dashboard to operate the platform, I built a dedicated administrative interface alongside the customer portal. It provides the YiroInc team with dedicated areas for managing customers, resources, products, orders, payments, tutoring requests, consulting, procurement, notifications and platform settings. Notifications and Transactional Emails I added in-app notifications and transactional emails around important events so customers do not have to repeatedly check the portal for updates. These include payment decisions, order fulfilment, resource availability, tutor assignments and reassignments, password resets and account closure. Transactional emails were kept separate from the CRM system used for broader onboarding and customer communication. Deploying the Platform The public website and core platform are deployed independently. The public site remains on WordPress, while the React application is built with Vite and Nitro and deployed through Cloudflare. The portal communicates with the WordPress backend through the custom REST API, allowing the application to be developed and deployed independently while WordPress continues handling the public website and backend services.
Challenges & Fixes
Integrating Different Systems into a Unified Platform One of the initial challenges I faced was that YiroInc Academia was not being developed on a blank backend. The system needed to integrate with WordPress, WooCommerce, FluentCRM, and a custom REST API, all while maintaining a completely separate frontend. This situation created several boundaries I had to navigate: I needed to determine which tasks WordPress should continue to handle, which elements should live in custom tables and endpoints, and how the React application could interact with these systems without relying on the traditional WordPress frontend. Eventually, we decided to treat WordPress as part of the backend infrastructure while exposing the application's primary workflows through the custom YAC API. Keeping Frontend and Backend in Sync I ran into issues with frontend and backend synchronisation as the API expanded. There were times when the backend supported features that the frontend had not yet added routes or screens for, particularly in areas like tutor requests, consulting, and procurement. As a result, notification action URLs could point to workflows that were not yet available in the frontend. To address this, I had to systematically audit both sides together rather than assuming that a working endpoint meant a feature was fully completed. Ensuring Consistent Role Behavior The role management system also introduced its own set of integration challenges since the Academic, CFA, FRM, and Corporate user experiences shared much of the same application shell. At times, the information specific to a user's role could be accurate in the backend while the frontend displayed behavior as though the user belonged to a different context. For instance, shared interface labels would default to “Academic” instead of adapting to the active profile’s identity. I ultimately made the authenticated profile type the definitive source for role-specific behavior instead of depending on routes or hard-coded labels. Addressing Development and Deployment Issues Even transferring changes between the local project and the WordPress installation presented challenges early in development. I encountered configuration issues with the VS Code SFTP setup while working on the yiroinc-core plugin, which included invalid configurations that hindered the deployment workflow. The final production deployment also brought a separate issue. Cloudflare's GitHub build was stuck before the application even began to build. When we bypassed that process and deployed locally, Nitro generated a Worker name from the Git repository and deployed a second Worker instead of updating "yiroinc-core-frontend." I traced this back to a missing explicit Worker configuration and modified the Worker name, custom domain, and deployment settings in vite.config.ts, which made subsequent builds predictable and consistent.
Outcome
YiroInc Academia is proof that I can take on a complex project from the beginning through to production, while working across product decisions, frontend development, backend logic, integrations and deployment. One of my biggest takeaways was learning to think about features as connected workflows rather than isolated screens. Payments, orders, resources, tutoring and user roles all depended on each other, and the project pushed me to understand how changes in one part of a system affect everything around it. It also strengthened my ability to debug across the full stack. I became more comfortable tracing issues from the interface through the API and database, working through edge cases, and making decisions that supported both the user experience and the operational side of the business. More than anything, the project gave me confidence that I can handle larger, more demanding builds and stay with them from the first idea to a working production system.
Gallery
/