What Makes a Software Company Strong Is Not Its Size
Petyo Stoyanov · April 7, 2026
Today, a small software company can do more than ever before. What makes it strong is not its size, but the way it works.
Strength is no longer measured the same way
Artificial intelligence has fundamentally changed the way software is built.
The change is not simply that AI tools now help you work faster and more productively. That is useful, of course, but to me that is not the real shift.
The real shift is that AI now creates a new kind of capacity – one that allows small software companies to build a fundamentally different operating model.
Yes, teams today are made up of both people and virtual employees.
Until recently, the strength of a company was measured by how many people it had, and capacity was largely a linear function of team size. Today, some kinds of work can be taken on by virtual employees.
What matters to me is building a system in which virtual employees are part of how the company operates.
AI as an assistant or AI as a system
This is where the human role comes in. In my view, when you work with AI-driven virtual employees, the human becomes even more important when it comes to the company’s capacity. And not only in terms of capacity, but in other ways too, which I will come to in a moment.
Founders of small software companies now have an opportunity that did not exist until recently.
Imagine two founders of small software companies. The first uses individual AI tools from time to time, and for him AI is more of a chaotic helper. The second has built an entire team of virtual employees who support him-not chaotically, but as a structured system, the way it would look if those roles were performed by real people. A chief architect and a developer can be virtual employees, for example, and so can a project-specific legal advisor.
In the first case, AI is a tool that helps increase the founder’s personal capacity. In the second, AI is already part of a system in which different roles take on different parts of the work – the effect is not just an increase in capacity, but a multiplication of it.
That is why, today, I do not see AI as a helper, but as an entire layer on top of which I can structure the way my company works, the way I envision it.
When I think about how to structure the operating model, I do not start with where to insert AI. I start by thinking about what kinds of people and roles my business needs today. Then I decide which of those roles, services, or functions can be taken on by virtual employees – but only if that creates real value for me, not as an end in itself. As a result, I maintain a structure of virtual employees that looks the way it would if those roles were performed by real people.
The team is no longer made up of people alone
How do I “hire” a virtual employee?
Although I have been talking so far about the benefits of virtual employees, I want to make one thing clear: my goal is to have an optimal, not a maximum, number of employees on the team. And when I say team, I mean people plus virtual employees. For me, going to extremes would only create noise and, instead of helping, it would start getting in the way and pulling focus.
At the moment, our team includes the following virtual employees:
Mentor – my strategic advisor for the business. With him, I discuss ideas, refine messages, and think through the company’s strategic direction.
He is the “person” I sit down with first when I need to think through a business-related topic.
I use him beyond purely strategic questions as well – for example, when discussing new features for our platform. Yes, I could define a separate Product Lead role or something similar, but at this stage of the company that would feel more artificial than useful. What matters more to me is to build on something that actually works, rather than simulate a more detailed role structure that is not yet necessary.
Virtual consultants for specific projects also play a very important role on the team.
Project consultants – if this were a person, it would be the person on the team who knows the project inside out: the contracts, the regulations, the architectural decisions, and the history of the relationship with the partner. The role is not to be a general advisor on everything, but to support a specific project. In my team, every project we work on has such a consultant. They are extremely useful.
The next virtual employee on the team is:
Finance & Accounting Employee (FAE) – this is not an accountant in the traditional sense, nor does it replace the external accounting firm we work with. It is more of an operations assistant who helps me with monthly invoicing. For example, by extracting data from invoices issued by cloud providers and re-invoicing partners according to specific logic, so that everything needed is prepared for the accounting firm that handles our bookkeeping.
I loosely divide the virtual employees on the team into non-technical and technical ones. So far, I have talked about the non-technical ones. As a tech person, I naturally find the technical ones much more interesting.
Chief Architect & Engineer (CAE) – it is now April 2026, and yes, he already codes in my place.
I would say this is one of the most important roles in our model. If he were a person, I would think of him as the team’s chief architect and engineer – someone with the kind of “doctor-level” expertise that comes from knowing the system and the projects in depth. When he is properly guided and given the right context, he can produce high-quality software built on the principles we follow as a team.
Virtual employees work through context. Without it, they are just well-sounding assistants, not real working capacity. That is why it is essential for context to be managed and maintained centrally.
What do I mean by that?
Every small software company keeps its important documents in one place – business plan, strategies, bio, identity, contracts, marketing plan, and so on, whether that is in the cloud or organized in some other way that works for the founder.
In our case, those resources include one more important layer – the virtual employees themselves, together with the context, prompts, and instructions they need.
When you hire a real employee, the first step is to bring them into the context – you give them the company documents they need to start with for their role, the company’s identity, and the specific resources relevant to that role. With a virtual employee, the analogy is very similar – in their folder, you will find the same company documents and the role-specific materials they need.
We follow the principle of a single source of truth – that is, the original version of each document lives in one place. This matters because both people and virtual employees then work from the same current version, rather than from different copies. In our case, this is currently organized in Google Drive through shortcuts to the original documents. But that is simply how we have chosen to organize it for now. Anyone can do it with whatever tools they prefer. What matters is that the context remains centralized and manageable.
Another principle we follow is that the operating model we are building with virtual employees is not dependent on any specific AI tool or provider. The AI models are executors within the framework we have defined for each particular employee. Any one of them can effectively “live” in a different AI environment. At the moment (though that does not mean this will remain the case in the future), we use ChatGPT for the non-technical virtual employees, while for the technical ones we use Claude Code as the primary tool and Codex as a secondary one.
I see virtual employees as real members of the team. They take part in processes just as the others on the team would, with a very clear understanding of the limitations they have (at least for now).
How this model works in our company
So far, I have described the model. Now I want to show how it works in our company through the latest feature we released in the BoroBit App a few days ago. It is a feature that allows users to see the value of their money in the app not only in BGN, EUR, and other currencies, but also through different reference points such as gold, 1 kg of white bread, 1 hour of work, bitcoin, and others. We have written more about the feature itself here.
We started with the stage where we were discussing how this feature should take shape for users. My main work at that stage was with Mentor. As the discussion evolved, the idea itself evolved as well – it grew from a reference point of BGN to EUR into something far more human, such as bread, an hour of work, and so on.
The goal of this first stage was to move the idea from concept to specifics – what problem it solves, where it belongs in the product, what it should do, and what it should not do. I should mention again that Mentor is fed with solid context about the company, the system, the business, and the BoroBit App in particular. He knows all the screens, understands the structure of the interface, is familiar with the current features, and knows the product extremely well, which makes him a very useful advisor when it comes to figuring out how the idea we have should come to life inside the app, in a way that fits both its context and current UX and UI thinking.
Working with Mentor is not an automated factory where we ask and he simply answers. It is much closer to a discussion with a real colleague in a working environment – an iterative process in which we choose between options and look at the topic from different angles. Mentor is not the one leading the process; the human is. The human guides it, makes the judgments, keeps the connection between the product and the final outcome, and moves the process forward.
As a result of this stage, we already know exactly what we want to build in concrete terms – where it will live in the product, which screens and functionalities it affects, and all the details the developer needs in order to implement it.
The process ends with a document we call a feature brief. It serves as the bridge between the discussion stage and the next one – the development stage.
The feature brief contains the structured information the developer needs – the goal, the product principle, what is in scope (which screens and sections), what is out of scope, the core UX rules, and detailed instructions for each screen or section that will be changed or built. The document is designed in a way that makes it useful for a virtual developer to implement the feature. That is why it contains one key element: the development work is broken down into separate phases, so the feature can be implemented phase by phase by the virtual developer.
At the development stage, the team works with the Chief Architect & Engineer (CAE). He takes the feature brief and turns it into a working feature.
CAE is not just a virtual developer that writes code. He is fed with so much technical and company context that he understands the environment he works in very well. He understands the product and the system in depth, and he does not write code in a piecemeal way, but in line with the system’s architecture, following principles for long-term code development, minimal scope, and safe changes (not like a random tool, but like a developer). That is why, for me, his value is not only in saving me time on coding, but in the fact that the team effectively gains one more person who can actually do the work.
Development is also an iterative process, carried out in the phases defined in the feature brief document – as the saying goes, “divide and conquer.”
For this particular feature, we split the development into five phases – an initial phase in which we prepared the internal structure the feature would build on, then one phase for each of the three panels – Portfolio, Cash Flows, and Settings – and a fifth and final phase for polish.
Although CAE writes the code himself, the development process does not happen by magic. I lead the process, while CAE is the one who builds. At every phase, I validate the changes he has made – whether they meet the required code quality standards, follow good practices, and achieve the goals of that phase.
My internal measure of whether CAE has done a good job is whether I can look at the code he has changed or written and recognize it as my own. Most of the time, he gets it right on the first pass, but quite often I still need to guide him, clarify additional details with him (sometimes directly in the code), and feed him more context so that the result fully meets my standards.
During development, if I sense that CAE is missing a specific piece of context he has not been fed with, we pause the work for a moment and add the necessary information to his context – but in a way that makes it available for future work with him as well. At first glance, this may slow the current development down a little, but in my view this is exactly what is key to increasing the capacity of virtual employees: enriching their context must become part of the work, not a one-off action.
This is how the feature moved from idea to implementation: through a process involving two virtual employees, while I led the process, guided the work, and validated every step.
Today, we already have processes in the company in which people, virtual employees, and external and internal systems all take part at different stages. To me, the next level is for the processes between all of them to become increasingly automated.
Security becomes even more important
This model gives us much more capacity, but with it comes a much greater responsibility for the security of the entire environment around the virtual employees. I mean things like what context they can see, how the models themselves are configured, whether sensitive data is properly isolated, and whether everything around them is structured the way it should be.
And the analogy with a real employee is very accurate here – when a new colleague joins the team and starts working on the code, they are not given access to keys, certificates, and everything else. AI needs to be treated the same way.
We take the time to organize our work with AI so that it rests on clear principles – least-privilege access, isolated sensitive data, well-structured context, a properly configured environment, compliance with the security requirements of the specific AI tool, and a human who remains in control.
The human remains at the center
In our case, the central role belongs to people. Virtual employees are important, but the most important ones remain the people who drive this process.
With the rise of AI, many things have changed in people’s day-to-day work – whether for founders, developers, or others. But what has not changed is that the human still carries the risk and the responsibility for the final decision, must understand what they are doing, and remains the one who drives the process.
But yes, the work of a developer, for example, has changed fundamentally. Less and less time goes into mechanically writing code, and more and more into guiding the solution in the right direction.
For me, more and more value comes from directing my daily effort into feeding and maintaining context (as a system, not chaotically) – and AI pays me back for that by taking over the writing of the code, with one important condition: not at the expense of quality. Another activity, not because it is new but because I now invest more effort in it, is formulating the task properly.
Strong context + a well-formulated task = a useful AI developer.
Every three months, I stop and take stock
The software industry is changing continuously with the development of AI. The time when it was enough to learn one or several programming languages, or to specialize deeply in a single technology, is over. That still matters to me, but it is no longer enough. Today, constant adaptation is necessary. And that applies not only to developers and founders, but to almost every profession and field of work.
In the same way, a company’s operating model is not static – it evolves.
I follow one simple rule – every three months I have an automatic reminder that tells me, “Stop what you are doing and check how far AI has progressed over the last three months.” When it pops up, I take time to see whether there is anything new that I can actually use in the way I work and that would create real value for me. It could be a new level of AI autonomy, or simply a useful new tool. If I decide it is not mature enough yet, or that it does not create value for me at this stage, I do not use it.
After that come three months of work, during which I tune out the noise and all the talk around AI and focus on the real work of the company. Then, three months later, I take stock again – and that is how I keep adapting the process over time.
How far will AI go in its development?
I do not know. But I do know that we are living in an extremely dynamic situation, and everyone needs to keep adapting.
I believe the time is coming when a small and strong team will be able to do big things.
Read More
