Immovato

With Immovato I co-founded a SaaS startup, where we strived to innovate the real estate sector in Germany. Immovato was an online platform giving property sellers and landlords a set of tools, that is usually reserved for estate agencies. All of this was offered at a low monthly cost. While similar services are very familiar in the UK, the German market did not have any SaaS solutions for real estate offerings.

## The first approach

Back in 2014, my co-founder, an established estate agent in Germany, and I sat together brainstorming how we would be able to innovate the real estate sector in Germany. As a UK resident myself, I was aware of innovative solutions in the UK, so we did a first market analysis for Germany and compared offerings in the UK and Spain to see what our product would look like. What we came up with was the following service for our MVP:

-   Automatic listings on the most popular German real estate marketplaces (Scout24, Immonet and Immowelt)
-   Custom API to offer commercial clients flexibility with implementations of third party applications
-   Customer account management including subscription-based payment gateway
-   Marketplace for property photographers, stagers and local estate agents to offer their services on a project basis

The next stage of research was focusing on the three German real estate marketplaces and how we would be able to communicate with them. One of the biggest struggles was, that some of them did not offer any API we would be able to hook into, so we would have to rely on webhooks, SFTP and email - not ideal to achieve our goal of a fully automated system. The marketplace that offered an API was using a very dated XML-based SOAP API ([OpenImmo](http://www.openimmo.de/ "http://www.openimmo.de/")).

## Branding

Since I had a background in design and development, I focused on the branding of our product next. While the iconic standalone logo was developed in one night, the actual brand name took much longer to nail down. The combination of “Immobilie” (German for “property”) and “Innovation” was finally chosen and Immovato was born.

The colour palette has been updated twice over the following years to keep up with current trends, but the overall design remained largely the same from 2014 to now.

## Development

Together with two contractors and one part-time employee, we began the development work in November 2014. The tech stack we chose at the time was a Laravel (PHP) back-end with an AngularJS front-end. This was largely due to the experience of the engineers we chose to work with and also my own experience at the time, which was largely within the PHP world.

Unfortunately, we ran into several issues creating APIs to send our real estate listings to marketplaces, so the project became slower and slower in early 2015, which resulted in a financial bottleneck (at this point we had bootstrapped the app using our own funds) and the completion of the MVP was finally put on hold until we were able to raise funds to continue.

Through a small pre-seed round of around €50,000, we were able to continue around December 2015.

In the meantime, there has been a lot of movement in the technologies we were using. AngularJS had a new major version release, which was largely incompatible with our Angular 1 code, so we had to make an important decision:

Do we continue with AngularJS 1, do we upgrade to Angular 2 and hope that the framework does not change completely again with the next major version or switch to a different framework altogether?

At the time React has started to become the de facto choice for many startups and after some investigation and PoC development time we were convinced, that React would be an excellent choice for our product and despite it being very different to Angular, it would be a feasible effort to move our front-end codebase over.

But what about the back-end?

Since we have all worked in JavaScript much more and Node.js with the Express framework became much more popular, we decided to scrap the Laravel back-end while we’re at it and build on a MERN stack (MongoDB, Express, React, Node) instead. At the time it seemed sensible to make this decision now rather than continuing to build in PHP and JavaScript separately, later requiring different skillsets when we would eventually hire a larger engineering team.

Until the summer of 2016, we were working on the MVP but kept failing to integrate our product with the third-party services we required, due to the lack of APIs on their end, as described above. Additionally, we were running low on cash again and required the ready MVP to start raising a seed round.

Eventually, the decision was made to rely on manual input for the MVP stage. This meant a customer would sign up, book a package through our app and then my co-founder would manually add listings for marketplaces. This way we were able to have a soft launch of the product and serve a few customers to generate a small amount of capital to continue with the development process.

Unfortunately, we were not able to raise further capital in a seed round at the time and Immovato was put on hold.

## What are my key learnings?

Running a business and building a SaaS solution with limited resources is hard. However, I have gained valuable experience managing software engineers and also managing the expectations of stakeholders. The leadership experience I have gained with Immovato has been valuable in my further career in senior and lead engineering roles I have since worked in.

The experience of moving a codebase from Angular to React has also taught me a lot about best practices and the value of high-quality code. Without this experience, I would not have learned React as early as I did, which has given me a significant benefit when I first started working as a contractor.


I co-founded Immovato, an online estate agency SaaS solution in Germany and served as CTO for many years.

Innovating the Real Estate Sector

Raconteur

Raconteur is a London-based publisher for special-interest content for business leaders, well known for their infographics and special reports in The Times / The Sunday Times newspaper. I have been working as part of their creative division in a small engineering team. When I first joined Raconteur the key objective was to move their WordPress-based monolithic solutions to a React-based modern structure.

## The project

Raconteur Insights is a bespoke publishing platform I have developed in-house alongside their UX team. The challenge was, that designers were developing animated infographics using Tumult Hype. These consisted of a HTML document and an embedded script file, that was bundled and uploaded to an SFTP server.

The overall content structure would always be the same, but there are various different types of content that are collated for a given report. Each report has an intro screen, displaying an animation and the title of the report, followed by a table of contents. This is followed up by articles and infographics, sorted in a predefined order.

The aspiration of Raconteur Insights was that this would feel like a print publication with the added benefit of dynamic animations. The design team consisting of print designers and one UX designer had very specific expectations that needed to be met.

## The first approach

Since this was a greenfield project, none of the systems design decisions have been made, so I started from scratch.

### What we knew:

-   We wanted to build a custom publishing platform
-   The technology stack should be based on React
-   All other systems are based on WordPress
-   Animations are done by the design team in Tumult Hype

### What we had to work out:

-   Is WordPress the right tool for this headless implementation?
-   How regularly are we publishing these dynamic reports? → Do we want to build a server-side rendered (SSR) application or static pages (performance benefits)
-   What are the business requirements for test coverage and maintainability?
-   How do we bring our Hype animations into a React app?
-   How do we host the app?

Based on these questions I started a week-long spike into how best to structure the app. First I was looking at the meta frameworks Next.js and Gatsby. At the time Next.js did not have good support for SSG (static-site generation) and Gatsby did not have support for SSR (server-side rendering). After initial trials and weighing up pros and cons we decided to go down the route of statically generated pages using Gatsby. The primary deciding factor here was the fact, that we intended to create one report per month, keeping the necessity for rebuilds quite low and build times under 10 minutes per month. Had we decided to publish more frequently (say once a day), we would have preferred Next.js’ SSR approach, since the length of Gatsby’s builds would increase significantly after around 9-12 months.

Another deciding factor for Gatsby was, that at the time, Gatsby had the best support for TypeScript, which was an appealing choice to make sure we have a type-safe system in place. In addition we chose to add unit- and integration tests with Jest.

The next decision I had to make was for a content management system. Since all other websites Raconteur manages were based on WordPress (some headless, some monolithic), this seemed like the obvious choice. However, after looking into the custom post types we required to make this publishing platform work as intended, we would have had to utilise Advanced Custom Fields to a large extent and the RESTful API availability within ACF was rather limited at the time and would have led to constant over-fetching of data. For that reason we decided to look at different headless-first CMS solutions. The ones I looked at and trialed are:

-   Contentful
-   Sanity
-   Prismic
-   Strapi

All of these systems seemed very appealing for different reasons, however we decided early on, that we did not want to maintain a self-hosted CMS outside of our WordPress host, so Strapi was ruled out early, despite being open-source and very appealing otherwise.

After some research and testing all these CMS’s and comparing pricing and features, we decided to use Contentful for Raconteur Insights.

The next question to answer: what about Hype animations? I had been thinking of the best way to bring these into our app since the very beginning and after some investigation I noticed, that the HTML structure is always the same, just the script would be different for each animation. Therefore the component structure was quite straight forward:

    export default function HypeAnimation({ animationName, slug }: IProps) {
      // When mounted, get the container and create a script element with the link to the SFTP hosted hype file
      useEffect(() => {
        const container: HTMLElement = document.getElementById(`${animationName}_hype_container`);
        const script = document.createElement("script");

        script.src = `https://${process.env.SFTP_PATH}/${slug}/${animationName}/${animationName}.hyperesources/${animationName}_hype_generated_script.js`;
        script.async = true;

        container.appendChild(script);
      }, [])

      // Return a div with the correct structure for the hype animation
      return (
        <div
          id={`${animationName}_hype_container`}
          className="HYPE_document"
        />
      );
    }

This way we would be able to insert any amount of animated infographics with the least amount of effort and impact on performance.


Raconteur Insights is a bespoke publishing platform I have developed in-house alongside Raconteur's UX team. The challenge was, that designers were developing animated infographics using Tumult Hype.

Bespoke Publishing Platform

Dennis Publishing

At Dennis Publishing we developed a custom SSR platform based on React.

React Platform Development

Holland & Barrett

I joined Holland & Barrett during the early stages of a digital transformation process in 2020. As part of this transition, we were rebuilding the customer-facing front-end using React-based micro-frontends, that communicate with a mix of new and legacy backend services.

Up until this point, Holland & Barrett have used a third-party provider for their subscriptions service. When I joined the team I had been tasked to reimagine the front-end for subscriptions and worked within a cross-functional squad of back-end engineers and a UX designer to rebuild this service end-to-end.



_This case study is protected, please get in contact with me to read the full case study._


Up until this point, Holland & Barrett have used a third-party provider for their subscriptions service. When I joined the team I had been tasked to reimagine the front-end for subscriptions and worked within a cross-functional squad of back-end engineers and a UX designer to rebuild this service end-to-end.

Case Studies