In May 2009, Oleg Nesterov had a question for his fellow programmers: which parts of their jobs were boring? He was mentoring a Google Summer of Code project called JDevTools, designed to take some of the repetitive work out of building Joomla extensions. Before the tools came the invitation. Tell us what wastes your time.
The proposed machinery was practical: scripts for creating and packaging extensions, generating files, and handling familiar development tasks. Jonas Arnfred was the student behind the project; Ian MacLennan was Nesterov’s fellow mentor. The ambition was to give developers fewer chores to perform by hand. Software, in this telling, ought to earn its keep.
Nesterov also asked people to challenge the proposed feature list. A tool could be technically sound and still fail the elementary test of being wanted. His post made room for that possibility before the team disappeared into implementation. It was an early glimpse of the question that runs through his later work: what, precisely, should the software make easier?
Later that year, in September, he founded MindK. The company began as a one-person development studio. The distance between those two activities is smaller than it first appears. Both involve finding work that ought to be done differently, then persuading other people to build the answer with you.
“What are the most boring tasks for you while creating extensions?”
Oleg Nesterov · Joomla community, May 2009
A mathematician enters the web
Nesterov’s route into software passed through Sumy State University in Ukraine. He earned a master’s degree with honors; his early professional biography describes the subject as mechanics and mathematics. He began his web-development career in 2006, while his university years were still under way.
By 2011, he appeared among the technical reviewers of Eric Tiggeler’s book Joomla! 1.6 First Look. MindK was then working on custom extensions, templates, and websites. The reviewer biography records three principles he wanted to follow: a sense of mission, enjoyment of the work, and continual self-development. It also describes his interest in teaching and in tools that improve developers’ productivity.
There is an appealing lack of grandeur to those early credentials. A useful extension. A technical review. An answer that helps somebody else get unstuck. These are contributions that invite inspection. They work, or somebody will quite reasonably tell you they do not. The feedback can arrive without an appointment.
The later CEO’s public writing retains that practical scale. He explains budgets, requirements, recruiting workflows, and the decisions a client must make before commissioning software. The vocabulary has expanded since Joomla. The habit of explaining the moving parts has survived.
- 2006Begins web development
- 2009Mentors JDevTools; founds MindK
- 2015MindK opens a university lab
- 2024Returns to speak with students
The customer arrives with spaghetti
One early MindK customer supplied an education in what happens when those moving parts are neglected. Nesterov recalls a US construction executive who had already endured several unsuccessful outsourcing attempts. The executive arrived with a tangle of code and little useful software to show for it.
For a young development business, the assignment carried a second job: help a disappointed buyer believe that hiring another outside team could end differently. A sales promise would have had limited novelty. The customer had presumably bought those before. Working software would need to do more of the talking.
Nesterov’s later outsourcing advice gives clients an unusually active role. They need an internal decision-maker, clear communication, and a working relationship with the people doing the development. Buying outside expertise still leaves the buyer with decisions to make. A contract cannot supply the business knowledge that the customer keeps in their own head.
That allocation of responsibility helps explain the sort of company he has tried to build. MindK sells engineering, but the relationship requires a continuing exchange: the client explains the business; the team questions, designs, builds, and checks. A handover of requirements is only the beginning of the conversation.

