A Startup Journey Part 1, just making it work

Sander Mulders
GeoPhy
Published in
4 min readMay 17, 2017

This is part of a longer series focused on the technical components of where we started and where we are going.

Four years ago, we decided to tackle the challenge of how to find the best office space in the Netherlands. At the time, a digital solution for commercial space did not exist. We wanted to take the manual work out of finding and comparing space options for commercial tenants.

We thought it would be fairly simple, given the tangibility of real estate, the size of the industry and the (seemingly) large presence of information in the market. We quickly learned that despite the vast amounts of information available, a majority of industry decision makers continued to rely on gut feelings, opinions, personal relationships, and excel spreadsheets. We’ve come across so many excel spreadsheet set-ups driving ridiculously large portfolios, it deserves a special call out.

We had a different approach, we believed in letting the data speak. At only 40,000 buildings, our first dataset was relatively small and easy to manage. We came up with a way to take data from the building itself and combine it with 50 or so peripheral characteristics to rank buildings against one another using an objective algorithm: the OfficeRank.

As you would expect, the initial modelling was done in simple spreadsheets (keeping it consistent with the industry), but we knew a “proper” database could take the results to another level. To do this, we kept it basic, sticking with a MySql, PHP, JS, HTML stack. This allowed us to quickly build out a prototype for the Dutch office market.

The first working prototype

Almost immediately, we gained traction with large institutional investors and industry stakeholders. They understood the importance, and inevitability, of big data, but had yet to integrate it into their day to day decision making process. OfficeRank, which was our very first product, showed them how.

We were lucky. We had clients that saw the same opportunities we saw, which allowed us to build out our product, literally in real time. Developing and deploying code minutes before presentation was not uncommon and proper CI/CD was still a mythical concept.

One of the detail pages of our dashboard

Before we realised, a year had passed. We encountered the same obstacles and opportunities on the paths that every successful startup journeys … running a rapidly expanding digital platform on the same codebase. Yes, 1 codebase. Which of course was harder to maintain as it had organically grown over time and interest in the product kept on growing, which then caused us to develop many more features, handle support requests, do side projects and so on! As a result, the complexity of our infrastructure and code base increased.

Our tech-team of 3 decided it was time to rebuild our platform and underlying database. At the same time, we decided to expand beyond the Netherlands and into other asset classes.

Just like any other startup, we were constantly adjusting our product to find the right market fit. From a backend standpoint, this made things tricky, as we were rebuilding not knowing what the future may hold.

Given our technical background, we stuck to what we knew, putting little focus on defining features or uses cases. We focused on redesigning our database structure from the ground up while sticking to mysql. We decided on Laravel as our PHP framework and redesigned our UI. We adopted queueing to spread the workload over multiple work instances as the aggregations were out of control due to the growing data sets. The architecture was still a monolith but one that allowed us to grow and build our platform into something that is now handling millions of buildings and serving customers worldwide.

We went from a team of of 3 to 60 (btw we’re hiring ), and we have no intention of stopping. We want to map the world. Rough estimate indicate 4.6B properties worldwide, not including the contextual data element. Looking ahead, we certainly have our work cut out for us. Looking back though I still wouldn’t change the way we approached the tasks at hand. Our agility is what made this possible: quickly adding features, testing them in the market without trying to build the perfect technical solution. Just make it work!

Keep connected, as I’ll detail our first architectural choices next.

--

--