A software release was approaching, and a borrowed piece of code kept crashing. The culprit was Oracle's Outside In library. Dennis Turpitka's team found the bug and discussed it with Oracle, but an official fix would take time they did not have. So they examined the library from the inside, worked around the problem themselves, and shipped. In Turpitka's account, the rescue involved patient inspection rather than a grand invention. Someone had to look beneath the surface.
That episode offers a useful way into his career. Turpitka founded Apriorit in Dnipro, Ukraine, in 2002 and made a business of difficult software engineering. He was interested in what happened beneath the interface: how systems communicated, why integrations failed, and where a promising product might encounter an unhelpful technical fact. His public writing gives that work a human scale. There are deadlines, mistaken assumptions, and customers whose ambitions need translating into something a computer will actually do.
Eight people, and the difficult jobs
Apriorit began with eight people. Turpitka was 24. Its early territory included corporate security, drivers, and software research, subjects unlikely to provide much entertainment at a dinner party unless the dinner party had already gone badly wrong. They were, however, areas in which specialist knowledge could become a durable business. By its twentieth anniversary in 2022, the company reported more than 350 people and five offices in Eastern Europe.
The choice of work mattered. In a 2017 interview, Turpitka described a company drawn to unusual engineering problems: operating-system internals, compatibility failures, and undocumented ways for programs to communicate. C++ was central to its work. More than 70 percent of development, he said then, was for Windows using C++. These were his description of the business at that moment, not a timeless inventory.
He also wanted responsibility for the whole product. Market analysis, use cases, testing, and documentation belonged alongside development. An engineer could finish a component while leaving the customer with an unfinished business problem. Turpitka's ambition extended to the troublesome distance between those two outcomes. A program that compiled successfully still had to earn its place in somebody's working day.
A battery with a language problem
One project involved a universal battery intended to power different kinds of drones. Making that possible required understanding the communication protocols used by different manufacturers. Turpitka used the example to explain why reverse engineering deserved a less suspicious reputation. Taking a system apart could make it cooperate with something new. The battery needed to speak several dialects.
He was candid about the costs. Reverse engineering consumed skilled labor. A reconstructed algorithm could behave almost like the original and still fail important tests. A third party could change a protocol and send the investigating team back to the beginning. His enthusiasm accommodated these inconveniences; they belonged in the estimate.
In December 2019, he imagined automation and machine learning taking over more of that investigative work. The aspiration was practical: reduce the effort needed to understand complicated technology, making the method available to more companies. His wider hope was for systems that worked together more readily. The technical exercise carried a cooperative ambition, one battery and one stubborn interface at a time.
The expense nobody applauds
By April 2021, another concern occupied his writing: software can become expensive simply by getting bigger. Every new feature adds code, and that code needs maintenance. A team can eventually spend its resources caring for yesterday's promises, with little left for tomorrow's improvements. The applause tends to accompany the feature announcement. Maintenance receives a quieter reception.
Turpitka distinguished the value people get from a product's functions from the conditions that let a team keep improving it. The second category covered technology choices, working practices, communication, and the ability to respond to change. He argued that an outside development partner should take responsibility for those conditions too.
It was a revealing argument for a founder selling engineering services. He wanted clients to examine how work would continue after the exciting part. Could people exchange knowledge? Was there someone accountable for communication? Would the product remain affordable to change? His proposed test of a partner went beyond the number of developers supplied. The relationship had to preserve room for the next useful thing.
Security that fits the people using it
His advice to startups about data protection followed a similar line. In a 2014 contribution on preventing breaches, Turpitka recommended continuous monitoring with an emphasis on simplicity. Young companies concentrated on research and selling, he observed, could struggle to support tools that required a dedicated security specialist. The protection had to fit the organization that would operate it.
He pointed toward records and alerts that people could search and interpret without extensive specialist knowledge. The interesting detail is the intended user: a small team with competing demands, rather than an imaginary organization with unlimited attention. A technically capable tool still had to make its findings understandable.
The contribution also connected Apriorit with security spin-offs including Hypertection, Cloudifile, and Ekran System. Those projects show a business extending beyond services into related technology ventures. They also help explain the recurring attention to usability in his security arguments. Detection has limited practical value when the people receiving the warning cannot quickly work out what deserves a response.
“Starting up Apriorit was my way of ensuring that I can make a difference by doing what I like the most.”
Dennis Turpitka
Before buying the fashionable answer
Turpitka's July 2021 writing on artificial intelligence began with a question executives can be reluctant to ask: does this project need it? He urged companies to establish the business purpose, examine the work they wanted automated, and assess their data and resources before committing to development. Ordinary automation could already handle some repetitive tasks. Existing services could solve others.
For translation, for example, he suggested considering an available API before building a translator from scratch. He also discussed simpler image-matching techniques and the importance of realistic training data. His interest in AI came with a budget and a checklist. That combination is less photogenic than a prediction about the future, but considerably easier to put in a project plan.
He included ethical questions about bias and the effect on people. In his account, adopting technology required considering whom it would benefit and what errors it might introduce. Read alongside his engineering work, the argument is consistent: a difficult method earns its expense by serving a particular need. A fashionable label provides very little help with that calculation.
A founder, subject to the same rules
The personal details he offered in 2019 bring the executive back to desk level. He had trained technically and worked as a developer before founding the business. Running it meant moving between time zones and responsibilities. He limited most daytime activities to half an hour, with longer meetings as an exception. New ideas went to the people who would implement them, then into a small working pilot.
He admitted that a consumer venture had failed after the team underestimated how far its existing business experience would carry it. His answer was to respect the preparation required outside familiar territory. The lesson sits comfortably beside his technical examples: assumptions become expensive when nobody investigates them.
There was also a pleasing literary complication. His reading recommendation was Charles Bukowski's The Pleasures of the Damned. A founder occupied with software discipline admired poetry made from ordinary, sometimes unlovely material. That preference gives the public portrait an unexpected edge. Computer code was hardly his only interest in how small parts could produce an effect.
A Ukrainian company, an international ambition
In his foreword to IT Ukraine: From A to Z, Turpitka placed the company inside a larger national story. He described a growing technology sector amid political and economic instability, and clients reaching from the United States to South Korea. Digital security, virtualization, and cloud computing gave Ukrainian engineers a role in work being used far beyond their own offices.
He hoped Ukraine would become a significant international technology hub. The ambition connected company growth with a country's reputation for expertise. Each new client relationship could also demonstrate what its engineers were capable of doing. It is an outward-looking view of a business founded in Dnipro: specialist work, performed locally, carrying consequences across borders.
Turpitka died on January 2, 2022, in California. Apriorit marked its twentieth anniversary the following month with a tribute to its founder and a commitment to continue his work. The company now identifies Klaudia Zaika as CEO. Her career there began in quality assurance, another reminder that the less visible parts of software can lead somewhere consequential.
His career is easiest to understand through the problems he chose to discuss. A battery needed to communicate. A library crashed. A product became harder to maintain. A client wanted AI before establishing why. Turpitka kept returning to the work of finding out what was happening underneath. His lasting proposition was concrete enough to test: look closely, understand the constraint, and give the next person something that works.