Building AI Products

This is something I have wanted to put into words for a while.

What I have felt and learned over several years of building AI products—and doing that work in Korea, rather than the US or China. Here, I mean content-generating AI products, specifically those whose teams design, train, and serve their own core generative models for images, video, voice, music, or 3D. Think Midjourney, Runway, ElevenLabs, Suno, Meshy, or Tripo.

There are, of course, approaches like Higgsfield that connect multiple models and add value at the interface layer. This essay focuses on teams that take responsibility for everything from core model research to product development and operation. Once building the model yourself becomes part of the job, the work becomes quite different from building a typical SaaS product.

Software, with something of manufacturing behind it.

What strikes me most about building AI products is how different it is from building typical SaaS: the structure of the product, how the team works, and the skills it needs. Users are clearly using a software service. But behind it, the process of making the product sometimes feels closer to manufacturing.

In a content-generating AI product, users first judge value through the output. Do I like the image? Does the voice sound natural? Can I use this 3D asset for my work? Early feedback often centers on generation quality and control: the resolution is too low, the model struggles with text, or someone wants to change only one part. Once users get something usable, the next questions start to appear: can I make several outputs in a consistent style, or bring them straight into the tools I already use?

Some of these problems can be addressed relatively quickly by improving the UI or adding features and plugins. Others cannot be overcome without improving the model itself. Quality and usability do not resolve themselves in a neat sequence, but in my experience, if the output does not meet the minimum required for a task, it is hard to validate the experience beyond it. That minimum differs for someone making things for fun, someone seeking material to refine, and someone who needs a production-ready result. Even while the product changes quickly, the bottleneck blocking a user's work may remain in the model.

This is where it starts to resemble manufacturing. It is not simply that GPUs are expensive. In typical SaaS experiments, we try to test a hypothesis quickly with minimal resources. In a product built on our own model, the experiment itself can be a substantial investment. Before seeing a result, we need to prepare large amounts of data and secure GPUs. The pace of improvement is tied to those resources and the time training takes. Nor does finishing training mean a model is ready for the product: quality, stability, throughput, and serving costs all have to work. We build software, but behind it we deal with research and production at the same time.

To users, it is software; to those of us making it, it often feels like manufacturing. We can change screens and features quickly, but not necessarily the model that produces the results inside them. Only after preparing data, securing GPUs, and training can we see whether an improvement worked. The model still has to meet quality, throughput, and serving-cost requirements. Users see one piece of software; inside the team, software development happens alongside work that feels like operating production equipment.

One product, different tempos.

What does this look like in practice? The Product team receives feedback every day. We improve the product and ship new features frequently, but some users leave because they dislike the generation quality. Often all they say is, “The quality isn't good.” Which quality, exactly? It is hard not to conclude that the model must come first, so we ask Research for improvements.

Research knows about the problem too. But knowing does not mean being able to fix it immediately. We need to infer the cause, form a hypothesis, prepare data, and experiment. Daily feedback does not produce meaningful research progress every day. It would help to run several experiments in parallel and compare them, but with limited GPUs we run one, wait for the result, and then decide on the next. Product is frustrated. Research is frustrated too. One side watches daily user reactions; the other waits for the next training result. We make the same product, but work on different clocks.

A team leader can see both sides. Faster model improvement requires more resources, but product development and marketing cannot stop until the next model arrives. We need to find people who can get value from the current model and make their work easier. The more costly a decision, the more carefully we consider it. Yet waiting for sufficient confidence in every decision slows experimentation further. We need investment to move faster, but first need to demonstrate confidence to secure that investment.

Trying a different way of working

We have not found a definitive answer, but there are ways of working we are gradually trying within these constraints.

First, narrowing the goal of model improvement. With limited resources, we cannot pursue the best performance in every dimension at once. Instead, we prioritize the most critical recurring user problems: quality issues that block real work. The goal is not vague progress across the whole model, but a change that makes a particular user's task possible. This requires understanding “poor quality” feedback more specifically. Who was trying to make what? Where did they get stuck, and why? If we solve the problem, will they actually use it?

Second, shortening the distance between research and deployment as much as possible. The researcher who develops the model also takes some responsibility for the worker that runs inference in the service. We create an environment where researchers can deploy a trained model and validate stability, speed, and memory use themselves. Tools like Codex and Claude help with deployment and operations code, greatly expanding the scope for researchers to handle initial serving validation. Instead of passing results to Ops and waiting, researchers confirm the model runs in a real serving environment before handing it to Product. This can substantially reduce communication costs and delays at the Ops stage. But omitting a separate Ops step does not eliminate operational work or responsibility boundaries. This is the hardest part: we are still clarifying what Research and Product each own, and which standards both must follow.

