As we’ve grown Proof, we’ve done a lot of things well, but we’ve also made a ton of mistakes. The way I explain growing a business is that nothing ever really works as you planned.

I can count on one finger the number of strategies and tactics that we’ve launched that have worked as well as we thought or better. Almost everything flops a little bit or flops a lot, and I wanna kind of share some of the ways that we’ve really kind of messed up at Proof.

You’re going to make mistakes while growing a business, but I hope this helps you learn a few things that you can avoid.

1. Not focusing on churn early enough

When we launched Proof, we sold it via a webinar. We basically pre-sold it to a bunch of people for a whole year.

Then, we launched the software and it just started growing really, really quickly. This was the one thing that’s actually worked better than we expected.

We got to about $75,000 MRR in the first six months of growing Proof, which we thought was insane. That grew to about $175,000 MRR in the first year.

So growth worked really well, but the whole time we were thinking, “How can we add more customers? How can we add new customers?”

We celebrated at the office every single day when we hit another thousand dollars of MRR. We would play “Another One Bites The Dust,” and we’d all dance around and celebrate.

At this point, we just kind of thought we’d take care of churn later. And churn was horrendous at the beginning. At one point, we were measuring around 20% monthly user churn.

We were getting a lot of expansion revenue so the effects of churn didn’t hit us immediately, but eventually, you have to pay the price for high churn. You can’t just keep pushing that off forever.

As we’ve gotten bigger, growth has slowed down because we never really addressed these issues as much as we should have that point. The problem was we weren’t going deep with our current customers.

We were always asking, “How can we add new customers?” But we were not thinking about customers that already paid us and already existed — we didn’t go deep with that section.

2. Growing too fast

This might sound like a good problem to have, but it is still a problem. I think we started growing too fast, adding in too many people, adding technical problems with the product because we just didn’t ramp up our growth slowly enough.

I think one of the big problems was we had several industries coming in and using our product. At first, we were laser-focused on people that were doing coaching/consulting and selling courses. Our product was built to help them get more trials for their membership sites, get more webinar registrations, and receive higher order values from sales.

Everything was really simple. Then we started to have law firms start using Proof. We started to have e-commerce stores want it. We started to have SaaS companies use it. And so we just lost focus as we grew too fast, and we weren’t able to kind of keep momentum in a single vertical.

Maybe six months in, I asked “Who exactly are our customers?” and we really didn’t know anymore. There were so many different kinds.

That makes it really hard to channel your marketing, to decide which features to build, and really to do anything.

3. Too much technical debt

I’m not an engineer, so I don’t have really deep insights into this. But I believe that you should leave a lot of technical debt out there especially early on. You should be really scrappy, really lean, and consume all these third-party services that you can to get your app built. I’m a proponent that startups build and write code for the things that you’re actually going to be offering.

But with that mindset, we took on too much technical debt. About six months in, we had $75,000 MRR — but we probably spent four months of retooling stuff, fixing our Firebase issues. We had been promised that Firebase would be infinitely scalable, but we started hitting the limit nearly every day. People couldn’t log into the app, and they couldn’t do basic things because we just built Proof on the wrong stack.

Hindsight 20/20, we were naive. We got to a point where we were just like things slowed to a crawl because we built an angular app and that wasn’t being supported anymore. So we had a thing we couldn’t scale.

4. Not hiring more engineers fast enough

We were growing fast, technical debt was piling up, and we needed more minds thinking about how to grow and build this platform. But we only had two engineers.

And one big problem was that we lived in Annapolis, Maryland, a town of 40,000 people. There were about two full stack engineers in Annapolis, Maryland. And they were both working at Proof.

We tried to recruit from DC and Baltimore, but we found that engineering talent there didn’t want to drive over, and we really weren’t built to be a remote company. We wanted everybody to be with us in the office.

And we got to this point where we realized, there’s really no other engineering talent out there. Around that time, we got into Y Combinator and decided that we were going to move out to Austin, Texas after the program.

5. Building incremental features and not substantial new offerings

After working through a lot of our technical debt, we were trying to listen to our customers. And they were telling us these incremental things.

Proof Quickstart Checklist

