The 3 biggest learnings I got from switching from a product company to a software vendor

Ahmed Sabaa
Ahmed Sabaa Software Engineer
26. July 2018 in


If you are interested in understanding more about successfully producing top-notch software or even a software engineer who’s thinking of switching ventures to a software vendor, I highly recommend keeping three simple principles in mind that will make your transition a lot easier.

I have been working in software engineering almost all of my life, starting at university times until now. Since I grew up in an emerging market, where the internet was a slightly newer concept than in Western Europe, e-commerce was a beast to be tamed. Most startups that opened in Egypt back then, were e-commerce companies with an idea or a product to sell. Along with that business boom came an adjacent boom entailing the need for web developers or software engineers. That's why the start of my career has been all about B2C e-commerce platforms with a core product to develop along with the back-end services that are needed to run the business. Fast forward some years and I started working at Spryker, a software vendor. It does not sell perfumes online nor does it provide deals for the hottest new restaurants. It gives an opportunity for e-commerce business to have a head-start when embarking on their e-commerce journey. I have been learning a lot from Spryker during my time here and here are my 3 biggest learnings.

Why the quality-first approach really matters

You might be coming into the world of software vendors from a software engineering superstardom, with experiences in microservices, fast delivery, containerization and service discovery. You might be good at getting features out to the customer: fast and in time for some business goals. You might even have incorporated some design patterns or code quality measures to try and make your life and your team’s life easier in the future. But once you stop deploying features to a website and start building a product that is released under semantic versioning constraints, most of your experiences writing code that just “needs to work”is a bit skewed from what is expected from you writing code in a software vendor environment. The software delivery system needs to be different, it’s not code that runs on a server. It’s code that your clients will pull into theirs and should have their cycle update run as smoothly as possible. You might cut corners to reach some deadlines when working on new features for a website but code quality takes higher priority when you sell a software. Of course, there are ways to cut corners while still keeping your code quality high but you have been more creative with your solutions. What I learned the most, is that the learning curve is very steep and some things might not make sense in the beginning until you realize how clients use the software and what is needed on your part.

Design patterns actually make sense

I come from a very DIY software engineering background, we wrote our own Call Center application, our own CRM application and our own accounting application. And while learning and writing all that code, there were multiple times when I thought: “Oh, you can apply a facade design pattern here” or “A factory would definitely reduce the reasons to change for this class”. But then I also thought of all that as over-engineering and programming buzzwords for interviews. I had the mindset of most design patterns being extra classes and extra code written for just instantiating classes or separating concerns. Once you work for a software vendor, design patterns and SOLID principles are your friends, using all those concepts on a daily basis and understanding how much they help you in a bigger structure. Also consistently having those tools throughout your code creates familiarity with your actual users, that is the developers who work with your software. So, learning those early on in your career and incorporating them in your designs for new features or refactoring of legacy code, will make their long-term benefits available to you and to the future developers of your code. My absolute favorite design principle that I realized during my time at Spryker is IoC (Inversion of Control). It is the best way of decoupling modules or packages, which in turn saves software users the headache of constantly updating code that they don’t need.


Conventions, RFCs, and team communication are the only way to move forward

In most companies that I worked at before Spryker, the most recurring issues were knowledge islands and code inconsistencies. But at a software vendor, both of those things cannot exist. A knowledge island leaves your company with a gap that cannot be filled when a developer is sick or leaves the company. And code inconsistencies make the developers working with your software tired of reading your documentation. Having conventions and RFCs constantly discussed within your team helps you have conventions that will lead to code consistency in the long run. Code consistency will also make the lives of the developers working with your software a lot easier. The second you make them expect how a feature would be developed, how it would be integrated into their implementation, you definitely succeed in making your code consistent. In my experience, having a consistent pool of incoming RFCs from the team along with discussions regarding code improvements and glaring problems in the code, are the two best ways of keeping the code shipped to your clients as consistent as possible.

Still got questions?
Ask the author for further information.