From tech heap to tech harmony: How OWOW unified under React

From tech heap to tech harmony: How OWOW unified under React

Recently, my team captain and head-of-tech Dees wrote an article about how switching to a unified React tech stack improved adaptability and efficiency. As lead developer, freshly arrived at OWOW, I was among the core initiators, at the forefront of OWOW’s technological transition from a scattered “tech heap” into a focused tech stack. I want to share my experiences and hindsight perspective on this transition, which has taken place over the past two years.

Why?

Let’s hop into our DeLorean and go back in time a few years, to look at the status of affairs regarding OWOW’s tech in mid 2023. *WHOOOOSH*

Our tech department, which amounts to roughly 40% (!) of all people within OWOW was split into two teams: One for websites & e-commerce and another for app development; let’s call these the “web” and “app” teams respectively.

The web team was using predominantly low-code platforms like WordPress and Shopify themes. It’s worth mentioning that, while both of these platforms are indeed low-code, we did have a considerable amount of code for custom page templates and theme development. This resulted in a kind of hybrid low-code setup, where complexities like request handling, routing and authorization are solved by their respective platforms, while our code is mostly used for content-templates and visual identity.

For websites, the web team used WordPress, featuring a little bit of Vue or plain JavaScript code for interaction, animations and such. For E-Commerce, we had our built-in-house, minimal Shopify theme which uses Liquid template code and also, a bit of Vue and plain JS for stuff like shopping carts or other interactive elements.

The app team, on the contrary, is exclusively high-code. We used PHP and Laravel for back-end and API development, while front-ends were scaffolded with the likes of JavaScript, TypeScript, Vue and Bootstrap.

Some foreshadowing: React makes an appearance in the occasional project for either team.

Opportunities arise

So, what’s wrong? PHP and Laravel were, and still are a solid choice for the back-end. Vue is an amazing UI framework that is still relevant and thriving today. Shopify themes can dramatically reduce time-to-market. There is plenty of overlapping tech choices between the teams (PHP, Vue). And to top it off: Developers are happily doing their thing in their comfy tech stack… Aha! This is what’s wrong!

Developers happy? Comfy? Not at OWOW, and definitely not on my watch!

Just kidding, of course :)

The actual problem is precisely in the fact that: Each team within our dev department is using their “own” technologies. You may think “different products, different tech”, but you have to understand that OWOW is but a small agency, that takes on big projects. The discrepancy between the teams is exactly the difference between their practices when building software.

Enter React.

As was foreshadowed: We use React occasionally. We especially experimented with React in mobile app development. We have a history of building both iOS and Android native applications, which have accumulated to significant technical debt, maintenance struggles and reliance on a few expert employees whose skill set fit the bill. So, in an effort to unburden our app devs and resolve the accumulating tech debt, we decided to give React Native a shot. Coincidentally, we did a few React web projects in parallel due to circumstances. These new projects were all done in TypeScript, too.

Some advantages became clear immediately:

  • Planning became easier: Developers who work on React projects became interchangeable
  • Experience with React Native carried over to React for web, and vice versa.
  • Architectural similarities became apparent, making on-boardings easier.
  • Static types massively improved our code

These developments ultimately opened up the discussion about moving towards unified tech choices, with React at the center. Oh, and whenever we chose React, we always paired it with TypeScript.

Ripping off the band-aid

Given the current situation and the opportunities and challenges at hand, we finally decided to go for it. The potential value of a shift to Typescript and React seemed clear; and if not now then when? A transition would obviously be challenging, but the potential seemed worth it. And so the die was cast: From now on, new projects would be built with Typescript, with React for interactive user interfaces.

“Hello, new phone, who dis? Mr. Steep Learning Curve from Ops Pressure inc.? What do you mean, paradigm shift? Uhh… who doesn’t want what? Toolset rebuild? You must have the WRONG NUMBER” *frantically ends call*

It wasn’t easy.

  • The team had to learn React, this did not come easy for everyone
  • We lost efficiency
  • …which created pressure from PM’s to meet critical deadlines
  • …which created pressure from Ops to stay within budget
  • We had to rebuild internal toolsets
  • Internal political games and scheming to opt for our classic tech, rather than React/TS
    • (yes, I noticed. love you all though <3)

We struggled like this for a solid year. Though, we struggled forwards.

Back to the future

*WHOOOSH* - Welcome back in 2025, or whenever you’re reading this.

We are now landed, settled and got completely comfortable in our new tech stack. For the most part, everyone is now happy and productive. The only annoyed developer grunts we hear now, are about React’s garbage collection, memory churn or virtual DOM inefficiencies. Or NextJS’ vendor lock-in conspiracies. But that’s another story. And who even knows what those things are, anyway. So, fantastic! Exactly how everything is supposed to be.

On a more serious note: In the end, our transition worked out well and was definitely worth the effort. It has done wonders for our recruitment, talent scouting and individual team member growth. Our code quality has improved drastically, and React’s rich ecosystem has saved us from reinventing the wheel on several occasions.

Some numbers, compared to 2 years ago

  • Overall job satisfaction score has improved from 7.7 to 8.5
  • Growth perception score has improved from 7.0 to 7.8
  • Projects enjoyment score has improved from 6.8 to 7.9
  • Dev department satisfaction score has improved from 6.7 to 7.6
  • Received roughly 8x the amount of applications on web developer positions
  • Roughly 3x more applicants reaching second or third round interviews
  • Code reusability increased by 70%
  • Amount of developers who can now work across web and app teams increased by 30%

The chaos of unwieldy WordPress plugin-hell is now history, and has made way for a well organized code-first CMS. Cohesion between web and app teams is at an all time high, and we’re actively taking steps towards merging into a single dev department. Another peripheral benefit of our transition to TypeScript + React, is that we could create room to improve our general DevOps and infrastructure foundations.

In hindsight, we definitely should have approached our transition with more care. A concrete plan and critical risk analysis would have made the entire process a lot smoother, less frustrating. At times, we were driving a nail with a sledgehammer, while some level of strategic decision-making on which projects were suitable for our new tech would have been nice…

But, hindsight is 20/20, the obstacle is usually the way, and in the end it all turned out great.

Here’s to taking our products to the next level!