Implementing the Engestofte Gods Solution #
After identifying the workflow and communication issues at Engestofte Gods, the next step was designing a technical solution that could realistically support automation, scalability, and centralized data management.
This post focuses less on the business problem itself and more on the implementation choices we made during development.
Why We Chose React #
For the frontend, we chose React because we wanted a component-based architecture that would scale well as the project grew.
The project contains multiple dynamic UI elements:
- customer forms
- booking overviews
- event dashboards
- filtering
- reusable input components
React made it possible to structure these features into reusable components instead of building everything as isolated pages.
Another advantage was state management.
Because customer data flows through several parts of the system, React allowed us to keep the UI responsive while handling form state and conditional rendering efficiently.
We were also already familiar with React from previous projects, which made development significantly faster. Since we already understood the framework and ecosystem well, we could spend more time focusing on workflow architecture and problem-solving instead of learning a new technology stack from scratch.
Backend Architecture #
We decided to use Node.js with Express for the backend.
The main reason was flexibility and speed of development.
Since the project revolves around handling requests, customer data, and automation logic, Express gave us a lightweight way to build APIs without unnecessary complexity.
The backend was structured around:
- route handling
- controllers
- service logic
- database communication
This separation made the project easier to maintain and extend.
For example:
- customer creation
- booking management
- automated workflows
- email generation
could all be isolated into their own modules.
Why PostgreSQL #
One of the biggest decisions was moving away from spreadsheet-style thinking entirely.
We wanted structured relational data from the beginning.
That is why we chose PostgreSQL.
The project naturally contains connected entities such as:
- customers
- events
- bookings
- menus
- budgets
- staff assignments
A relational database made these relationships manageable and scalable.
PostgreSQL also gave us:
- strong querying capabilities
- reliable data consistency
- structured relationships
- future scalability
We were already comfortable working with PostgreSQL from previous school projects, which meant we could design the database structure confidently without slowing down the development process.
Using a real database instead of scattered files or Excel sheets was one of the most important architectural decisions in the project.
Designing the Workflow #
One of the biggest technical discussions we had was:
How little information can the user input while still allowing the system to automate meaningful tasks?
That question shaped most of the implementation.
Instead of large free-text forms, we moved toward structured input using:
- dropdowns
- categories
- checkboxes
- predefined selections
This made the data easier to process automatically.
For example:
If a customer selects:
- Wedding
- 120 guests
- Buffet
- Premium package
the system already has enough structured data to:
- estimate resources
- generate offer templates
- classify the booking
- prepare internal workflows
without requiring manual interpretation every time.
That became one of the core ideas behind the system.
AI-Assisted Inquiry Flow #
One of the more experimental parts of the project was integrating AI into the customer inquiry process.
Instead of sending raw customer messages directly to the business owner, we explored a workflow where structured form data would be forwarded to an AI assistant.
The AI could then:
- generate a professional response draft
- summarize the inquiry
- suggest pricing structures
- prepare offer text
This approach was interesting because it combined traditional CRUD systems with AI-assisted workflow automation.
The goal was not full automation.
The goal was reducing repetitive administrative work while keeping human oversight in the loop.
Technical Reflection #
One of the biggest lessons from the project was understanding how important system architecture becomes once software starts representing real business workflows.
Small technical decisions suddenly mattered much more:
- how data is structured
- where logic belongs
- how workflows scale
- how systems communicate
The project became less about “building pages” and more about designing operational infrastructure.
That shift in mindset was probably the most valuable part of the entire process.
Repository #
GitHub Repository: