Hello,
I have been wondering for days what my first post on this blog should be about. Should I write about something I learned lately, a project I am working on, or my thoughts on some hot topic? Or maybe it is better to describe some technology? Maybe a movie I watched?
This kind of decision-making paralysis is something that has accompanied me through my whole life so far. Luckily, I am getting better at dealing with it. The solution is quite obvious - just pick the first idea or roll a die and just get started to see how it goes.
Ultimately, a good starting point is by asking oneself a question - “How did I get here?” - so, how did I get here?

How It All Started Link to heading

My professional journey started with me getting a job at Instapage as a Quality Assurance Engineer. I did not know much about QA or web development at the time. To be brutally honest, before Instapage, I was a failure. I dropped out of Warsaw University of Technology due to personal issues, went back to my hometown of Białystok, and did some part-time jobs like disassembling old homes for bricks. These were dark times, but I made it through thanks to Paweł Wiszowaty and Marek Dajnowski, whom I could never thank enough for their courage, goodwill, and faith in me. If you ever read this post, guys, thanks again – you changed my life.

QA at Instapage Link to heading

Instapage at the time was a small company led by Tyson Quick, hiring about 6 engineers, all based in Białystok. It still is a SaaS that helps small and mid-sized companies create landing pages with a pixel-perfect, drag-and-drop landing page builder. Instapage also allows users to publish landing pages, collect leads, and analyze data. With this context in mind, I was tasked with creating an E2E testing solution using Selenium Webdriver and NodeJS. There was no Playwright or easy-to-use CI/CD pipeline solutions like we have today.

Building “Adonis”: My First Scaling Challenge Link to heading

With some help from our admin, I hosted a Jenkins instance that ran a battery of tests with a NodeJS app called Adonis.
Adonis was an orchestrator created by me that spawned worker virtual machines. Each virtual machine started a headless Chrome instance, navigated to a testing instance of the Instapage application, and ran a Selenium test script. After the test was done, results were reported back to the orchestrator, and the worker was assigned the next test. There was about 10 tests running in parallel.

I cannot tell if the Page Model design pattern was broadly known at the time, but the tests I created were quite similar to it. At first, the tests were pretty simple and required developers to include data-at anchors in HTML so components could be easily found during a test run. Later, I even added a feature for taking and comparing screenshots of a rendered view or landing page. It helped the QA team spot regressions before deploying to production.

Shifting to Backend Link to heading

I could have stayed in QA, but I realized I had way more fun creating the orchestrator itself than writing and maintaining the actual tests. This spark of curiosity impelled me to learn PHP and officially transition to backend development.

The Instapage application was built using the Phalcon framework, MySQL, Redis, and an Apache HTTP server, with a frontend created in jQuery and Angular 2.
I joined my colleague Adam Jabłoński on his one-person integrations team. The integrations team was responsible for the creation and upkeep of third-party API connections like Salesforce, Mailchimp, and others. Our users were able to use API keys or OAuth2 to connect Instapage with these CRMs, allowing leads collected on their landing pages to be sent to the correct contact lists.
The biggest challenge was the upkeep: working with API documentation (or the lack thereof), debugging, and creating new integrations – a struggle that still continues to be carried out by others today.

My first steps in the backend were intensive. I learned how to write maintainable and readable code, how to debug it, how to perform code reviews, deliver under pressure, and test my own solutions. I also learned how to collaborate with other developers and communicate clearly.

My First Big Feature: Heatmaps Link to heading

Adonis aside, which wasn’t a product feature of great importance or one that could make or lose money at scale, my first big project was Heatmaps. The problem was complex. Users viewed landing pages on different devices, resolutions, and browsers, and we needed to collect scroll depth data, mouse movements, and click events. These events had to be stored, normalized, processed, and displayed as a heatmap on top of a rendered page.

My colleague Tomasz Grochocki was responsible for the frontend, I handled event collection and normalization, and Adam took care of the infrastructure and map-reduce jobs. We didn’t know much about Big Data at the time, and I think we hit every single pitfall associated with it. We faced scaling problems, DDoSed our own service a few times, and ran into heavy performance issues with map-reduce.

Our initial solution was very simple. An event-collecting script sent events in batches to a data collection endpoint. Node services then normalized the events and stored them in MongoDB, where they were map-reduced. Against all odds, this eventually worked. Now I know that we essentially created a poor man’s version of the Lambda architecture.

A few years later, I returned to Instapage and worked on the next iteration of Heatmaps and analytics. In the meantime, someone had rewritten our solution into a Kappa architecture using GCP services and Apache Beam.

Working Towards Seniority Link to heading

Instapage grew. We moved to our own building, teams expanded, microservices exploded, Node.js exploded, Angular got a few new versions, PHP received regular updates, and Domain-Driven Design became popular. Needless to say, things were exciting.

By then, the integrations team was five people large, and we worked in Scrum with two-week sprints. I was the only one left from the original team, working alongside new frontend and backend hires, an integrations team lead-in-training, a Scrum Master, and a dedicated QA engineer.

Our first goal? Refactor the old integrations code. The startuppy legacy code was a mess and hard to maintain, filled with PHP 5.3 idioms, “clever” solutions, pitfalls, and inconsistencies. Delivering new integrations became harder and harder, and keeping the frontend consistent with other parts of the application was no easier. There was no other way than to refactor, or even rewrite, some parts.

We had to hit the books. We learned design patterns, did our homework on software architecture and coding standards, and studied REST APIs – you name it. It more or less paid off. The integrations code was modularized, the API was documented using the OpenAPI standard, and user secrets handling became much more secure with OAuth2. The frontend adopted company-wide components, and we even created a form builder, since integrations were strictly connected to landing page forms. Things were good.

Postclick and Farewell to Instapage Link to heading

At the peak of Instapage, our founder decided to build the next generation of his original idea and tap into the ad spend optimization market. The idea was sound on paper, and to me, it felt like an opportunity for further growth.

The majority of company resources were put into creating this new system. We knew what was needed and planned for massive scale. We went straight for microservices, embracing GCP and the power of Kubernetes. As the integrations team, we created a new form builder, a Kafka-based leads collection solution, and we even played around with an event-loop-based PHP framework called Swoole. The system was being documented with C4 diagrams, and I felt like we were doing solid engineering work.

Unfortunately, then the “San Francisco tech sharks” happened. Engineering VPs changed twice, COVID-19 erupted, people got laid off, and the atmosphere started to get grim. I applied for a Team Lead position but didn’t get it. The reason? I didn’t have previous team lead experience, and my years at the company didn’t count.

After that, I decided it was time for me to go. In the end, this part of my journey turned bitter, and I left the company unsatisfied. On the other hand, I made great friendships, a few of which last to this day – shout out to Łukasz Sternicki! At the time, I didn’t know I would be back at Instapage again for a short stint in the future.