Developing a greenfield project for a PropTech start-up in stealth mode
Published: 2020-02-21 15:37:40

My team is building a PropTech platform from scratch, and it's pretty refreshing to work on a greenfield project. I'll tell you why in a bit. But first off, I need to confess something. We need help. I mean a lot of help. I'm going to describe what we've done so far to give you a better idea of what we need.
 
## OK, what's PropTech?
 
There are a lot of words with the suffix "-tech" these days - "adtech", "kidtech", "insurtech" (Bleuchhhh). So PropTech is basically techified real estate. It means applying the cutting-edge UX, technical innovation that you might see in a platform like Uber and applying it to the real estate industry. And believe me, the real estate industry over here in Germany is oooooold school. Customer service here sucks (at least compared to the states). In fairness, some sectors have really improved the quality of their customer service in the last decade. Not the real estate industry though. Because we're in Germany, there needs to be just enough bureaucracy to almost drive you insane but not quite. So many pieces of paper to get signed by grim-faced men with giant, quivering mustaches.
 
![Mustache man](https://miro.medium.com/max/809/0*QRWGOp-zg_ZqqciC)*WHERE is your Unbedenklichkeitsbescheinigung? I must have it!*
 
OK, I'm exaggerating a bit, but still, you have to get used to managing huge stacks of paper. It's high time for the German real estate industry to get the ole' Uber treatment (ideally without the controversy). So we figured we'd help to modernize the industry and build something cool. Don't worry, I'm going to talk about who "we" are later on, but first I want to describe the platform.
 
## What kind of PropTech platform are we talking about here?
 
The specifics of what you can do in the platform are all hush, hush for now (we're supposed to be in stealth mode). But let's just say real estate agents, sellers, and anyone else who needs to be involved in the process can log in and get their shit done. This will hopefully minimize faxes and phone calls because everything will be integrated into a streamlined workflow in the platform.
 
For now, I want to focus on the technical aspects. When I say it's a greenfield project, I want to add that caveat that we've selected the technologies already. But they are modern, popular technologies - nothing arcane or proprietary. Let's go over how we're structuring the platform, starting with the front end.
 
## The front end
![Frontend](https://miro.medium.com/max/1596/0*P8ZEEryUc3J58VUq)
 
The front end consists of several single-page web apps that are targeted at different user roles (such as agent, seller, and so on). These apps are being built in the React framework [Next.js](https://nextjs.org/) because we wanted a scalable solution that uses server-side rendering. We've also had good experiences with Next.js in the past. We're integrating with a headless CMS ([Contentful](https://www.contentful.com/)) so that back-office users can easily add content.
I asked our current front end dev, Gieselbert* how he feels about working on this greenfield project and he had this to say:
 
> "I appreciate the opportunity to not repeat the mistakes I've seen in other web apps, such as the misuse of typescript. In my last project, I worked on an existing front end that was designed by a back end engineer - so it used back-end design patterns. That wasn't so great. I'm glad we have the opportunity to start things from scratch this time. It's nice to work with NextJS too, you can start coding with very little configuration."
 
_*Name has been changed for confidentiality reasons._
 
## The back end
![Backend](https://miro.medium.com/max/1483/0*uprkfhvc_1MW0N1W)
 
For the back end, we were able to leverage one of our newest open-source projects which we named "Herbie" (coming up with a name was quite an ordeal by the way, one that we covered [in another article](https://medium.com/@merlin.pav/87cb8848fab6?source=friends_link&sk=83049123e06a43e5ecc4d5771774869b)).
 
Herbie is an abstract data layer that makes it easier to exchange data across distributed systems. It's built with Django and Python and comes with a simple API to create business entities. You can read more about it in our [GitHub repo](https://github.com/herbie/herbie). Currently, we're using it to integrate the web app with the Salesforce CRM, but we'll soon need other connectors too.
 
I wanted a backend engineer's perspective on the "greenfield" question, so I asked one of the main engineers Hugobald*. Of course, he likes talking about Herbie, because he helped build it.
 
> "It's very convenient to use something like Herbie as a mediator between the main web app and the different consumers. In the past, I've had to integrate external systems directly with the main app. When you make a change to a data structure, you can end it up in a tangled dependency hell. So far, I've only integrated Salesforce but it's going to be much easier to connect more systems."
 
On the subject of greenfield projects in general, he added this:
 
>"My last project involved implementing a SSO solution, so there was a lot of troubleshooting and bug fixing. Don't get me wrong, I enjoy finding creative solutions to difficult problems, but working on this new project has tested my creativity in many different ways - you literally get to influence the architecture of the entire system. Plus, the team is still small, so I'm much closer to the product managers and stakeholders. In other projects it can take ages to get answers to questions about requirements, but the communications overhead here is much lower. Also, while defining the data structures, I've learned a great deal about the "ontology" of the real estate industry - come to think of it, I've learned a lot generally. I'm a way, it's a shame I have to leave this project, I think it would be a great career boost because you have so much influence as a founding contributor to the platform. I think one could transition into a leadership role fairly quickly."
 
But he also had one cautionary note:
 
> "Because it's a completely new product, not all the details have been finalized - the specs can change pretty quickly, and you occasionally end up having to undo changes. Sometimes, it's hard to keep up with the newest requirements. You have to do a lot of double checking with the product managers. But these issues are usually clarified in our daily standups."
 
_*Again, name has been changed for confidentiality reasons._
 
## The infrastructure
![Infrastructure](https://miro.medium.com/max/1486/0*JF_UW78u0UQuI2zf)
 
We decided to run the web app in a Kubernetes cluster on Google Cloud. We use Terraform to provision the infrastructure as code, and we use the Terraform Helm provider to deploy software packages to Kubernetes. This allows us to spin up new staging of QA environments in minutes.
 
We'll probably use Cypress to automate testing for the web app, but to be honest we haven't yet finalized our test automation suite. Of course, we're going to integrate test automation as part of our GitHub-based CI/CD pipelines.
 
## The ways of working
![Ways of working](https://miro.medium.com/max/1481/0*v56J4FkKrop0GXwb)
 
Our development methodology follows SOLID principles. We've been using these principles for many other projects and we've found them to be pretty reliable, so this project is no exception.
 
Additionally, we foster a DevOps culture amongst our developers. If you're unsure what that means, check out this [article on martinfowler.com](https://www.martinfowler.com/bliki/DevOpsCulture.html). Essentially it means that developers take a more active role in testing and deploying their code. While there are some developers out there who are quite happy to delegate these responsibilities to specialists, we find that most developers enjoy the extra responsibilities. They learn more about DevOps, have more influence on the product life cycle and have a vested interest in making sure their code is successfully deployed to production.
 
In tandem with this, we deploy features in small iterations according to the Scrum methodology. A lot of people are down on Scrum these days, but we find it's essential when working on a greenfield project that can change direction quickly. You really need to keep in close contact with all members of the team while deploying and testing often.
 
## Who "we" are
Remember earlier on I promised to tell you who "we" are? Well, now's the time. You see, our devs are what you would call "hired guns", they come in, get a project started then hand it over to permanent employees who make it fly. We work this way because we're an operational VC. We give start-ups money to do their thing, but we also lend them a little helping hand too. We lend them our folks - or should I say "operational experts". So that basically explains why we need help. We don't want our devs to be in the trenches for the long haul, we need to shift them to some other projects eventually. We need to replace them with permanent employees who are just as talented (hopefully even more so). There's just one problem though.
 
## Trying to recruit in stealth mode
…is a gigantic pain in the ass. There is no website to show anyone. There is no name I can mention. The whole project is wrapped in a mystery, buried inside an enigma.
This is the shopping list of all the people we're supposed to get on board:
* Four (Python-loving) back end engineers
* Two front end engineers
* Three turtle doves (just kidding)
* Aaaaand, last but not least, one VP of engineering
 
Quite frankly, I'm not sure how we're going to find all these people without being able to tell them much about the company. If anyone has any experience or tips trying to get devs to join a start-up that's in stealth mode, I would love to hear from you. To provide you with some more background about the project and the company, we also recorded a podcast with our CTO who openly admitted he'd apply for the VP of engineering role if he wasn't already our CTO!
 
## Why stealth mode?
 
The reason this start-up is in stealth mode (or at least "quiet mode") is because we think they will be big and we want to announce it at the right time. Folks are investing heavily in PropTech right now - just have a look at this article on Techcrunch where they state that "…upwards of $16 billion in venture capital has flowed into real estate-related start-ups in 2019 alone". So there's a lot of competition out there.
 
In the states, there are tons of VCs who specialize exclusively in PropTech such as A/O PropTech in Europe and MetaProp in the US. There is a lot of excitement around the potential growth areas for this technology. In fact, I like this quote from one of MetaProps co-founders Zach Aarons.
 
>"PropTech is the most fun sector in the world. No other sector shares the complexities and idiosyncrasies of technology that has to be applied to the built world. We are very lucky we get to do what we do."
 
It summarizes the genuine enthusiasm that many people have for the transformation that this type of technology can bring to the industry. Of course here in Germany, the hype is growing too, but we're always a little bit behind the states when it comes to start-up trends. Nevertheless, the industry has its own portal "[PropTech.de](https://www.proptech.de/)". If you happen to speak German, go ahead and check it out - you'll get a sense of how quickly the space is growing over here. And being a founding employee of a potential unicorn can turbocharge your career later down the track.
 
So there you go - that's our portrait of a greenfield project in PropTech. If you're interested in joining this project, you can reach me at [mirela.stefan@project-a.com](mailto:mirela.stefan@project-a.com) (the roles are also on our [careers page](https://www.project-a.com/careers), just filter by "Hamburg"). Even if you're not keen at all, I hope I piqued your interest in the PropTech industry and gave you an insight into what it's like building a brand new product from scratch.