Alexander Yumashev and the trouble with saving time

Alexander Yumashev once took the CEO title out of his email signature. He was answering customer support tickets, as he liked to do, and the title kept producing an awkward reaction. A chief executive replying personally? Customers wondered how small the company must be. For a while, he presented himself as Alex from tech support. Then he put the title back.

The exchange contains much of what makes Yumashev interesting. He had built a software business in which the founder could hear a complaint, understand the code behind it and decide what happened next. Yet this direct access could make buyers suspicious. The usual corporate distance had become so familiar that its absence required an explanation. A useful service was being mistaken for an understaffing problem.

Today he is the founder, CEO and lead developer of Jitbit, the self-funded company behind a help desk ticketing system available in hosted and self-hosted versions. His professional identity has several tabs open. He runs the business, writes software, publishes essays and releases open-source tools. Closing the coding tab has never appeared to be part of his plan.

The customer who paid nineteen dollars

Yumashev grew up in Russia, studied mathematics and computer science, and worked as a software engineer at a bank. Alongside that job, he released small Windows programs. The early breakthrough was a stranger buying a $19 network utility for system administrators. A person somewhere had exchanged actual money for something he had made. The amount was small; the evidence was persuasive.

He kept experimenting while holding on to the salary. His account of those years includes a Moscow apartment, a $500 car and new applications arriving every few months. The projects initially brought in roughly $1,000 a month. Eventually, the bank supplied more than a pay cheque: its support work gave him a problem he understood. He had already written a ticketing system for his own use. Help desk software became the business worth pursuing.

Jitbit dates its founding to 2005. Yumashev’s ambitions had previously wandered through an independent music label and a recording studio, both unsuccessful. Music remained an interest; software offered a more promising way to make a living. In 2013, he described a colleague encouraging him to release a little Windows application as shareware while he was also testing shopping-cart software with a friend. The experiments could help one another.

That detail makes the origin less tidy, and more believable. There was no single immaculate business plan waiting to be executed. There were things to build, a way to accept payments and customers who might buy. The founder who wanted independence had to discover which of his enthusiasms other people would finance.

A crowded market looked inviting

By 2012, Yumashev was arguing publicly that an existing market could be a fine place to start. His guest essay for Business of Software defended products entering categories where competitors were already selling. Customers had demonstrated that they wanted something. Competitors supplied examples to study, including weaknesses a new entrant could address.

He used Jitbit’s Macro Recorder as an example. Other tools already existed when it launched. Early sales encouraged the team to improve its own version. The help desk application, meanwhile, could contribute substantial revenue without owning the top Google result. His argument allowed room for an ordinary commercial ambition: make a product useful enough for some customers to choose it.

It also made learning cheaper. Taking payments, marketing a website and managing a team were skills that carried across products. A familiar category gave a new founder somewhere to practise them. Novelty could wait until the business had learned how to function. There is a certain relief in an entrepreneur allowing the world to continue existing while he sells it software.

The help desk itself reflected his experience inside organizations. He wanted an approachable interface while retaining the features administrators needed, including directory integration and an option to run the software on their own servers. Ease for the person asking for help had to coexist with the requirements of the person responsible for the system.

In a 2017 interview, he recommended bringing support staff into business and product discussions. They talked to customers every day. He also suggested executives spend time answering customer emails themselves. These were practical instructions from someone whose product had grown out of doing that work, rather than observing it through a reporting dashboard.

The inbox gets a vote

Yumashev’s support habit continued after Jitbit became an established business. In his 2018 account of answering tickets, he described how customer conversations had repeatedly changed the roadmap or the way the product was positioned. Someone using the software could expose the consequences of a design decision far sooner than its author expected.

The CEO signature complicated that exchange, but it also carried authority. A founder could explain why a requested feature did not belong, or recognize a request that deserved to change the plan. Being available gave him both kinds of conversation. The useful information sometimes arrived attached to irritation, which is rarely how a product team prefers to receive its education.

His objection to outsourcing support follows the same logic. Earlier in his career, his responsibilities had included fixing printers and making Ethernet connections as well as responding to requests. In 2021, he argued that handing support to an outside team did not make bugs or product decisions disappear. Those questions still had to reach the people who could act on them.

