A website that explains 24 services, accumulates technical content, and meets customers in Korean, English, and Japanese. To keep a growing number of pages manageable, IXC chose an MDX-based content structure instead of a separate CMS and combined it with a managed cloud, an enterprise-grade CDN, a web application firewall, and malware detection.
The website had more and more to hold. The range of services had widened, and the experience gained from projects had to be recorded as case studies and insights. What had only been explained in Korean now had to be delivered in English and Japanese too.
The work of managing the website, however, could not grow at the same pace. Moving between several admin screens to introduce one new service, or relying on memory to know whether all three languages had been updated, was not something that could be sustained for long.
That was the problem we wanted to solve with this rebuild. A website that can hold more, without making the next addition or correction any more complicated.
The IXC website you are reading now is our own project, planned and built on that goal.
As the company changed, we redefined the role of the website first
IXC provides services in four practices: software QA, cloud, payments, and customer engagement. The website had to introduce these businesses while helping visitors find the service that fits their own task.
A team preparing a release and a team considering a cloud migration, for example, want to confirm different things. The former cares about which risks are verified and what they receive as deliverables. The latter wants to know how much of the migration can be entrusted and how operations continue afterwards.
Rather than introducing every service broadly in one sentence, we chose to explain the problem and scope of each service separately. That is how the 24 service detail pages came to be.
We also divided the roles of the content. Service pages explain what can be entrusted to us, and case studies show the actual decisions and the course of the work. Insights cover the judgment criteria needed when adopting or operating a technology.
The visitor journey we hoped for is simple. Someone who understands a problem through an article confirms the approach in a related case study and goes on to look at the service they need. Even if they do not inquire on the first visit, we wanted a website worth returning to at the next decision.
The pages were multiplying, so why did we remove the CMS?
For a content-heavy website, a CMS is the first thing that comes to mind. Writing in an editor, inserting images, and publishing has clear advantages. We attached a CMS at first as well.
As we organized the operating structure, though, a more important question emerged. Where does the authoritative content live, and by what path are changes reviewed and published?
For IXC, managing the relationship between service information, per-language manuscripts, and screen composition mattered more than managing article bodies alone. Development and content work were also closely connected rather than handed off between separate departments.
Under those conditions, the approach we chose was to run no separate CMS and to use MDX files as the authoritative source of content.
MDX is a format that lets reusable screen elements sit inside a document-style body. Long articles are written like documents, and where needed they combine images, explanatory blocks, tables, or notices.
This was not a decision to give up on design and upload plain text. It was a decision to manage manuscripts as manuscripts and to manage recurring screen expressions as shared components.
File-based operations are not more convenient for every organization. Where there are many non-developer editors, or complex approval and scheduled publishing is required, a CMS may be the better fit. IXC chose to reduce the number of systems it has to maintain, in line with who edits and how we develop.
What we wanted to keep light was not only the website's screens. It also included the work the team has to carry to keep the site running.
Keeping three languages aligned mattered more than creating them
Building a website in Korean, English, and Japanese does not end with the first translation.
When the scope of a service changes, the descriptions in all three languages have to be reviewed together. When a new case study appears, readers of each language must be able to understand the same project. If an item Korean now says we no longer provide is still on the English page, that is not a translation problem. It is a problem of making different promises.
So instead of managing the three languages like separate sites, we grouped them as per-language manuscripts belonging to the same content. The relationship between shared information and each language's body is made explicit.
A missing manuscript in a required language is checked during the build. If the three languages needed for publication are not all present, it surfaces before deployment.
Of course, the existence of a manuscript file does not guarantee the accuracy of the translation. Omissions that automated checks can catch must be distinguished from differences in meaning and expression that only a reader can judge.
The operating principle we set rests on that distinction. What can be checked repeatedly is left to the system; whether the meaning of a service comes across is judged by a person.
Rather than leaving multilingual operations as a special extra task, we wanted it to be a routine step that every piece of content passes through when it is published.
We chose a structure that reads consistently over a different screen for every page
As services and languages increase, design becomes an operations problem as well. If the rules for headings, cards, tables, and buttons are decided anew for every page, the number of things to fix keeps growing.
IXC chose to share the rules for recurring screen elements through a design system. Even as the manuscripts differ, the way a visitor reads information and finds the next action stays familiar.
Consistency here does not mean making every page identical. A service introduction needs scope and process, a case study needs background and decisions, and a technical article needs explanation and evidence. The character of each content type is kept while the basic rules of expression are shared.
Sentence lengths and line breaks also differ across the three languages. Not treating English and Japanese as finished just because the Korean screen looks right, and reviewing shared components alongside each language's actual screens, became an important standard.
We wanted the website to be a place where knowledge accumulates
In this rebuild, insights were not a bulletin board for posting company news more often.
What has to be verified before a release, which risks to look at first in a cloud migration, what to prepare to be ready for an outage. Insights are where the questions IXC deals with in the field are recorded as content that readers can apply to their own situation.
It would be a shame if such articles were read only on the day of publication. They should connect to related articles and be reviewed again when technology and operating conditions change. We needed a structure that could be found and revised over time.
This long-term accumulation is part of why we chose MDX-based content operations. Even as service introductions, case studies, and insights keep growing, we wanted the standard for managing manuscripts to stay consistent.
For readers who arrive through search, what they need first is an answer. Rather than repeating technology names, we explain what problem we started from, what we compared, and why we chose that method. That is the editorial direction we want to keep so the website remains a knowledge asset of IXC.
We manage the content ourselves and moved the infrastructure to a managed environment
Managing content as files does not mean taking on all of the server operations ourselves.
What we wanted to control directly were the service descriptions, the content structure, the user experience, and the criteria for publishing changes. Managing the entire underlying environment needed to run the website separately was a different kind of burden.
So the deployment environment moved to a managed cloud. We manage the content and the application, and rely on a managed environment for infrastructure operations.
This decision weighed not only server fees but also the work that goes into operations. Once the website is public, it has to be revised and inspected continuously. A configuration that reduces the attention spent on the underlying environment and lets us focus on improving content and services suited us better.
Choosing a managed environment does not remove operational responsibility. Confirming the application's behavior, access permissions, and the content being published is still our job. It is closer to a decision that separates what can be delegated from what we remain responsible for.
We handled overseas access and security at separate layers
A website offered in three languages cannot assume a domestic-only access environment. We configured both the path that delivers content and the safeguards that protect the public application.
An enterprise-grade CDN for content delivery
We applied an enterprise-grade CDN so that cacheable content is served from a distributed delivery network. The configuration reduces the load of the origin server handling every request directly and delivers content efficiently to overseas visitors as well.
Applying a CDN alone does not make every page open at the same speed, however. Cacheable content and dynamically handled requests have to be distinguished, and the results confirmed in real access environments.
A web application firewall and DDoS protection for public requests
We also applied a web application firewall (WAF) and DDoS protection. The WAF inspects incoming web requests and filters out hostile ones. DDoS protection handles large volumes of attack traffic.
Even a corporate website has points that accept external input, such as the contact form. Delivering content well and protecting public endpoints were treated as separate tasks.
Malware detection for the operating environment
We introduced malware detection as well. A web application firewall that inspects requests and a function that detects malicious files in the operating environment play different roles.
Applying any one of these does not complete security. The protection layers were configured on the premise that application updates, permission management, and secure code have to be handled together.
We made deployment simple without skipping the check before publishing
When an update is cumbersome, even small fixes get postponed. Conversely, if publishing is easy but there is no verification step, errors deploy just as easily.
IXC configured changes to pass through checks before proceeding to build and deployment. In addition to checks on code and content, a step that exercises key behaviors in a real browser, such as the menu, search, and contact form, is connected. The checks run automatically on every push, and once a verified change is merged into the main branch, the managed environment takes over the build and deployment.
For the check before publishing we use Qoretix (qoretix.com), IXC's own release-readiness review: one build, three critical flows exercised in a real browser, and one retest after the fixes. The same standard applies to this site.
What we considered important was not automated deployment itself but what confirmation comes before it.
A new page does not exist only as a standalone document. It works within per-language screens, lists and links, and shared components. Beyond whether the changed part looks right, we also have to see whether the flow visitors were using is preserved.
Automated checks take on the repeated inspections. They do not judge whether a manuscript is persuasive or whether a description matches the actual scope of a service. Technical publishing conditions and editorial judgment about the content are carried together.
The result of this rebuild lies in how the next change is handled
The new website holds more services. It also has a foundation for running Korean, English, and Japanese content and continuously accumulating case studies and insights.
The important change in this project is that several decisions connected into one way of operating. The content source is gathered in files, recurring screens use shared rules, and changes are published through a verification and deployment flow. Content delivery and security each use the technology suited to its role.
We do not try to explain this in terms of search rankings or inquiry growth right after launch. Those results are something to confirm as real operating data accumulates. What we have put in place is a structure that lets a website with growing content keep being revised and operated.
The standard going forward is here too. When introducing a new service, revising an existing description, or publishing a new case study in three languages, we will confirm whether the current structure actually reduces the work and improve it.
What IXC changed was not only the look of the website. It is the way the services and knowledge the company builds up keep being reflected on the website.