We built a system for school meal ordering and meal-count management for customers including daycare centers. Alongside service development, we prepared the cloud environment, the deployment path, and the backup standards, and verified the core business flows.
In a school meal ordering system, the quantities entered on screen are information that real operations will use. Taking orders and managing meal counts may look like separate features, but for the user they have to connect into one piece of work.
Company K needed a new system to handle this work. Deciding what to build and deciding where the finished system would run had to proceed together.
IXC took on development, QA, and the cloud environment as a single project. The starting point of this case was not to look for a server once the features were done, but to prepare the real operating conditions together with development.
The usage pattern of the work became the basis for infrastructure design
A feature list alone is not enough when choosing a server configuration. Whether usage is spread evenly across the day or concentrated at particular times can change what has to be prepared.
For Company K, the server configuration was decided with the hours when orders concentrate in mind. Not only the existence of an ordering feature, but the actual situation in which it is used, was reflected in the underlying environment.
In infrastructure design, the conditions under which a service is used have to be worked out before server specifications. Only when you know at what hours requests gather and what work runs at that moment can you judge the scale and the operating standards.
Without knowing the rhythm of the work, it is easy to judge the environment on average usage alone. That is why usage patterns have to be examined from the build stage onward.
Deployment preparation was not left until after development
The cloud environment was prepared first, and development proceeded on the same schedule. A path from code change to deployment was put in place so that building a feature and putting it into the real environment were connected.
Getting a feature that works in the development environment into operation takes yet another piece of work. If the environment is not ready, users cannot use the code even once it is complete.
The point of automated deployment is not only fewer buttons to press. What matters is that the path for applying changes stays consistent. When the next feature is added, the way it was done before can be referred to.
Even once the deployment path is in order, the features to be released still have to be confirmed. Updating the environment and verifying the behavior of ordering and meal counts have to be handled together for the next change to reach operations.
We confirmed the flow that connects ordering and meal-count management
QA ran alongside development, executing and verifying the core flows of ordering and meal-count management. The process confirms whether the features can be used as work, rather than whether each feature exists on its own.
In a business system, a button responding when pressed and a user achieving their goal can be different things. If a record is saved but the information needed at the next step is missing, the work has to continue outside the screen.
That is why the unit of verification cannot be limited to individual screens. Whether an earlier action leaves the result that a later one will use has to be considered as well. This is why the ordering feature and the meal-count feature are seen as one business flow.
The QA results in this case were part of the process of moving the service into operation. Unlike an approach that looks for a separate party to verify the system after it is built, the core behaviors were confirmed within the scope of the build.
Backup and operating standards were organized as well
In configuring the environment, the backup interval and the operating standards were documented alongside the deployment path. Work that would recur after the service went live was prepared during the build stage.
Setting a backup interval is a preparation for protecting data. A backup setting alone, however, does not mean immediate recovery from any failure. Describing the level of recovery requires separate confirmation through actual restore verification and operating conditions.
This distinction matters when defining the scope of operations. What has been configured, what has been tested, and what can be done when a problem occurs are different pieces of information.
For Company K, the underlying environment and the operating documents were added to the development deliverables so that the next change could follow.
Operations continue on a system customers order through
On the platform we built, customers including daycare centers order meals and manage meal counts. When features are added, the deployment path that was put in place is used, and operations continue.
The outcome of this project is broader than a new order screen. Business features, verification, the environment the service runs on, and the path for later changes were prepared together.
An organization building its first system can easily see development and operations as nothing more than separate phases. But for a service that will be used after launch, the features of day one and the changes of next month have to be prepared together.
The Company K case is a project that connected building the software a business needs with putting in place the environment to keep running it.