EdAlign

Inspiration

I work as an Educational Technology Coach in an international school, where I see how many different teams and processes are involved in keeping a school running.

Email, forms and spreadsheets all serve useful purposes, and schools have developed many effective ways of using them. However, individual processes are often created at different times and for different teams. This can mean staff need to move between several places to submit something, follow its progress or understand what needs to happen next.

I began by creating smaller tools with Google Apps Script to support individual processes. Staff appreciated having clearer forms, structured tracking and automation. These tools reduced repeated administration, saved time and made it easier for everyone involved to see the progress of a request.

I later shared some of these approaches with educational technology staff and teachers at an international school conference. The conversations that followed showed me that people in other schools were working through many of the same challenges. A number of them asked how similar approaches could be introduced in their own settings, which helped me realise that the opportunity was wider than my own experience.

Each tool worked well for its particular purpose, but it still supported only one process. I began to think about what might be possible if those processes could be connected and staff could have a more consistent experience.

That is where the idea for EdAlign came from: one platform that builds on familiar school processes while helping different teams, requests and approvals work together.

EdAlign is my independent project. It was not commissioned by or created specifically for my school. My experience working in education helped me recognise an opportunity that could be useful to many educational organisations.

What EdAlign does

EdAlign brings the everyday operational work of a school into one connected place.

It currently includes modules for IT support, facilities, purchase requests, professional development, asset management, and events and trips. Staff have one clear place to begin, regardless of which team or process they need.

What matters to me is not simply putting several forms on the same website. Different parts of a school often need to work together, so EdAlign allows related records to stay connected.

For example, when classroom equipment develops a fault, an IT request can lead to a connected purchase request for a replacement. That purchase can then be linked to the relevant asset. The original issue, purchasing decision and equipment record remain part of the same story.

Connections can also reduce repetitive administration for teachers. Once a professional development request has been approved, a teacher can begin a connected purchase request with relevant information already filled in. They can check the details and submit it without completing another form from the beginning.

These actions may save only a few minutes each time, but across many staff members and requests, that time adds up. My aim is to help teachers spend less time repeating information, looking for the next step or requesting separate updates.

Staff can submit and follow their requests, while support teams and approvers receive organised queues, assignments, comments, attachments, status updates and activity histories.

Schools can configure each module around their own teams, approvers, permissions, request types and form options. They can activate the modules that are useful to them without changing the experience for staff each time.

EdAlign takes a school-specific approach, using language, roles and processes that feel familiar to people working in education. It is intended to complement the ways schools already work while providing a clearer connection between teams and processes.

How I built it

The earlier Google Apps Script tools helped me understand the opportunity, but EdAlign was designed and built separately as a new platform.

It uses Next.js, React, TypeScript and Firebase. Firebase provides sign-in and stores the organisations, users, modules, requests, permissions, comments, attachments and activity behind the platform.

My professional background is in education rather than software development. I began with an understanding of school processes and a clear idea of what I thought would make sense to the people using them.

I used Codex as my development partner. It helped me understand the code, plan changes, build features, investigate problems and test how a change in one place could affect other parts of the platform.

I remained responsible for the product decisions. I decided what information staff need, how each workflow should behave, which options are genuinely useful and whether the wording would feel natural in a school.

Codex gave me the technical support to turn those decisions into a working application, but I still needed to review the results carefully and decide whether they were right for EdAlign.

OpenAI Build Week

EdAlign existed before OpenAI Build Week, and I want to be clear about that.

During Build Week, I used Codex with GPT-5.6 to make a significant extension to the platform. The largest addition was the development of a sixth module for Events & Trips.

The module covers school events, off-site trips, residential trips and staff events. It includes planning and logistics information, costs, approval stages, comments, attachments and activity history.

I also created a seven-step setup process so administrators can configure the module gradually and return to it later. The module connects with EdAlign’s existing permissions, dashboards, users, exports and navigation instead of behaving like a separate application.

