Startups should do the hard thing

You can build your strengths. You do not have to accept weakness.

This was back in 2022. A friend of a friend told me about a startup (UnifiedSTR) in crisis. I was hired to write a report for the Board Of Directors, to educate them regarding the true state of the technology. When I was given access to the code I was shocked by what I found. It was the absolute worst code that I had ever seen, in my entire 20 year career.

The company began in 2016. The basic idea was genius: more and more people were renting their apartments on platforms such as AirBnb and Booking.com and VRBO, so UnifiedSTR would build a unified platform for all of them. (AirBnb and Booking.com and VRBO are called "short term rentals" and so the industry is called STR.)

Siméon was the founder, enormously charismatic, able to convince investors to trust him, so they had put several million dollars behind him. But he hired his friend Raj to be the CTO, and this was the first mistake. Raj was only 23, he had limited programming experience, and he had no experience as a manager. He was in over his head. But they had millions to hire a tech team, so he was soon managing 18 engineers, some in America, some in Africa.

The tech was horrible, everything was hardcoded: passwords, API keys, URLs. This made it impossible to set up a normal test site. The code language had been PHP, the initial code had been a monolith, but over time the code lost cohesion and melted into a blob.

Raj was afraid of enforcing accountability on some of the developers so some of them worked without much oversight. Kwan was a frontend dev who, around 2019, had learned about Angular and so he rewrote the frontend of one module in Angular. Later, around 2020, he learned React, and so he rewrote the frontend of a different module in React. When I arrived in 2022, there were 7 different strategies in use for different parts of the frontend. Cleaning up this mess would take at least 6 months, maybe a year. And it would be important to set limits on Kwan, demand accountability, or fire him.

A few of the engineers had survived the chaos and become good, almost despite the overall environment in which they worked. Aarron was dedicated and had committed to memory the whole of AirBnB's API. Deepika had memorized the API for Booking.com. These two represented important institutional knowledge — they knew what worked and what failed. They both needed to be promoted.

I put all of this in the report and sent it to the Board Of Directors. They thanked me profusely. One of them said: "This is the first time I feel like I understand what is going on." The Board used my report to justify a reorganization of the company: the CTO was fired, while Siméon was demoted from CEO to Head Of Business Development. Given his charisma, Siméon was still helpful in developing new alliances.

A few weeks later, we also fired Kwan. We had tried to put limits on how many technologies he experimented with, he had not respected those limits, and so we pushed him out.

The Board then hired a new VP Of Engineering but he indicated he needed 2 months to wrap up work at his old job, so we had a long interregnum, and during this time we had many conversations about the correct path forward. I developed a plan to incrementally fix the software; I felt that by January of 2023 we could have the worst problems resolved. However the Product team wanted to go in a different direction, with a new product. At this point I had the following conversation with Allison, who was Head Of Product.

Lawrence: So, wait, what is the new plan?

Allison: We are focusing on those people who are just getting into the Short Term Rental market. We are building an interface that is friendlier than AirBnB. We are going to hold their hand and onboard them gently. We are not going to make any assumptions about how much they know about STR.

Lawrence: So... uh... we want to be the next AirBnB?

Allison: We will help people get set up on AirBnB.

Lawrence: And Booking.com? And VRBO?

Allison: No, we can't handle that.

Lawrence: Who do you mean? Who can't handle that?

Allison: The tech team can't handle that. I've been here for two years now and they've never gotten it right.

Lawrence: Sure, but that's why we got rid of Raj. We got rid of Kwan. We are hiring some really good engineers. We are making major changes to the tech team. It's going to be stronger now.

Allison: We don't know that. And even if it is true, it would take years to build a reliable system that integrates with AirBnB, Booking.com and VRBO.

Lawrence: We have a system, right now, that integrates with AirBnB and Booking.com and VRBO. It has a few bugs, but we can fix those.

Allison: I have been documenting the bugs in this system for two years. Nothing has been fixed.

Lawrence: Yes, but that's why we are building a better team.

Allison: Okay, that's great. I'm really happy about that. And when the team is better, then we can build integrations with all of the STR companies. But right now, the tech team isn't able to build software that works.

Lawrence: When we run marketing campaigns we get incredible response rates. On the last campaign, 2.5% of the people who saw the ads signed up for our service.

Allison: Yes, but after 90 days more than 95% of them quit. It's the churn rate that is killing us. And the churn is because our software is so buggy. People get excited at the thought of renting their apartment on all of the major platforms, and they are eager to sign up for that, but when they realize how buggy our software is, they all quit.

Lawrence: But they are excited! And they are okay with us taking 2% of their revenue. We have established product-market-fit. That is a big deal. We just have to fix a few bugs and then we have a successful business.

Allison: It's more than a few bugs. You just documented this yourself. You said there were fundamental errors in the architecture of the software. It would take a long time to fix. Maybe we need to re-write everything from scratch.

Lawrence: I don't think we need to re-write everything from scratch, but even if we did, what you are suggesting is to build something completely new. A friendly interface for AirBnB. That will also take some months to build.

Allison: Not many. We are keeping it simple and basic.

Lawrence: But will simple and basic be exciting for the users?

Allison: That's a good question and hopefully we can iterate fast on this so we can push it out, get some feedback, and improve it based on that feedback.

Lawrence: But you are walking away from an idea that we know customers love, and which they are willing to pay for, and instead you want to implement an idea that has not been tested. A friendly UX to onboard people to AirBnB? Where is our competitive moat? Why couldn't AirBnB simply implement this themselves? If we have any success then AirBnB can just copy our ideas.

Allison: Or they can buy us. That gives us an exit strategy.

