Project Progress: Building the Christmas Market Platform With AI and Code Agents

Introduction

#

In my previous post, I described the starting point of our christmas market project for E.G. At that stage, the project was mostly about understanding the case, identifying the manual parts of the workflow, and thinking through what a useful MVP could look like.

Since then, the project has moved from planning into implementation.

We now have a clearer idea of what should be prioritized, what can wait, and what is already working. The project is no longer only a concept about forms, emails, and visitor information. It has become a working application with a frontend, a backend, saved applications, email handling, AI-based categorization, and a public standholder list prototype.

This post is a continuation of the earlier one. Instead of focusing on the idea phase, I want to describe how far I have gotten, what changed in the scope, and what I have learned from building it, especially while using a coding agent as part of the process.

What Changed Since the Planning Phase

#

In the first post, I described the solution as three connected parts:

• A digital standholder application flow
• Email automation
• A simple live map

That is still the overall vision, but in practice our priorities became more specific as the project developed.

Right now, my own focus is mainly on:

• Making the standholder form fully work
• Using AI on the public stadeholderliste
• Building automated emails to last year’s standholders

At the same time, another member of my group is working on the dashboard. That means I do not need to build the internal review interface alone, and it also means I can focus more on the data flow and the public-facing parts.

The live map is still a good idea, but it is no longer a must-have for the first strong version of the project. We still see value in it, but for now it makes more sense to make the existing flow solid before adding another large feature.

This is one of the most useful lessons from the project so far: the scope has to stay flexible, but the priorities have to become sharper.

What Has Been Implemented So Far

#

So far, I have worked on turning the standholder flow into something that actually functions, not just something that looks good in a mockup.

A frontend that resembles the real site

#

I built the frontend in React and tried to make it feel closer to the real Christmas market pages for E.G. Instead of creating a completely separate-looking prototype, I wanted the application to feel like a believable continuation of the existing site.

The frontend currently includes separate pages for:

• Julemarked
• Årets program
• For stadeholdere
• Stadeholderliste

That structure was important because the project should not only demonstrate technical features. It should also communicate how the solution could fit into a real website context.

A working digital standholder form

#

The standholder form is now one of the most important working parts of the project.

Instead of the old process where a company first needs to ask for a form by email, the application now allows a standholder to submit relevant information directly.

The form includes fields such as:

• Company name
• Contact person
• Email and phone number
• Product description
• Preferred placement
• Previous participation
• Need for electricity
• Links and practical notes

This means the data is structured from the start instead of being scattered across email threads.

A backend that actually saves applications

#

The project now has a backend that receives the form submission, validates it, and saves it.

This was a major step, because it changed the form from a visual interface into a real intake system.

At the moment, the backend can:

• Validate form data
• Save applications as structured JSON
• Keep application status metadata
• Detect duplicate submissions
• Return useful responses to the frontend

This gives the system a proper foundation for later admin handling and public reuse.

Email sending through SMTP / SendGrid-compatible setup

#

The submission flow also attempts to send the application as an email.

In practice, this means that when the form is submitted, the application is not only stored but also forwarded through an email pipeline. I tested this locally and confirmed that:

• the application was submitted
• the application was saved
• the email was received

That was an important moment in the project, because it made the workflow feel much more real. It was no longer only a simulated process.

AI-supported categorization

#

Another part I have implemented is AI-supported categorization of standholders.

This matters because one of the practical problems in the case is that companies are not always easy to place in rigid predefined categories. Some are easy to classify, but many are more mixed or unusual. If everything is hardcoded too early, the result becomes inflexible.

The system can now try to categorize a submitted company into a broader public-facing category and assign tags. If the AI is unavailable, the backend can fall back to simpler heuristic rules.

The important point here is that AI is being used to support messy real-world data, not to replace human judgment.

A public standholder list using real data from last year

#

To make the public side of the project more realistic, I seeded the application with last year’s real standholder list and used that as demo data.

That made it possible to build a public stadeholderliste page where a visitor can:

• Search
• Filter by category
• Filter by location
• Filter by tags

This is useful because it demonstrates how the future value of the project could work for visitors, even before this year’s approved companies are fully flowing through the whole system.

It also creates a connection between the current manual website content and the new digital structure.

A Change in Technical Direction

#

In the earlier post, I considered a possible stack with React on the frontend and Java/Javalin on the backend.

