Software Planet Group is a UK software development company and long-term product partner for people who want to build something that actually works in the real world. When we look back at the history, it is easy to say: “the company has been around since 2015.” Formally, that is true. But in reality, these were different companies over time since 2000. Names changed, structures changed, legal entities, locations, offices, technologies — everything kept evolving. One thing never changed: a stubborn passion for building software products.
For us, this has never been a classic business merely for making money. Money is necessary to live and to grow, but it has never been the end goal. The real goal has always been to understand how to create software that is more than just a bundle of features; something honest, alive, and genuinely useful.
Every time the industry threw new methodologies, fashionable acronyms or yet another “silver bullet” at us, we kept asking ourselves the same uncomfortable question: where is our own value?
The Question That Wouldn’t Go Away
From the very beginning, we lived with a simple but painful question: as a company, how are we actually different from a freelancer?
A freelancer can be talented, fast and cheap. They can throw together an MVP over a weekend or wire up another integration layer overnight. So why would anyone need companies like ours? What essential, non-replaceable component do we bring?
At some point this internal question became even sharper after a phrase by the well-known start-up founder Anton Karpenko aka Karpolan (RIP): a developer in outsourcing is lost to a start-up. It sounded like a verdict: service companies do not think about the product, they think about tasks. They care about items in a tracker, not about a living product that grows, survives and changes the market.
We understood very well why the industry often sees it that way. Classic outsourcing frequently does sell hours rather than product. But we refused to accept that label as a law of nature. We wanted the mere fact of our existence to be a counter-example.
We do not “code the client’s tasks”. We do not want to be “hands for Jira”. We see our role as helping the client launch a successful product and grow it over time. That includes not just implementing features, but also protecting the product from technical mistakes and strategic missteps the client would almost certainly make without a competent partner at their side.
Our answer to the phrase “a developer in outsourcing is lost to a start-up” is this: yes, if it is just outsourcing. But if it is a team that shares responsibility for the product, challenges requirements, proposes alternatives, and cares about the next release as much as the current task, then the developer is not “lost”, they are “multiplied”. That is the model we are trying to live.
And even if we end up as the last mammoth still holding this position, so be it. Partnership with our customers is what gives our work meaning; shipping a new product and seeing it succeed is what gives us a sense of significance in this world.
An Industry Burnt by Its Own Projects
In the late 1990s and 2000s, everyone could feel it: something in software projects was fundamentally broken. Books like Death March by Edward Yourdon appeared, openly describing what many of us had already seen with our own eyes: projects that were doomed from the very start, systematic budget overruns, missed deadlines, exhausted teams.
Large corporations were losing huge amounts of money not because people were stupid, but because processes were ineffective, requirements were blurry, and project management was chaotic.
For us, Death March was not just another “clever” book on the shelf. It was an unpleasant but useful mirror. It showed what kind of meat grinder the industry repeatedly throws itself into, and what any project inevitably turns into if you do not actively manage uncertainty and expectations.
But that was only a diagnosis. What we still lacked was a direction of travel. If this is what we do not want, then what do we want instead, and how do we get there?
Between Frameworks and Reality: MSF and RUP
The broader industry, of course, did not stand still. It tried to respond in a more formal and structured way. Microsoft introduced Microsoft Solutions Framework (MSF). Rational Software promoted Rational Unified Process (RUP). These were attempts to bring order into the chaos: to define processes, roles, phases and artefacts.
They provided a language and a structure. They helped name things and avoid at least the most obvious insanity. But they still did not give the one thing everyone secretly wanted: a guarantee that a project would no longer turn into a death march, and would instead become a controlled movement towards value.
Yet even when you follow these processes to the letter, churning out piles of documents in the name of “clarity”, the actual impact on outcomes is often marginal. The defects are still there, only now they are better documented. The software industry was still desperately searching for a way out.
Extreme Programming as Our First Hill
The first real turning point was discovering the approaches and philosophy of Kent Beck, which he lays out in his books on Extreme Programming (XP). After Death March, it was a genuine breath of fresh air. If Yourdon had shown us what hell looks like, Kent Beck showed us at least a rough path out of it.
In one of his books, he tells a story about planning: he and a friend got lost, and Kent suggested climbing a hill to understand where they actually were. It is a very simple, almost everyday metaphor, but it captures software development perfectly. As long as you wander blindly in the lowlands, you may keep moving fast, but you have no idea where you are heading or whether the path makes any sense at all. You are just “taking steps”. For us, Extreme Programming became that hill.
We climbed it to get a view, and for the first time clearly saw several things.
Firstly, speed without feedback is not an advantage — it is simply a way to hit the wall faster. Secondly, code quality is not a luxury, but the foundation of any sustainable speed in the medium and long term. Thirdly, working with the customer is not “acceptance of completed work”, but a continuous conversation in which goals, risks and priorities become clearer over time.
XP gave us both language and practice that still, to this day, shape the way we think: short iterations, tests as a way of thinking about design, refactoring as an ongoing process rather than “a celebration one day in the future”, and working shoulder to shoulder with the client instead of hiding behind kilometres of specifications.
If Death March showed us what we did not want our projects to become, Extreme Programming gave us the first vantage point from which we could see where and how to move next. In many ways, that hill was the starting point of our conscious journey as a company that wants to build and grow products, not just “deliver tasks”.
Passion as a Response to a Systemic Defect
If we speak frankly, the root cause of most project failures has rarely been technology. Projects fail not because the programming language or framework is wrong, but because nobody is willing to say out loud: “we do not understand what we are building” or “we will not make this scope in this timeframe with these resources”. Often it is because the project has no true “owner” who is ready to invest their energy in bringing it to life.
We gradually realised that the real shortage in the industry is not the lack of engineers or the lack of yet another methodology. The real shortage is teams that genuinely care about the product rather than about ticking off tasks.
For us, passion stopped being a romantic word and turned into a very pragmatic answer. People who genuinely care notice defects in requirements before they turn into disasters in production. They argue, they clarify, they refuse to implement something obviously harmful just because “it is in the spec”.
This is the mindset we have tried to cultivate inside Software Planet Group: to be the team that cares about the product at least as much as the client does. It is not always comfortable for clients, because we ask unpleasant questions. But in the long run, this approach wins — both in terms of money and in terms of quality.
How We See Our Expertise Today
Looking back from 2000 to today, we do not see a neat linear story of “business growth”. What we see is a trail of searches and corrections.
We are rethinking our expertise not as “we are good at Java, Rust or Svelte”, but as the ability to turn a chaotic mix of ideas, constraints and expectations into a clear, controllable process of building a product.
Our difference from a freelancer and from traditional outsourcing is not the size of our team or the slick design of our website. The difference is that we assume responsibility for the entire journey: from the earliest rough hypotheses to a live product you are not ashamed to show to users and investors.
We are not selling hours. We are investing ourselves in outcomes and we understand the cost of being wrong.
Yes, this approach has its roots in that same era of budget overruns, failed projects, and scepticism towards outsourcing as a class. But our passion for software development is not “love of code for the sake of code”. It is a readiness to learn from other people’s and our own failures, to change our ways of working, to challenge industry dogma, and to keep asking the same hard question: what real value are we bringing here?
Instead of a Postscript
Software Planet Group was born and grew up in a time when the industry was learning from very expensive mistakes. We have gone through our own excesses, naivety and brave experiments as well.
One thing, however, has not changed: we do care.
For us, this story is not about more than twenty years of business. It is about how a passion for building software products turns into a sense of responsibility for the result.
And as long as there is still something to rethink and to improve, this story is far from over.
No matter what kind of product idea you have, whether you are in London, New York or anywhere else, when you work with us you can be sure of one thing: we will do our best to act as your true partner, to immerse ourselves in your industry — from accommodation to construction — to look at your product’s UI/UX through your users’ eyes, to add real value to your idea, and to contribute to your success.
