Work

The Leverage Model

Hands down, the most interesting and impactful project I’ve worked on lasted for over 5 years. I was part of a joint venture between two companies that developed a specialized solution for WordPress-based ecosystems. The objective was to come up with an optimal combination of hardware, software, and network architecture that would provide both extremely high speed and high capacity for e-commerce and content delivery without the need for cloud computing and microservices. Instead, we adopted a monolithic architecture on individual machines, leveraged RAM extensively, and implemented aggressive caching to minimize disk I/O and enhance system performance.

My responsibilities included refining the application layer, rigorously testing and approving WordPress plugins for compatibility, and assisting in OS-level enhancements. We used LXC/LXD containers and synced machines for rapid deployment and resilience, allowing each client’s system to be isolated and securely bridged to an external network, as well as ensure uninterrupted service in the event of a service or machine failure. In production, our system proved capable of handling up to millions of requests per minute on a single machine.

The project’s impact was significant: clients frequently saw ROI and ROAS double or even triple, coupled with cost reductions exceeding 60%, considering both service costs and reduced requirements for engineering maintenance. This project broadened my practical expertise across diverse CS domains and my understanding of the interdependence of these disciplines in real-world applications.

Infynit

One of the most fun and challenging projects I’ve worked on was a prototype streaming video platform. As a proof of concept, the project had considerable constraints: very low budget, tight deadline (less than three weeks), a small team (myself and three others, one of whom was a designer), had to be built using a vanilla WordPress + LAMP stack setup.

Initially we weren’t sure we’d be able to produce anything even worth showcasing internally. The company had a significant catalog already, so content wasn’t an issue. But we knew that categorization and content delivery would be a challenge considering we also had to build the UI in the same short timeframe (and near-zero budget for leaning on cloud providers).

We took design cues from various top streaming services, and split our dev team to focus on UI and functionality in parallel. We set up a new container on the same machine as the test site to host all content assets, to avoid spending money for dedicated media hosting. In WordPress, we stripped down everything we could and used a barebones custom theme, Advanced Custom Fields, and Elementor, along with a lot of questionable JS and PHP, to construct the UI and build out the taxonomy for the streaming library. We moved the database into RAM to reduce load times, and heavily optimized page designs to further increase performance. And when we were done, for good measure we stress-tested the site for dozens of simultaneous users.

In the end, what we ended up with was not very pretty under the hood, but it looked and felt first-class to our internal users. It certainly wasn’t anywhere near production-ready, but I learned a lot about leading a team in building complex systems under daunting restrictions.

UGURUS

I’m often faced with the challenge of meshing multiple systems together that just don’t want to play nicely with each other. When possible, I leverage tools like Zapier to speed up development and reduce project cost (as well as to offload the burden of development and support), but sometimes those tools either don’t work, or they introduce new problems that aren’t worth the time or cost to solve.

In an ideal word, clients would pay whatever is needed to get the job done. In reality, I typically have to “just make it work.” One particular challenge from UGURUS (now a service by Digital Ocean) involved just that - develop a solution for accurate booking attribution in Data Studio (via Google Analytics) that worked across multiple platforms and domains in their client onboarding pipeline, without introducing new products and with a minimum overhead of custom code.

After several back-end attempts didn’t pan out, the solution I ended up developing involved a series of scripts that brought across several domains with the help of Google Tag Manager and various platforms’ APIs. while each step was fairly simple in its implementation, the architecture of the overall solution was not so much, as each platform had varying limitations as to what data could be carried through and how they interacted with each other (APIs, iframes, query strings, etc.). After several rounds of testing and revisions, I was able to deliver a very budget-friendly solution that was flexible enough to accommodate future updates to UGURUS’s booking system.