An estimate with the awkward bits left in
The same concern appears in Nesterov’s explanation of project estimates. A detailed budget breaks work into features and accounts for several kinds of effort, including analysis, design, development, testing, and project management. Third-party services and risks deserve their own attention. The number at the bottom has a biography.
His distinction between a detailed estimate and an accurate one is particularly revealing. A document can contain plenty of rows without settling the uncertainties behind them. For fixed-price work, discovery and an agreed specification matter. For an evolving product, the estimate has to acknowledge that later decisions will change what gets built.
This is an unglamorous subject on which to spend a founder’s writing time. It is also where trust is often won or squandered. Someone must explain why a feature costs money before the invoice makes the explanation rather more urgent. A beautifully formatted spreadsheet has yet to remove a single unknown by looking confident.
The broader lesson is one of legibility. Nesterov repeatedly makes the work visible enough for a non-programmer to discuss it. Customers can disagree with a feature, question a risk, or change a priority. That becomes harder when all they receive is a price and a promise.
Teaching becomes part of the company
MindK’s connection with Sumy extended beyond employing engineers. In 2015, the company established a web and mobile development lab at Nesterov’s university. A university account describes free courses taught by experienced developers working on international projects. The arrangement brought professional practice into the place where he had studied.
The company later added more ways to share that practice. Its history places the launch of the UP2IT conference and monthly community tech talks in 2017, followed by intensive courses for developers, project managers, and DevOps specialists in 2019. Teaching was becoming a recurring activity with several formats.
In March 2024, Nesterov returned to the university conversation himself, meeting students, graduate students, and teachers online. His subject was the modern employee, the limits of technical skills alone, and the realities of project management. The programmer who once asked colleagues about boring tasks was now discussing the skills needed to work effectively with other people.
The setting matters. Students learning a technical discipline could hear from a graduate whose job had widened to include customers, teams, and judgment. A functioning application needs people who understand one another well enough to agree on what functioning means. There is no compiler for that agreement.
MindK establishes a development lab at Sumy State University, where Nesterov earned his degree.
Hiring software, and hiring across borders
Nesterov’s work also took him into the business of assembling teams. He lists a co-founder role at Bridge beginning in November 2019, describing involvement in its early operations and product direction as it developed its cross-border recruiting services. Finding engineers became a business problem he helped work on directly.
His account of building an applicant tracking system for Bridge starts with a familiar frustration: existing tools did not fit the way the organization wanted to work. The response involved examining requirements and weighing available products against a custom system. Recruiters and other users belonged in that evaluation.
The sequence is telling. First, identify the work. Then ask the people doing it what is missing. Only then decide how much software to build. It resembles the invitation to Joomla developers a decade earlier, translated into a different workplace. The recurring interest is in removing friction from someone else’s day.
He applies a related argument to consulting businesses. In his writing about Innmeldt, a Norwegian pension consultancy, expertise becomes something a software product can help deliver to more people. A consultant’s knowledge has commercial value; the question is how to share it without requiring a fresh hour of personal attention for every interaction.
The Innmeldt product made that argument tangible. Corporate customers could set up their own branded portals, while employees could see pension information and calculations on personal pages. Membership management, questions for advisers, and invoicing also belonged in the system. The consultancy’s knowledge had to become something people could navigate. For Nesterov’s team, that meant working through the everyday details between expert advice and a usable product.
The old question meets AI
By 2026, Nesterov was describing another change in how MindK builds software. His current professional biography emphasizes agentic engineering: AI systems perform substantial implementation work while humans direct the architecture. He frames the challenge around where automation helps and where human judgment remains essential.
It is a contemporary proposition with a recognizable ancestor. In 2009, the repeated work included generating files and assembling familiar pieces of an extension. Today, the scope of the proposed automation is wider. The decision about what deserves to exist still has to be made by someone.
The company has accumulated conventional markers along the way, including a place on the 2023 Clutch 1000 list and AWS Select Services Partner status. In discussing the AWS milestone, Nesterov credited the engineers’ skills and their continuing learning. Those are useful details in a career that keeps circling back to education.
His next test is embedded in the promise he now makes about AI-assisted development: give smaller teams more capacity while keeping quality and security steady. Faster implementation makes the earlier questions more consequential. A team can produce the wrong feature with admirable efficiency. The calendar will applaud; the customer may decline.
The durable part of Nesterov’s story is the attention he has paid to that gap. He has mentored tools, reviewed a technical book, helped build a development business, supported training, and written explanations for people buying software. Across those activities, the useful question keeps returning. Which work should people spend less time doing, and what would they rather accomplish instead?