For him, a small business also offers a customer a shorter route to its decision makers. Filtering every interaction risks removing an advantage the customer chose it for. He urges founders to stay familiar with the ways their product is actually being used. Otherwise, a plausible picture of the customer can gradually replace the customer.

The freedom to remove a feature

There is a financial choice underneath these habits. Jitbit is privately held, profitable and has taken no outside investment. Its customers fund the business. Its distributed team serves companies around the world, including Siemens, HP and Philips. The company’s public description still places being small and personal alongside being stable.

Yumashev made the product implication unusually explicit in 2013: “we love killing features, instead of adding them.” A crowded interface can be the accumulated record of reasonable requests. Removing something requires deciding which requests deserve to survive. Talking to customers gives that decision a basis beyond the founder’s preference for a tidy screen.

By 2022, he described independence as freedom from having to pursue an IPO, acquisition or other liquidity event to satisfy investors. He also spoke about the pleasure of fixing a bug and having people benefit immediately. Continuing to program was part of the reward. The remote company gave the team freedom of movement as well as a livelihood.

His co-founder, Max Al Farakh, remains part of this story. Yumashev began the venture himself and brought in a business partner as it developed. Their shared support experience helped shape the product. A company built around direct contact still needed colleagues; independence did not mean answering every ticket or writing every line alone.

“Coding was the reward, at least for me.”

Alex Yumashev, August 2026

When the reward became the shortcut

Yumashev has long been candid about the temptation to retreat into code. In a 2020 essay, he treated programming as a way founders could avoid marketing, analytics and the duller obligations of running a business. The work felt productive, and it was enjoyable. That combination made it an especially convincing hiding place.

His open-source profile shows how much of his attention still goes to practical engineering. The projects he highlights include SAML authentication, HTML sanitization, caching, mapping database results, coordinating browser tabs and exporting CSV files. These are the components of software that must work after the announcement has faded. They suit a developer who continues to maintain a commercial application.

Then AI made the relationship with coding more complicated. In March 2026, he described trying to remove jQuery from 67 files using a coding agent. He prepared instructions and helper functions, and arranged separate writing and review agents. The task still produced mistakes involving nonexistent page elements and differences between jQuery and browser behavior.

He was frustrated precisely because he already used AI heavily. Starting something from scratch and changing software with years of inherited decisions were different assignments. Existing customers depended on the latter. The experiment left him reviewing the files himself, with a rather less cheerful view of autonomous migration than the promotional demonstrations suggested.

In April, he revised an earlier prediction that AI might undermine the SaaS business. His new argument emphasized responsibility: customers buy someone’s continued ownership of a working service. Generating code does not settle who maintains it, handles exceptions or answers when something breaks. Jitbit was incorporating AI summaries and suggested replies into its existing product.

A motorcycle test, and the work left over

His enthusiasm survived the complaints. In August 2026, he described an agent building a small practice application after he needed to retake a motorcycle theory test. It collected about 550 questions from the relevant website. He practised for a week and reported getting every answer right. The software solved a narrow problem for one person.

Later that month, he returned to the pleasure AI had displaced. Writing code had been the enjoyable destination after research, customer conversations and product decisions. Faster implementation left more of his day devoted to deciding, prompting and reviewing. He welcomed the ability to fix neglected problems, while missing the act of building.

The questions preceding the code remained stubbornly human: should the feature exist, would it complicate onboarding, and would it disrupt somebody else’s workflow? Cheap implementation made weak ideas easier to approve. Every additional setting could become another obligation to maintain. The founder who liked removing features now had tools that made adding them almost irresistibly convenient.

By September, he was examining where AI actually helped service desks, emphasizing documentation, narrow tasks and assistance for support agents. It was familiar territory for a developer who had started with the everyday mess of support. The tools had changed. He was still asking whether they helped the person trying to get a job done.

Yumashev’s interests include bass guitars, snowboarding and mountain biking. His book, How to Build a Bootstrapped Software Startup, gathers another part of that long experiment in making things. But his ongoing story is easiest to recognize in the inbox: a request arrives, a decision follows, and somewhere behind the reply sits a founder who would very much like to get back to his editor.