What Should a 100 Million Won Software Contract Change for the Customer?

Building enterprise software, you end up thinking about contract size. The business has to sustain itself to keep developing the product and supporting customer environments, and I constantly think about which customers and which value lead to larger contracts. Honestly, I want to win big contracts.

But the contract size a vendor wants and the reason a customer pays have to be explained separately. This post is an attempt to take the second explanation all the way to the end: run a hypothetical ROI calculation, see where it stops, and write down what else has to be counted. For readers outside Korea, 100 million won is roughly 70,000 US dollars, a fairly typical size for a mid-sized enterprise software contract here.

Why do the vendor's price and the customer's reason to pay need separate explanations?

Because the two numbers answer different people's questions. How long we have been developing and how many features we have are useful information for understanding the product. What a purchasing owner needs is what changes in their organization after the money is spent. That person has to explain the decision inside their own organization, and "it has a lot of features" is not usable for that.

So the value has to be translated into the language of actual work. Can the evidence someone gathered by hand before every deployment now be checked more easily? Can you review whether a change request matches what was actually deployed? During a handover, can you reduce the re-investigation of earlier decisions? You get closer to value only when you also know which teams need these changes and how often.

What belongs in the cost of adoption?

More than the purchase price. Installation and integration, training, the workload during the transition period, maintenance, infrastructure, and internal operating hours all go in. And the cost of continuing with existing tools has to be compared over the same period and the same scope. Counting only one side in detail tilts the judgment. A common pattern is to itemize the new tool finely while treating the existing tools as free because they are already there.

How is ROI actually calculated?

State the assumptions and multiply all the way through. The numbers below are neither the CollabOps price list nor measured customer results. They are an example of which assumptions need to be checked when discussing ROI with a customer.

Under these assumptions, the working capacity recovered per year is 20 deployments × 2 hours × 12 months, which is 480 hours. Valued at 50,000 won per hour, that is 24 million won per year, or 72 million won over 3 years. Set next to the 180 million won total, this single item does not reach half.

This is not where the calculation stops. What the result says is not the value of the product. It says that hands-on time per deployment was always one item in a larger picture. Other items belong in the same table.

• Consolidating duplicate tools. Running an issue tracker, a repository, a CI server, and an approval workflow separately means separate licenses, separate servers, and separate people administering each. That cost belongs in the existing-environment column.
• Time spent on audits and handovers. Reconstructing "which changes went into this deployment and who approved them" by opening several screens is a different item from the 2 hours per deployment. It grows with the amount of audit response an organization handles.
• Time to reconstruct change context during an incident. Finding which change went out when directly extends the length of an outage.
• Time spent at the seams. This is the time people spend manually connecting the issue tracker, the repository, the pipeline, and the deployment tool. In a combination of separate tools, someone copies state across and double-checks it at every seam. When the repository, change requests, pipelines, and deployment records live on one plane from the start, this item disappears entirely. This column is exactly why we build an integrated platform.

The question in the opposite direction belongs in the same place. Is the product and the scope we proposed the right fit for this customer? If only one team is affected, narrowing the scope may be the right answer. Adding weakly supported effects to justify a price makes the calculation look precise without making it useful.

What should you watch out for when converting time savings into money?

Distinguish the valuation of recovered capacity from an actual reduction in labor cost. The 72 million won above is the valuation of recovered hours, not a statement that payroll went down by that amount. If the recovered time went into deferred work or quality improvements, those results have to be checked separately.

One more thing. Do not mix time that merely elapsed, such as waiting for approval, with time people actually spent working. Shorter waiting time is valuable too, but it is a lead-time item, not a hands-on-time item. Merge them into one number and it will not match when the customer measures later.

How do you account for reduced risk of outages and security incidents?

Only when there is evidence for both the probability and the reduction. The fact that a single incident can be large does not by itself determine a product's effect. You need to know which failure paths it reduces, how often those failures happen today, and how far the product can actually intervene. Multiplying a large damage figure by unknown probabilities and unknown reductions only makes the calculation look rigorous.

So this item is better left as something to measure during a PoC. How often did code change after approval? Were there cases where the deployed artifact differed from the verified one? The controls covered in deployment controls and four-eyes in finance are the kind of thing that goes here.

What should a PoC measure?

Start by recording the current work. Who is involved in the same type of task and how much, where rework appears, and which materials take time to find. Then compare against the applied scope under matched conditions. It also matters not to re-count, as our product's effect, time that other improvement efforts had already saved.

The questions to agree on with the customer are simple. What has to change, and by how much, for adoption to be worth considering? Which records will confirm that difference? If the improvement does not show up, how will the scope and approach change? A PoC that answers these leaves evidence that can be used in the purchasing discussion. In enterprise sales without BD I explained why we put a PoC at the first gate; this calculation is what that gate contains.

So what should 100 million won of software actually change?

The purchasing owner's ability to explain the decision inside their organization. That explanation should contain not the features we provide but the work that actually changed and the records that confirm it. The time to gather evidence before a deployment, the time spent on audits and handovers, the time to reconstruct context during an incident, and the seams between tools that people used to bridge by hand. Only when these items sit in the table together do the number 100 million won and the customer's work land in the same calculation.

The problem that 100 million won of software has to solve differs from customer to customer. That is why the more we talk about price, the more concretely we have to understand the customer's work. Translating the contract size I want into a change the customer can verify is not a sales task. It is part of building the product.