Between 2014 and 2016, PrestaRock consisted of three developers, including me. My workday was now structured differently: around 30% of my time was dedicated to project management and client communication, another 30% to task coordination, descriptions, and preparing specifications, and the remaining time was spent programming.
What were my first clients like? What did I learn from them, and what mistakes did I make? Why did each of my emails or requests improve over time?
As a freelancer, I noticed that I spent almost half of my programming time on phone calls and emails. That naturally led me to start my own company. I organically transitioned from developer to project manager, and my knowledge in this role was primarily shaped by observing how other project managers had worked with me throughout my career.
I also wrote about how, when I was a programmer working in an advertising agency, it annoyed me that the project manager had no technical knowledge. As a result, project management was merely about relaying messages and acting as a “copy/paste” intermediary between me and the client.
I envisioned myself as a completely different type of project manager who could solve this problem. I wanted to be able to answer any technical questions in real-time during meetings, provide recommendations on how to implement solutions more efficiently (playing the role of an analyst) and estimate tasks on the spot. This approach laid the foundation for what PrestaRock stands for today—Rock Solid Ecommerce Solutions.
We introduced the one-stop-shop principle, ensuring that project managers didn’t have to say, “I don’t know, I need to check with the developer to see if it’s possible, how much it costs, etc.” Having a single email communication channel became our guarantee of speed and quality.
Based on what I had heard at university, I managed projects the best way I knew how. I implemented an AGILE SCRUM project management method in the company, introduced weekly SPRINTS, documented processes and instructions, and moved away from an ad hoc work style where tasks were assigned randomly. Instead, we planned everything and structured tasks properly.
This allowed me to distribute work more efficiently. At the beginning of each week, I would document and assign tasks to the developers, ensuring they wouldn’t need to interrupt me throughout the week. This freed me up to focus on programming or working with clients.
I gained knowledge not only from my previous experiences but also by learning from my clients. Each email improved over time—I iterated on my writing style, responses, and communication approach with every interaction. I strived for what Brian Tracy calls “excellence.”
As a freelancer, I had the opportunity to work with some of the biggest e-commerce businesses at the time, and I was fortunate that my first clients were more experienced than me. Some sent me well-structured requests, and I realized their format would be helpful for others. So, I started using a similar structure for my other clients. Through trial and error, we always had more work than we could handle.
However, challenges soon followed. As we grew, we made our first mistakes and experienced our failures. During those years, we encountered demanding clients, and, honestly, just like working with untalented employees, it was harder to work with inexperienced clients as well.
Ten years ago, one of our first failures was that our team was still tiny. We sometimes miscalculated task durations, leading to delays because tasks were completed by someone else rather than myself. Additionally, unexpected extra work often arose, which clients assumed would be delivered within the same deadline, even when the scope expanded.
As a project manager, I didn’t know how to manage expectations, making it challenging to convince clients that some tasks needed to be split into separate phases or planned as a new stage.
Ultimately, I sometimes unintentionally promised unrealistic deadlines, which we couldn’t always meet. Looking back, though, the entire e-commerce industry was like the Wild West, and no IT project in Lithuania was ever completed on time during those years.
One of my biggest failures was a client’s attempt to build an “online shopping mall.”
Even then, I knew the idea would fail, but I couldn’t convince the client otherwise. So, we proceeded. Everything was fine until the client imported 500,000 products into PrestaShop 1.6. And what happened? Of course, PrestaShop couldn’t handle it.
Once again, a lack of project management knowledge became apparent. Our team started optimizing the project for free, even though it was additional work. I couldn’t convince the client that they needed to pay almost as much as the project cost to make it work.
But we weren’t the type of company to leave a project unfinished, so we kept working for free.
A similar situation occurred with an amber jewelry e-commerce store from the seaside. The client knew nothing about computers, the internet, or online stores but wanted to build one.
We helped with everything until we encountered a problem—the client’s product photos were of poor quality and improperly taken. Yet, we were blamed because, from the client’s perspective, the final result should have just worked.
They didn’t understand, even after three or four meetings, when we explained that the e-commerce platform generates thumbnails from what the client uploads; we tried solving the poor photo quality programmatically.
The situation escalated when we had to integrate a new PayPal credit card module that had just been released. The client demanded, “Make it work like eBay!” However, PrestaShop didn’t have a third-party module for this, and PayPal’s technology didn’t allow it. The client still wouldn’t accept it.
I remember visiting one of Kaunas’ largest companies to discuss developing an electronics e-commerce store.
The CEO kept complaining that our prices were too high and insisted that everything should be cheaper. Since this was a big, prestigious client, I offered discounts.
Later, I discovered that this company had a €30 million annual revenue and millions in profit.
At the time, I was young and inexperienced, so I offered discounts to almost everyone. That made me an ideal contractor: cheap, fast, and high-quality.
Finally, one of our biggest challenges was developer errors.
We had no testers at the time. After my first few projects, I realized I had to review all tasks, so I became both a project manager and a tester.
It was shocking that if I made 10 mistakes while coding for U.S. clients, my developers made that many in every 5-hour task.
For results-oriented clients, mistakes early in the project destroyed trust. It became impossible to charge for additional work because clients blamed our errors and demanded fixes for free. And since we wanted to be the best, we “redeemed our mistakes”—often at our own expense.
The first few years working with clients were mainly successful—until we started growing rapidly. Fast growth meant we expanded from just me to three developers. It felt like a big leap, considering we had initially shared an office with a designer, and now developers fully occupied our space.
As we grew, we took on every possible client and project, which led to our first failures—some clients needed to be let go, and some projects should have never been started. Mistakes, fixing them for free, and our inability to defend against additional unpaid work kept us from reaching proper profitability—we were working to cover our salaries.
However, these lessons laid the foundation for our most significant projects, which will be described in upcoming posts. Most importantly, we did not repeat our mistakes—and by 2015-2016, we had already become the leading PrestaShop solutions agency. Clients recognized PrestaRock as one of the few companies that knew how to code correctly and deliver high-quality services.