ProfitOptics Lead Software Engineer Milan Lukić on earning users’ confidence, building dependable pricing capabilities, and giving engineers more time with the business.
Most distributors still rely on spreadsheets to run important parts of their businesses, including pricing. Those spreadsheets hold familiar calculations, hard-won experience, and logic people can inspect.
When ProfitOptics builds a pricing engine or expands a client’s pricing capabilities, that confidence has to carry into the software. People need to see how a price was calculated, know which information went into it, and trust the checks behind it. The goal is software they can rely on every day, without returning to a spreadsheet to recreate the work.
Milan Lukić, Lead Software Engineer at ProfitOptics, helps make that happen. Working alongside pricing experts and clients, he turns business rules into dependable tools built around the way a team works.
We talked about a pricing engine he recently built for a distributor client, the explanation that helped users trust the prices, and how engineering adds value as a tool the business depends on.
When a client needs a pricing engine or expanded pricing capabilities, what do you need to know first?
How the money moves. Who makes the decision today, with what data, and where does it go wrong?
On a recent client project, the request was for a pricing tool. But the underlying problem was that sales reps were arriving at prices differently, using different tables and sources of information.
Once we knew that, the next step became clearer: one set of rules, one source of truth, and an explanation for every price.
From the technical side, I also want to know where the data lives and how clean it is. It’s better to find a problem in the ERP data in week one than in month five.
What did you build for the client?
The client is a distributor selling electronic components in a market where prices change daily.
Previously, a sales rep would open Excel and the ERP, look through the information, and make a judgment call. That took time, and different people could price the same item differently.
We built a pricing engine that uses their data, including quotes and purchase orders, and automatically applies their business rules. When the inputs change, the price adjusts.
Before the engine, they had around 5,000 items priced online. Afterward, that number was around 250,000. The important change was being able to apply the rules consistently across those items.
How do you make sure those rules reflect the business?
I work closely with a pricing expert at ProfitOptics and our client’s business lead.
On this project, I would present an approach for how the engine should work. Our pricing expert would test the rules with the client, then come back with what worked and what needed to change.
That loop—an idea, testing it with the business, and adjusting it—is how we developed the solution. Engineering benefits from both the project’s expertise and what we’ve learned from previous work.
People already know their spreadsheets. How does new software earn its keep?
It has to help them do the work with confidence. I think software works well when users don’t go back to their old spreadsheets.
To get there, you have to put yourself in the user’s seat. If I’m a sales rep, what do I need to see so I can price this item with confidence?
We kept the interface simple. The engine could have a lot happening behind the scenes, but the person using it needed to understand what was in front of them.
Our goal is for the client to trust the tools and use them in their daily work. Then we can work with them to make those tools better. When people keep using the application and start asking how we can enhance it, that tells me they’ve adopted the solution.
What did the client need to see before trusting the prices?
They could see a price, but they needed to understand how it had been built. They needed confidence in the logic before using the result.
"A good price that nobody understands won’t be used."
Our pricing expert and I sat with the client and explained the logic step by step: the inputs, the rules, and how those produced the final price. Then we built that explanation into the product.
What did you add?
A small side panel next to the price.
It shows the inputs and rules used to calculate it. The client can see the relevant costs, the margin they want to achieve, and how those things come together.
That changed the question from “Do I trust this number?” to “I see why it is this number.” They could answer the question themselves by looking at the application.
More business teams are using AI to build tools themselves. A self-contained tool is one thing. What changes when the business starts relying on it every day?
With a few users, a person can catch the problems. When the business runs on it, the system has to catch them.
More questions become important. Who changed this, and why? What happens when bad data comes in at night? What happens when the person who knows everything goes on holiday?
You need data you can trust, a change history so you can explain the results, and reliability. Those things may not be the most visible part of a demo, but they matter from day one in production.
"With a few users, a person can catch the problems. When the business runs on it, the system has to catch them."
How do you build that trust into the system?
In this pricing engine, new information, such as a quote or purchase order, can trigger new prices. That means prices can move quickly.
We built two safety nets. Checks block a bad price from going out, and every price keeps a history of how it was built. That gives the team a way to explain the result or roll back to a previous price.
Security also has to reflect the client’s requirements. For this project, I worked inside a virtual machine the client provided and used their AI coding environment. We built the pricing engine within their environment.
That behind-the-scenes work is what lets the business rely on the application. The safeguards need to be part of the system.
Where is AI helping you do this work?
It gives me more time to review and decide rather than type the code myself.
On the latest project, two developers used an AI coding tool. I still make the engineering decisions and use the tool to help implement them. It takes on repetitive development work, giving me more time to focus on the business side of the project.
That means I can spend more time with the client, join business meetings, and understand their needs directly. We have pricing experts, but it’s valuable for the engineer to be in those conversations too: how should an item be priced, how should the data be handled, and what does the team need to see on the screen?
The more time I have to think from the user’s perspective, the better I can design the solution around their work.
So the benefit goes beyond writing software faster?
Yes. It gives us more room to think about what we should build and whether it will help the person using it.
The price explanation is an example. Being in the conversation helped me hear that the client didn’t understand a price and wasn’t comfortable publishing it. That showed us what needed to change in the application.
When I have more time to understand the client and how they make decisions, I can suggest better solutions. AI helps with implementation, and I can spend more time on the engineering judgment and business understanding that shape the result.
What should someone bring you if they’ve already built a prototype?
The prototype is useful for showing what they want. Seeing it helps us discuss the solution and identify where it can be improved.
Before it becomes a production application, the engineering work still has to happen. That includes security, the live database, reliability, and maintenance.
The prototype makes the idea tangible. The next stage is building a system the business can depend on.
Your pricing engine. More possibilities.
What would help your team price with more confidence?
ProfitOptics helps distributors and manufacturers decide where to improve pricing, then builds the capabilities they need around the ERPs and platforms they already run. Commercial specialists, data teams, and engineers work together to make business rules consistent, connect information, explain recommendations, and reduce manual work.
Whether you rely on spreadsheets, need more from an existing platform, or have an idea ready to develop, let’s talk about what your pricing engine needs to do next.
About ProfitOptics
ProfitOptics combines commercial expertise, data knowledge, and enterprise-quality engineering to help distributors and manufacturers capture more margin and reduce manual work in pricing, rebates, and quoting. Clients can engage the team for commercial advisory, data work, a technology build, or a combination. Capabilities are built around existing ERPs and platforms, with Catalyst’s pre-built platforms and tools providing a head start.
- Founded in 2008: 18 years of solving commercial problems for distributors and manufacturers.
- 250+ team members: Commercial specialists, data teams, and engineers across the U.S. and Serbia.
- Experience with Fortune 50–500 companies: Supporting demanding commercial environments.
- $250M+ in margin expansion: Scenario-based pricing for a $15B distributor. Read the customer story.
- 2X sales team efficiency: A quote-to-order solution for a $400M healthcare distributor. Read the customer story.
- 95%+ acceptance of newly optimized prices: A pricing engine for a $5B distributor. Read the customer story.