Moving a technology from the lab to the market is a challenge of its own. In 2026, a breakthrough may solve a real technical problem and still prove difficult to commercialise, expensive to implement, or impossible to scale into a repeatable business.
Igor Konopliastyi is CFO at SPhotonix, a deep-tech company developing high-density optical data storage, and previously co-founded the SaaS website-building platform Quarkly. That has put him on both sides of the current problem: developing technology and turning it into a repeatable business. We spoke with him about how to determine if a technology has market potential, why revenue growth alone may not justify scaling, and how enterprise customers can influence product direction.
We are seeing technologies such as glass-based data storage move closer from research to real-world applications. But a technological breakthrough does not necessarily become a successful product. How to avoid building something that works technically but never finds a viable market?
I start with the market, not the technology. Before investing heavily in product development, you need to establish whether the problem is real, significant, and urgent enough that someone will actually pay to solve it. That means talking to potential customers early: understanding how they solve the problem today, what that costs them, what they dislike about the existing solution, and what would make them switch.
Developing the technology first and looking for customers afterwards is much riskier. Founders and engineers can become enthusiastic about what a product can do even when there isn’t enough demand for it.
Customer feedback must influence development from the beginning. A technology becomes a viable business when it solves a problem customers consider important enough to pay for.
In B2B, the engineer evaluating a product and the executive approving the budget may be looking at completely different things. How do you sell the same technology to both?
I focus on outcomes rather than features. The underlying value proposition doesn’t change, but the way you explain it does.
Technical decision-makers care about functionality, reliability, security, and integration complexity. Business decision-makers are more likely to care about cost reduction, efficiency, risk, and measurable returns. So you are solving the same problem, but you need to express its value in the terms each stakeholder actually uses to make a decision.
Suppose revenue is growing and new customers keep coming in. What would tell you that the company is still not ready to scale?
The first thing I would look at is unit economics. You want to scale profits, not losses, obviously.
Before increasing investment in sales and marketing, you need to know that each additional customer creates value after acquisition and operating costs are taken into account. Otherwise, growth simply amplifies the underlying problem. Another signal is repeat business. If early customers return or refer other customers without significant additional sales effort, that is strong evidence that the product is creating real value.
Then there is implementation, of course. If every new customer requires a different onboarding or delivery process, you don’t really have a repeatable model. Scaling business means scaling operational complexity along with revenue.
Could you give an example of what you mean? Let’s say a large customer asks for a feature and is willing to pay for it. Engineering says it will be expensive to build and maintain. Who gets the final say?
Each team has a different role. Business development is closest to the customer, so it can identify the request and assess its commercial value. Engineering can estimate the technical complexity, development time, and cost.
But the final decision should sit with the product team. Product has to balance customer demand and business impact against the technical effort, while looking beyond a single account.
That last part is very important. If you build every feature a customer asks for, you will eventually lose control of the product. A request becomes much more meaningful when you see the same need across multiple customers.
But in enterprise B2B, some degree of customisation is unavoidable. Where is the line between adapting the product and becoming a custom development shop?
It depends on the type of product. For highly configurable enterprise platforms such as SAP or Oracle, customisation is part of the model. Large organisations have very different processes, so these platforms provide APIs, configuration tools, and extension frameworks that allow customers to adapt the system without changing the core product.
For more standardised SaaS products, too much customisation quickly becomes a scalability problem. Every customer-specific feature adds development and maintenance costs. Instead of building something into the core product for one account, you should look for needs that recur across multiple customers.
Integrations can handle many of the remaining edge cases. A customer-specific requirement can often be addressed through an API, a third-party product, or a custom integration without turning it into a feature that the entire product has to support.
So technical complexity can grow with every customer. What about operational complexity? Which processes need to become repeatable first?
I would start with processes that are repetitive, critical, and easy to break as the company grows: customer support, HR, recruitment, and finance.
Payroll, invoicing, expense management, payment approvals, and budgeting shouldn’t depend on somebody remembering how they were handled last time. Standardising these processes reduces operational risk as the company grows.
Customer acquisition on the other hand is different. I would keep it flexible for as long as possible. Channels, messaging, and sales tools change constantly, especially now with AI, so you must need room to experiment. Otherwise you just risk locking yourself into a process too early.
The balance also depends on the business model. B2B sales tend to become more structured because they are relationship-driven and usually have longer cycles.
Most founders would see rising revenue as evidence that their strategy is working. When is the right time to start scaling in your opinion?
Technology companies often start launching new products or entering new markets before they have proved that the existing business works. Scaling too early, however, can become the biggest mistake and ruin the business. Yes, revenue may be increasing, but the burn rate may be increasing with it, with no clear path to profitability.
My rule is simple: scale profits, not losses. Before accelerating growth, you need positive unit economics and a commercial model you can repeat. Once every additional customer creates value instead of destroying it, scaling becomes much less risky.