Finally, not making every user wait for the next model. Some users already get the quality they need from the current one. We find the tasks they use it for and quickly improve usability and workflows around those tasks. Product and marketing keep running short experiments. The model's limitations should not push every product problem into the next training run. Equally, the ability to change the product quickly does not mean we can demand the same pace from research. Models take time, but the entire team need not wait and move at that same speed.

Perhaps what we are building is not just an AI model or a product. We are also building a way for research and product development, moving at different tempos, to work together toward one user experience.

A flexible customer strategy

It is easy to think of model improvement as giving existing users better results: fewer mistakes, more detail, and better adherence to their input. In generative AI, though, quality improvements can also change the range of target customers. The same output can be entirely usable for one person and not even a starting point for another. People making content as a hobby and those making commercial content need different things. It seems obvious now, but it took me time to realize.

In 3D, an output useful for exploring a concept or learning still needs to meet additional requirements for actual game production, including topology, UVs, and the time needed to refine it. When we first planned the service, we naturally imagined a product for professionals such as 3D modelers and game studios. We are still validating the requirements of their production processes and where the outputs can be used in practice. Some tasks require further editing; others remain difficult to support. While continuing that validation, we also found customers using the current outputs effectively for other purposes. Some people discovered a use for the product before the customers we had originally imagined.

In an AI product, validating a customer strategy is harder than drawing one up. We can plan whose work to support, but properly testing whether they will use it often requires a model with the necessary quality. Model improvement cycles are long, and reaching that test takes substantial up-front investment. If, after months of development, the customers we expected still do not use it, the business outcome can be a major failure regardless of model performance. Yet we should not change the model's direction every time we discover customers who use it well today. Following only the uses that get an immediate response can take us away from the original problem—or from a model with long-term value.

So we need to distinguish the customers we want to help in the long term from those we can help now. We keep the destination of supporting professionals such as 3D modelers, and continue model research in that direction. But the customers reached by product and marketing along the way need not be fixed. We can find people who already get sufficient value at the current quality level, improve their experience, and use their feedback and revenue as a foundation for the next stage. At the same time, we must keep reviewing results with the professionals we ultimately want to help, checking unmet requirements and willingness to adopt. We should not postpone all validation until the finished model arrives. We need to keep the destination but adjust the route based on actual use. That is not easy.

The conditions of building in Korea

None of these challenges is unique to Korea. Any team building a product on its own models will face them. Still, some conditions make the burden feel heavier while doing this work in Korea. GPUs are one. The question is not simply whether they exist, but whether we can secure the right type, at the right time, in sufficient quantity, at a cost and under operating conditions we can manage. Sometimes, even with a budget, it is difficult to get the GPUs we need in time.

Talent is similar. What compensation and opportunities can we offer researchers and engineers competing in a global market? Recruiting good people is not enough; we must also give them an environment in which they can experiment sufficiently. Sustaining that environment comes back to investment capacity. Developing our own models involves costs before we see results, with no guarantee that one training run will reach the level we need. What matters is not only the resources to start the first experiment, but the capacity to continue to the next based on its results. It is also a question of how long we can keep trying while translating a model's potential into real customer value.

Meanwhile, competitors in the US and China keep updating models and launching products. We meet users in the same channels as competitors with large marketing budgets, competing not only on quality but also on search visibility, creator partnerships, and content distribution. These conditions are intertwined. People cannot move quickly without experimental resources; resources need people who can design good experiments and turn them into a product. Organizational conditions add another layer. Security, privacy, legal, and contractual matters need to be reviewed together. These are necessary to provide a stable product. Aligning research and product development with those processes is another challenge we have to address.

Why build our own models anyway?

There is also discussion of sovereign AI and the value of models from countries outside the US and China. What it means to have been built in Korea is a question my own experience cannot fully answer. Still, being close to Korea's content-production industry may help us understand and solve some problems better. That possibility only matters, of course, if it becomes a difference users can actually feel.

Instead, I think about what product experiences become possible when we can build and change the model ourselves. Ultimately, I want to go beyond a service that generates 3D on someone's behalf and build a creative tool that helps people realize their intentions all the way through. A good result on the first try matters, but users also need to change the parts they dislike, connect the result to their existing work, and actually use it. Some problems along that path can be solved by changing the interface; others may require changing the model itself.

Being able to understand and change the technology across the product, from interface to model, according to the work we want to support. There is meaning in judging for ourselves what needs to change to create an experience, then carrying that choice through to implementation. This does not mean building everything ourselves. But for the technology that shapes the product's core experience, I want us to understand its limits and choose its next direction with our own hands. There are still many problems to solve, but that possibility may be why we keep building products on our own models.

And ultimately, I also find meaning in the experience and capabilities these efforts leave in Korea. We need teams here that go beyond using existing technology to research unsolved problems and turn that research into products. If the technical understanding and judgment developed in that process become a foundation for the next attempt, perhaps something meaningful will remain beyond the single product we are building.