Business-Centric Design Principles for Demand Forecasting Solutions: A Developer's Perspective

What matters most when developing an AI-based demand forecasting solution? Is it the latest technology stack, or perhaps the perfect prediction algorithm? Jeonghwan Yang, the developer behind ImpactivAI's Deepflow solution, has a clear answer: business priorities and fast delivery. After transitioning from semiconductor process research to AI demand forecasting, he has spent five years solving demand prediction challenges across diverse industries, developing a unique development philosophy along the way. Let's explore his journey in finding the balance between technology and business.

‍

From Semiconductor Research to AI Demand Forecasting

You transitioned from semiconductor process research to AI demand forecasting. What specifically drew you to join ImpactivAI?

Working in semiconductor process R&D, I faced significant dependency issues. Whether it was equipment or other teams, the dependencies were too strong, and communication processes in large corporations weren't smooth either. That's when I started looking for a field where I could work more independently, which led me to programming.

While searching for a domain that could encompass everything, I discovered ImpactivAI. The prediction space intrigued me, especially the approach of taking unstructured data from various domains and transforming it into structured, understandable formats. The opportunity to solve demand forecasting problems across different industries felt like an exciting new challenge.

These fields seem completely different. Did your semiconductor research experience actually help with demand forecasting development?

Semiconductor work centers on clear sequences where each process step follows the previous one. This structured thinking has helped tremendously in development. Development also has its flow with sequences and desired outcomes, so how you deliver the intermediate processes becomes the core of the work.

That said, work ultimately comes down to collaboration with people. While I sought technical independence, I learned that communication with team members and customers determines success.

‍

Development Philosophy for Fast Delivery

Moving from a large corporation to a startup, what was the biggest difference you noticed?

Large corporations have structural limitations that prevent quick decision-making beyond established processes. In contrast, smaller companies have the urgency of needing to meet the market quickly, so we identify critical points fast and communicate directly with the CTO or CEO to make immediate decisions.

Developers these days tend to clearly define their domain and stick to it, but in startups, I think having visibility across the entire picture matters more.

So you chose serverless architecture to enable faster decision-making?

When I first encountered Deepflow, the technology stack differed from what I was used to. The key question was how quickly I could adapt to the new stack and reach the collaboration stage. I used serverless as a tool to divide domains precisely and communicate understanding more easily.

From the client's perspective, they shouldn't need to know about backend changes, and the interface should remain consistent. Serverless architecture enables us to respond quickly when client requests come in. Being able to implement needed features quickly also means we can spend more time thinking about those features.

Going forward, we're focusing on maintaining model hosting well and scaling out effectively, while keeping the web side composed of lightweight logic that can handle steady traffic, even if B2B doesn't generate massive traffic volumes.

‍

Domain Understanding Equals Demand Forecasting Accuracy

Working with demand forecasting across various industries, is there something you consider more important than data?

Understanding what matters most in each domain is key. Even within a single product, identifying what you want to show and what you want to represent in different parts is most important.

Rather than just looking at data, the ability to grasp nuances across different domains has significantly influenced how ImpactivAI approaches demand forecasting problems. Since forecasting predicts what will happen in the future, this paradigm shift has affected my mindset and design approach as a developer.

How does demand forecasting differ from general development?

Forecasting shows what will likely happen based on evidence, which means there's actually more unknown territory. That's why quickly finding what value to deliver becomes crucial. This is exactly why we aim for designs that enable rapid development.

In demand forecasting solution development, I believe determining what to deliver matters more than the delivery itself.

‍

Core Principles of Demand Forecasting Solution Development

If you were building a new demand forecasting solution, what would be the most important design principle?

Delivery comes first, and designs that enable rapid development take priority. After that, I look at editability. Development convenience needs to be high.

It's important to quickly launch a demo version that uses fewer resources and show it to the market. Deploying only to users who requested a PoC is also a good approach. As someone responsible for development, there are policy risks, but being able to respond quickly when problems arise matters more.

Fast response sounds like you'd need to handle everything yourself?

Exactly. Full-stack isn't just about creating a single API. It encompasses how to modify APIs, how to change databases, and how to structure interfaces to compose the whole system. That's why you need to drop what should be dropped and keep what should be kept.

To achieve balance, you need to maintain balance outside of work too. You must first understand what each part considers important. This priority identification matters more than studying hard.

You mentioned priority identification is important. How do you apply this when working with clients?

Since domains share commonalities, when we provide data as a template for demand forecasting, prediction becomes much easier and enables faster feedback. Clients find it easy to fill in data and can see they don't need to hand over all their data.

With just templates, can you work with less data?

No, the more data points you have, the higher the demand forecasting accuracy. Compare collecting time series data daily versus weekly. Weekly collection provides far fewer data points for prediction, which can reduce reliability. Finding other ways to compensate for that is also an important approach.

Do you ultimately build the Deepflow roadmap with these principles?

Yes, for Deepflow, the top priority is what features can help customers with their judgment or actions. We also conduct VOC alongside this to understand what customers want.

We prioritize business requirements over perfecting technology. That's why providing stable services with proven technology matters more than chasing the latest tech.

‍

The Differentiated Experience ImpactivAI Deepflow Creates

One clear message emerges from developer Jeonghwan Yang's story. Successful AI demand forecasting solutions come not from the latest technology but from business priorities, fast delivery, and domain understanding.

ImpactivAI's Deepflow solves demand forecasting problems across various industries based on these principles. Domain-specific template approaches, flexible data processing, and designs reflecting actual customer workflows have led to results including an average 33.4% improvement in inventory optimization.

His philosophy that technology exists for business demonstrates that ImpactivAI is not simply a technology company but a partner in customer business success. We must remember that the future of demand forecasting lies not in technological perfection but in practicality and rapid value delivery.

‍