Another important part of my Build Week work was improving connections between modules. Related IT, Facilities, Purchase, Professional Development, Asset, and Events & Trips records can now remain connected while still respecting what each user is allowed to access.

I also worked on making IT and Facilities more consistent, improving support-team access, correcting dashboard and My Requests counts, rebuilding the public homepage, and improving accessibility and consistency across the interface.

I used Codex with GPT-5.6 most heavily while developing Events & Trips. GPT-5.6 helped me compare the new work with patterns in the existing modules and think through decisions involving setup, permissions and connected workflows. Codex helped me investigate the code, implement those decisions and test how the different parts worked together.

At the end of Build Week, I also used Codex to create the completely fictional environment shown in the demonstration. It includes configured modules, example requests, assets, comments, attachments and connections. EdAlign is not yet running with real school data, and outgoing notifications are disabled in the demo.

Challenges

The main challenge was adding a new module to an existing platform without making it feel like a separate product.

Codex could create a working page or feature, but that did not automatically mean it would follow the same patterns as the rest of EdAlign. Events & Trips needed its own information and workflows, while still feeling familiar to someone who had already used another module.

I approached this by asking Codex to first examine how the established modules worked. We created the core of Events & Trips and then worked through it section by section, comparing its forms, settings, navigation, permissions and request pages with the rest of the platform.

This helped me identify places where something worked technically but did not yet feel consistent. It also revealed some older areas where similar features had developed in slightly different ways.

The setup process was another challenge. Schools need flexibility because their teams and approval processes vary, but too many choices at once can become difficult to manage. I had to decide what schools genuinely need to configure, what could have a sensible default and how to divide the setup into clear steps.

Permissions also needed careful thought. A requester, reviewer, additional approver and administrator should not all see or be able to do the same things. Codex helped me trace those roles through the pages, data and Firebase security rules, while I decided how those responsibilities should work in a school context.

Testing the wider effect of each change was just as important. Something could work correctly on one page but affect a dashboard, another user role or a connected module. Codex helped me test those relationships instead of looking at every screen in isolation.

The process reminded me that a feature being technically possible does not necessarily mean it will be useful or understandable. I still needed to make the final judgement about what belonged in EdAlign and how it should work.

What I learned

Building EdAlign has shown me that understanding a setting and the people within it can be just as important as having a traditional technical background.

Codex helped me develop the technical understanding needed to turn my ideas into something that works. It allowed me to investigate and improve areas that I would not previously have known how to approach.

I also learned that working with AI requires patience, clear instructions and careful checking. The best results did not come from asking Codex to build everything in one go. They came from working through the platform in smaller sections, reviewing the result and correcting anything that did not make sense.

Codex could help me understand and implement possible solutions, but I remained responsible for deciding whether those solutions were safe, clear and genuinely useful to schools.

Most importantly, I learned that my experience in education has an important role in the development process. I may not always know the technical name for something, but I understand the people, decisions and everyday situations the product is intended to support.

What’s next

The six modules in EdAlign are only the beginning.

Schools manage a wide range of operational processes, and the same EdAlign foundation could support additional workflows over time. Rather than deciding those in advance, I want future modules to be shaped by conversations and pilots with school teams, focusing on where a more connected approach would be genuinely useful.

Because the modules share the same users, permissions, approvals, activity histories and connections, future workflows can become part of the same platform while still retaining what makes each process different.

My next step is to continue refining EdAlign before beginning small, carefully selected pilots with school teams. I want to learn whether it genuinely saves staff time, reduces the need for follow-up, improves response times and gives people clearer visibility over their requests.

I do not want to add modules simply to make EdAlign look larger. Future development will be guided by what schools find genuinely useful and where a more connected process could save staff the most time.

This is only the beginning. My long-term aim is to give schools one calm, connected place for managing the internal work that keeps them running.

Built With

• authentication
• cloud
• codex
• css3
• firebase
• firestore
• gpt-5.6
• html5
• javascript
• next.js
• node.js
• nodemailer
• openai
• react
• smtp
• tailwind-css
• typescript