Nature.House
Five years leading the full modernisation of a major European vacation rental platform — from raw script tags and a 27 MB JS payload to 0.7s mobile load times, 150 Storybook components, and a deploy on every MR
- Role
- Senior Software Engineer
- Type
- E-commerce
Overview
I spent five years at Nature.House as the sole front-end engineer and later the lead of a team of five, owning every significant front-end initiative on a large custom Symfony booking platform. We went from jQuery, no build tooling, zero tests, and a 12–14 second mobile load time to a 150-component Web Component design system, 95%+ front-end code coverage, GitLab CI deploying on every MR, and a 0.7 second mobile load time.
Details
Project Images





Goals
Bring mobile load time under 1 second
The site took 12–14 seconds to load on mobile. The root causes were uncompressed images and 27 MB of Symfony translation files loaded on every page request, regardless of content. Getting this to a usable state was the first and most urgent priority.
Replace the inherited jQuery codebase with a scalable architecture
The front-end was a bespoke jQuery system built by an external agency, with no documentation, no standards, and no separation of concerns. The goal was a fully modern, maintainable architecture that could support a growing team and years of product development.
Establish a testing culture from zero
There were no automated tests anywhere in the front-end codebase — no unit tests, no E2E tests, no smoke tests. Building a testing culture and reaching meaningful coverage was both a quality goal and a prerequisite for safe continuous deployment.
Give the marketing team full content autonomy
Developers were the bottleneck for any change to landing pages and SEO content. The goal was a content infrastructure where the marketing team could create, rearrange, and publish pages entirely on their own schedule.
Responsibilities
Front-end architecture across all repositories
Owned every significant architectural decision on the front-end — tooling choices, component library structure, testing strategy, CI/CD pipeline design, and the standards the team coded to. As the team grew, these decisions shaped how five engineers worked day to day.
Technical roadmap collaboration with the Product Owner
Actively participated in planning and prioritising the product backlog alongside the Product Owner — translating technical debt, refactor work, and infrastructure needs into roadmap items with real business impact. Bridged the gap between what engineering needed and what the product team could prioritise.
Grew the front-end team from 1 to 5
Joined as the sole front-end developer alongside a two-person backend team. Over five years I helped grow and shape the front-end team to five engineers, while the wider organisation expanded to include a UI designer, product owner, and dedicated QA engineer. Led hiring, interviews, and ongoing mentorship.
Key Features
Storyblok headless CMS — marketing without developers
Integrated Storyblok as a headless CMS across all search landing pages and the homepage. Every section is a drag-and-drop block in the Storyblok editor with a live preview integration. The marketing team manages SEO content and page layouts entirely independently, on their own schedule.
Progressive Web App
Implemented PWA capabilities across the platform — offline support, installability, and service worker caching — so the site works reliably on poor mobile connections, which matters for travellers browsing accommodations from remote areas.
A/B testing with Convert.com and Google Optimize
Set up and ran conversion experiments across key booking funnel pages using Convert.com and Google Optimize. Tested layouts, CTAs, and search interaction patterns to make data-driven decisions rather than opinions — directly informing roadmap priorities.
Challenges
A live platform that could never go down
Every major refactor — the jQuery replacement, the Symfony migrations, the infrastructure move to GCP, the full rebrand — had to happen while the booking platform was live and generating revenue. There was no freeze window, no big-bang cutover option.
Symfony 2 end-of-life with 50% of the app coupled to it
Symfony 2 reached end-of-life with no security support. Migrating to Symfony 4 required rewriting approximately half the application due to deep architectural differences between the two versions — a year-long effort on top of regular product work.
Running a complex platform as the only front-end developer
For the first two years I was the sole front-end engineer on a large, complex booking system. Every decision — architecture, tooling, standards, hiring criteria — was mine to own without a front-end team to consult or distribute work to.
Rebuilding the foundation while shipping new features
The refactor ran in parallel with continuous product development. Components couldn't be rewritten in isolation on a separate branch — the jQuery system and the Web Component system had to coexist in production for the duration of the migration, with no regression in functionality.
Solutions
Build-time translation injection — 27 MB to zero
Instead of shipping the entire Symfony translation dictionary to the browser at runtime, translations are now injected at build time — only the specific keys each page actually uses. This eliminated 27 MB of JavaScript from every page request and was the single largest driver of the performance improvement.
Storybook as the source of truth for every component
Each Web Component was built, tested, and documented in complete isolation inside Storybook before it was ever imported into the Symfony application. Storybook became the single source of truth for the design system — the library shipped as a standalone package, independently of the host application.
Incremental migration — jQuery and Web Components in parallel
Rather than attempting a full rewrite, the jQuery components were replaced one by one with native Web Components while both systems ran in production simultaneously. This allowed the team to ship new features and fix bugs throughout the migration without a feature freeze.
CI/CD as the quality gate
With 95%+ code coverage in place, the GitLab CI pipeline became a genuine quality gate rather than just an automation convenience. Every MR triggers the full test suite before deployment. The combination of high coverage and automated deployment made it safe to ship multiple times a day.
Results & Metrics
Mobile load time
Before12–14s→After0.7sFront-end JS translation payload
Before27MB→After0MBRelease cadence
Beforemonthly→Afterper MRStorybook components
Value150Front-end code coverage
Before0%→After95+%Front-end team size
Before1→After5
Design Colors
Typography
- Let nature wake you up.
- Find your cottage in nature.