In practice, the version I have worked on so far uses:

• React on the frontend
• Express on the backend
• JSON-based persistence for the current phase
• SMTP-compatible email handling
• OpenAI integration for categorization

This is not unusual in a project. Early planning often includes one technical direction, but actual implementation can shift when the team better understands the scope, time constraints, and what is realistic to build well.

For me, this has been a useful reminder that planning should guide implementation, but not trap it.

How I Have Worked With Codex

#

One thing that has been especially interesting in this project is my workflow with Codex.

Our teachers are encouraging the use of coding agents, and this project has given me a concrete opportunity to use one as part of a real development process instead of only experimenting with small isolated prompts.

I have not used Codex as a “build everything for me” tool. Instead, I have used it more as a development partner.

The workflow has often looked something like this:

1. I describe the current goal in natural language
2. Codex inspects the codebase and current files
3. It proposes or implements concrete changes
4. I test the result locally
5. I report back what worked or failed
6. Codex adjusts the implementation based on the real feedback

This has been especially useful when the project contains several connected parts, for example:

• updating the frontend while preserving the structure of the real website
• adding backend endpoints
• wiring form submission to storage and email
• creating seeded data for the standholder list
• refining categorization logic when the first result was not good enough

A good example was the stadeholderliste. The first pass of categorization worked technically, but the actual results were not always very convincing. Because of that, the workflow became iterative:

• build the endpoint
• test real output
• inspect the classification results
• improve the logic
• decide where curation made more sense than pure heuristics

That kind of loop is where a coding agent becomes useful. It is not only about writing code faster, but about helping move through implementation and revision more quickly.

What I Have Learned From Using a Coding Agent

#

Using Codex in this project has taught me a few things.

The better the context, the better the output

#

When I gave vague instructions, the output was also more generic.

When I gave better context, such as:

• what the real site should resemble
• what parts of the project are already implemented
• what is intentionally deferred
• what my teammate is handling
• which feature is currently highest priority

the results became much more useful.

This matches something I have noticed more generally: coding agents work best when they are guided with enough structure to understand not just what should be built, but why.

Testing still matters

#

Even when the code generation is helpful, local testing is still essential.

There were several times where something looked correct in the code, but only became clearly wrong after testing:

• route behavior
• background server state
• list categorization quality
• wording in the UI
• whether form submission actually saved and sent

That means the coding agent speeds up implementation, but it does not remove the need for verification.

It works well for iteration

#

One of the biggest strengths of the workflow was iteration.

I could build something, inspect it, adjust the goal, and continue. This was especially helpful because the project scope was evolving. Some features became more important, while others were pushed later.

Codex made it easier to keep moving instead of getting stuck between planning and implementation.

What I Still Want to Build

#

Even though the project has come a long way from the original idea post, there is still more to do.

My next priorities are still:

1. Finish the standholder form flow as cleanly as possible
2. Continue developing the AI-supported standholder list
3. Build automated outreach emails to last year’s standholders

The dashboard will continue in parallel through my teammate’s work, and the live map can still be considered later if there is enough time.

That feels like a much more realistic and focused direction than trying to build every planned feature at once.

Reflection

#

Looking back, I think the project has developed in a productive way.

The first post was about defining the problem and imagining a full platform. This post is more about learning what happens when that idea meets actual implementation constraints.

Some ideas stayed exactly as planned:

• the importance of structured standholder data
• the usefulness of AI for categories and summaries
• the value of reducing repetitive email work

Other things changed:

• the live map became less important for the current phase
• the technical stack shifted
• the immediate focus became narrower and more practical

That is probably a healthy sign in a real project. It suggests that the implementation is being guided by actual value and feasibility, not only by initial enthusiasm.

Conclusion

#

This project has now moved beyond the concept stage.

At this point, I have a working frontend, a functioning standholder form, backend persistence, email handling, AI-supported categorization, and a public standholder list prototype based on real data from last year’s christmas market.

Just as importantly, I have also gained practical experience in working with a coding agent as part of a real project workflow. Since our teachers are encouraging the use of coding agents, this project has been a good example of how they can support development in a meaningful way.

For me, the most useful takeaway is that a coding agent is strongest when it is part of an iterative process: plan, implement, test, revise, and repeat.

That is exactly the kind of workflow this project has required so far, and it is likely the same workflow I will continue using as the system moves closer to a stronger final version.