Lawrence: Or we can just grow the business we have right now, that we know customers love.

Allison: We can't grow the business we have. We don't have the right tech team.

Lawrence: But no matter what we do, we will want to fix the problems with the tech team. We can fix the tech team and do the old idea or we can fix the tech team and do the new idea. So why not do the old idea, since we know customers love it?

Allison: I don't know when or if we are going to fix the tech team.

Lawrence: We've already removed the worst people. And we are hiring better people.

Allison: Okay, great. Like I said, when we see evidence that the tech team is better, then we can consider a more ambitious project.

Lawrence: Our competitors are going to take over the space that we are walking away from.

Allison: We cannot compete with them. We are not good enough. We don't have the right tech team.

Lawrence: We need to compete and win. That's what competition means: you fight and you win. And we can build the team we need to win. We can build our strengths. We don't have to accept weakness.

Allison: I have seen no evidence that would make me think we can build the team we need in the time we have. We are burning through our investors money. We need to come up with something good in the next 6 months.

Here is why UnifiedSTR was initially exciting to customers: imagine you want to maximize revenue by listing your apartment on AirBnB and Booking.com and VRBO. And a reservation comes in via AirBnB, renting your apartment for a week. Do you want to then manually go into Booking.com and VRBO and manually mark that your apartment is unavailable for that week? Can you imagine how tedious it would be to have to manually manage the calendars across all of the apps? UnifiedSTR was able to use the APIs of AirBnB, Booking.com, and VRBO to keep all of the information synchronized, including the photos, descriptions, and calendar.

More so, the STR industry was becoming more professional: some people had 4 or 5 or 10 properties they were renting. Some were basically running decentralized hotels, with as many as 20 or 30 properties. Could you imagine the insane difficulty of trying to keep the calendar synchronized across the major STR websites, when you have 20 properties?

In short, the need for UnifiedSTR was obvious, and this is why we got such high response rates when we were advertising.

But coming up with a universal translation layer to unify all of the disparate 3rd party APIs was a fundamentally difficult task. All the same, I had come up with a database schema that would allow us to do it, and I had hired my friend John Leimgruber to help build the new API that could act as the universal translation layer.

But I was critical of the new direction that Allison, with the support of our new CEO, had decided upon, so I was sidelined as it was built. I instead focused on the team building a datalake and enabling our business intelligence (BI) tools.

Then the new VP Of Engineering came aboard. One of his first acts was to fire Deepika. She was an expert on the Booking.com API, but since we were no longer integrating with Booking.com, he felt her skills were useless. I was disappointed to see her go, as the possibility that we would pivot back to our original idea disappeared once she was gone.

For various reasons, building the new site dragged on longer than it should have. The VP Of Engineering had never worked with PHP before, and he distrusted it, so he decided the new product would be built with Java. This meant the old tech team had to be fired and a completely new team hired. This cost us at least 3 months.

To be clear, there were many problems in the old code base, but it wasn’t because it was written in PHP. You can write bad code in any language, and you can write good code in any language.

Most of a year went by. The new product launched in the summer of 2023. But no customers were interested. There were some clever UX ideas in the onboarding, but everyone who wanted to list their apartment on AirBnB simply used AirBnB, rather than signing up for our service. And for those who had become professionals, those with 10 or 20 properties to rent, we had nothing to offer.

Even worse, our competition had been moving forward. While we worked on this easy idea, other startups were focused on what had been the market of UnifiedSTR. Perhaps the greatest complement anyone ever paid to UnifiedSTR was the way other startups rushed to imitate our original idea.

By late 2023 it was obvious that UnfiedSTR had no future. By this point 18 months had been spent chasing the idea of "A friendly onboarding for AirBnB" which was an idea no one wanted.

Why am I writing this now? I have mentioned that on Friday I hosted a party for the startup scene in New York, and we ended up discussing this idea of startups that self-destruct by going after the easy idea that no one wants, instead of the difficult idea that everyone wants.

My friend Chrissy was at the party and she spoke about the startup where she has been working, which is focused on cryptocurrencies. A hard problem that needs to solved is the amount of fraud that has happened with cryptocurrencies, and therefore the issue of trust. The leadership of her startup has considered ways of tackling the issue of trust, but all of the ideas seemed hard, so they gave up and instead focused on building an intuitive UX for managing one's cryptocurrencies. She felt her company was self-destructing by going after the easy thing, where there is a lot of competition, instead of going after the hard thing, where there would be less competition, and where they might satisfy a real need people have.

And so, I worry that too many startups make this mistake, going after what is easy, rather than going after what is hard. The ideas that are easy will face too much competition. The ideas that are hard will be difficult to attain, but if you can breakthrough the difficulties, that is where a major business can be established.

Above all, remember this:

You can build your strengths. You do not have to accept weakness.

I titled this essay "Startups should do the hard thing" but I worry that some people will think that I mean that startups should go after huge markets. Most of the time, that isn't the case: startups should go after niche markets that don't interest the bigger players. Unless you've a breakthrough technology to commercialize, a startup should not compete directly with Google or Microsoft or Amazon or GE or Phillips or Merck. Find some niche market, solve a difficult problem in that market, and grow from there.

But I am still a big believer in what UnifiedSTR was trying to do. And though competitors have been picking away at the market, there is still a space for a company to implement a technically perfect translation layer between the APIs of AirBnB, Booking.com, VRBO and other STR companies.

If anyone is interested in funding another attempt in this space, please call me: 434 825 7694.

I know we could build a category-killing startup in this space. While Allison was feeling burned out and cynical, the truth is a good team can still go into this space and compete and win.