And I’m telling you, we reworked our set-up flow probably four or five times. And each time, it got a little bit better, but really nothing substantial was built. We would add new features and it would move the needle a bit, but honestly, the product is still pretty similar to what it was towards the beginning of Proof.

We didn’t invest heavily enough in R&D and innovation.

We just started tweaking things at some — and we weren’t doing great product thinking. And so, it kind of got away from us.

I think we should have built more substantial offerings, listened to customers and not necessarily taken the exact feedback they gave. They may have said “hey, I need it to be a little bit easier,” and I think you should do that by adding tooltips. We should have listened to their frustrations, but not their solutions.

We just kind of got a bit stuck in trying to make a faster horse when what we needed to do was build a car. Which is what we’re working on now!

6. Building the company too soon

This is something that they hammered into us at YC not to do, but mostly we didn’t do a good job of this.

We started to grow, we raised capital, we moved to Austin and we started to build our product. But we started to build the company on top of the product.

The way that we thought about this — and in hindsight, I think this is wrong, so don’t do this — was like this.

JP my co-founder was the CTO. I said, “JP, you’re in charge of building the product. I’m going to be in charge of thinking about how to build the company, as its own product. And the company product will build the software product.”

I pulled out of the day to day of what was happening with our customers and what was happening with our product. I was focused on things like culture, hiring, scaling, systems, operations, and the such.

I got really far removed from product — to the point that I really didn’t know what was in our product. I didn’t know what we were working on. And that was an issue. That was a problem. Especially as the CEO, I’ve got the most authority and if I’m not excited about making the new product or building something cool, nobody else on the team is.

With Experiences, JP and I are both fully engaged in the product. In fact, we’ve flattened out the whole organization. We added layers of management, and we added all these different things.

But now, we’ve flattened the whole thing out. I’ve said, “Everyone in the company — you’re either writing code or you’re helping customers implement the code.”

That is what we do as a company. Everyone non-technical still has their day to day role — like Finance or Marketing — but in addition, everyone is either writing code or helping our customers (if they’re not technical). And that’s been huge.

There’s a lot more momentum now, everyone understands the customer, and they understand the problem. Everybody is on the same page about what we’re building, and I think we got away from us a while back.

7. Not communicating well during transition

About 6 months ago, growth was slowing for Notifications and we had to figure out what was next. We decided that we wanted to personalize the entire funnel for conversion and create these delightful human experiences — starting with B2B SaaS companies.

To accomplish this, we had to switch some resources over. We split off into teams of four. One of the teams was the Experiences team that was charged with figuring out how to build the next product. What would it look like? Was it even possible?

What quickly happened in the company is people thought “there’s kind of this new team — and that’s the new company and we’re the old company.”

There’s kind of this exciting, new product and there’s this old product that people aren’t as excited about. And this really blew my mind, because I didn’t really think about it like this. We’ve got an existing product that’s great, has three thousand customers and is important for our business. At the same time, this product won’t get us a huge valuation or $200 million in ARR.

When we started this exploratory team, I didn’t do a good job of communicating, I was in my own head about this.

And there became this divide in the company that really kind of killed some morale, killed some momentum. There was a lot of disagreements. At one point, we were in a meeting and one guy was working on Notifications and says, “I’m kind of worried, are we going to get let go?”

And that was the farthest thing from my mind. At no time had I thought about that, that wasn’t what we were doing. If anything, we were just going to continue to shift more resources over to Experiences as we had them available. But I didn’t do a good job, as a leader, of communicating well through the transition.

I’ve gotten a lot better at it now, and I’m trying to communicate every single day. Here’s what I’m thinking, here’s why I’m thinking about it, and here are the principles underlying my thoughts.

I’m trying to add a whole lot more transparency to what I’m thinking. Just so that people can have some context and clarity around a transition time. Experiences is in Beta, so it’s not generating revenue yet. We’re still in private beta with some B2B SaaS companies, but we plan to have this fully released and generating meaningful revenue this year.

I don’t think we’re anywhere near perfect, and we’re going to continue making a whole lot more mistakes over the next year. Making mistakes is how you grow and learn, but it’s wise to learn from the mistakes of others. So I hope these lessons help you as you build your business — maybe you’ll avoid some wasted time and resources.