Site icon Brent Ozar

How the Company-Startup Thing Worked Out For Me, Year 7

It’s time for my annual update on the wild ride. If you want to catch up, check out past posts in the Brent Ozar Unlimited tag. This post covers year 7 of the company – April 2017 to April 2018.

This year was about making financial sacrifices.

One way (certainly not the only one) to build an app is to work through these phases:

  1. Start by solving a pain manually with hourly rate consulting
  2. Gradually turn it into a productized service: a standard, fixed-rate consulting package
  3. Build tools so you can deliver the finished product faster (thereby increasing your profit), but still do the work primarily as a productized service that involves human beings
  4. Gradually make the tools so smart that your customers can use the tools rather than the consulting part of it – turn your productized service into an app

At phase 4, you’ve got an app, which means you can:

Making the jump from phase 3 (where your consultants use the tool) to phase 4 (where the public does) can be really expensive and risky. In late 2015, when the company bought out Jeremiah and Kendra, I decided to go for it. I hired Richie to be our architect/dataveloper, and I knew it was going to take years before we could get that product to market. I was fine with that risk. Not ideal – sure, in a perfect world you ship things gradually – but I was totally comfortable with that long term waterfall risk.

About two years into the process – during this year, year 7 of the company – the decision to bootstrap (self-finance) the whole thing was very financially challenging for me personally.

On the income side, we had:

On the expenses side, we had:

To keep things going, I did a lot of work without getting paid for it – at least in the short term – knowing that I was just gambling everything I had on the eventual success of SQL ConstantCare®, a product that couldn’t bring in revenue until year 8. I took on projects I didn’t necessarily want to do, and I started taking a really hard look at the profitability of everything we were doing.

I abandoned in-person training classes
and switched to online-only.

I’d been teaching in-person classes for several years, and they did pretty well financially, but I wondered how an online-only class might go. I did some experimenting to make our online classes even more valuable than in-person classes by:

When I thought I had the formula down, I stopped offering in-person classes and only offered online classes instead. I blogged about the reasons why at the time.

Ernie

As I worked on this plan, it seemed too good to be true. Why wasn’t anybody else in our business doing online-only training? Surely I must be missing something – there had to be a catch. I held my breath, and…tickets sold well. I sold less seats than the in-person classes, but I got a much higher profit percentage on each ticket sold, so I wound up way ahead. Plus, my quality of life went up – I wasted less time traveling and spent more quality time at home.

That work/life balance was especially helpful as our beloved dog Ernie was diagnosed with cancer and given about six months to live. We’d always spoiled her silly, and with me being at home most of the time, we took it to absurd levels. She passed away in January 2018.

I did keep doing pre-cons for established conferences – for example, Erik & I managed to sell out not one but TWO freakin’ pre-cons at SQLbits 2018. That was bananas (and profitable,) and we would have gone to the conference anyway, so that was nice.

Looking back at this decision, I’m really glad I did it. It was a quality-of-live vs. quantity-of-revenue decision. The more I look back at my life, the more I’m glad I make decisions like that. It feels like every time I’ve said, “Should I work less and make less, or work more and make more?” I’ve ended up choosing the former, and I’ve been happier with it. You’ve probably heard DBAs talk about being smart and lazy – working juuuuust hard enough so that you don’t have to work more. That works with your life, too, not just with your scripting of daily monotonous GUI tasks.

I think at some point in the future, I might start teaching in-person classes again. As a teacher, it’s fun to see the lights in peoples’ eyes as they suddenly understand a tough topic, and it’s tough to beat that rush. However, I really like working from home, and I still do enough travel for clients that bring me onsite to their offices, and I get the light-bulb moments there.

We started offering online classes taught by others.

I wish I could say this whole thing was part of some kind of brilliant plan, but Edwin Sarmiento just asked if he could do an Always On Availability Groups class through us. I knew Edwin, I knew he knew his stuff, so I said sure, let’s give it a shot.

Edwin’s class sold well – no surprise there, he’s a pro – and it was a win/win. We were able to offer more classes to our audience, and the audience was excited to attend top-notch stuff from the comfort of their homes – especially given that the course matter was in demand, and unavailable through local trainers.

We split the revenue right down the middle with our guest instructors, a 50/50 share. They got new income they wouldn’t have been able to get otherwise because we were really good at marketing, and we got new products to sell. I tried to make it so easy that all the instructor had to do was show up and deliver a great class.

This worked out really well financially for both sides. This worked out well, although I ended up discontinuing guest instructor classes in Dec 2018 to simplify our lineup (and my life.) Looking back in the rear view mirror at this one, this was just plain old luck.

I stopped selling to the EU.

I saw the GDPR coming, talked to our attorneys, looked at the compliance tools in a lot of services we relied on, and I just wasn’t confident in our ability to defend ourselves quickly and inexpensively against EU regulators. We’d never sold peoples’ data, but that doesn’t mean anything to outside inquiries – if they come calling, you have to be prepared to document all kinds of stuff for ’em. Dealing with government regulations isn’t something that fills me with joy, nor did the EU bring in a significant portion of our revenue, so I dropped it.

An influencing factor at the time was that we were working on SQL ConstantCare®, a mentoring system where you sent in performance and health metrics from your SQL Servers, and we’d give you advice on what tasks to focus on. I knew customers would be uploading metadata into the cloud – and that’s a super-sensitive area.

I didn’t want to have to defend that stuff to EU regulators until we had a version where EU customers could pick their data center – like have all their data reside in a specific country – and where we automatically deleted all data older than 30 days. Those things don’t ensure compliance, not by any means, but I just didn’t even wanna go near EU sales until we had those things in place. They just weren’t a high priority for US customers, so they were low on the priority list. (It’s really tough being a small business with limited resources – so many things I wish we could do, but only so many dollars in my wallet.)

So I blogged about stopping sales to the EU, and uninformed people went bananas. “OMG, HE MUST BE SELLING UR PRIVATE DATA TO THE FACETUBES!” Every time I saw those reactions, I just smiled and shook my head. I could tell who had never tried to build a business, pouring their life into it. Those folks would say things like, “Just become compliant – how hard can it be? What do you have to hide?” Riiiight. Someday, those folks will walk into a courtroom or a government office to defend themselves or their companies, and they’ll learn some fun lessons.

Looking back, I’m really happy with that decision: GDPR enforcement is still a big question mark, the new EU copyright directive is a hot mess, and…Brexit. Just no point in a small business dealing with all that paperwork for a relatively small percentage of revenue. I do love Europe, and I still travel there, and I wanna get back in business there at some point, but…just only so many hours in the day, and I don’t wanna spend any of them on government busywork. It’s that whole quality of life thing. I’m glad I chose quality over quantity.

Looking forward, I’m excited that the compliance ecosystem has no choice but to get better over time. A year ago, I blogged about how a data safety industry was on the horizon, and last month, Grant Fritchey showed how it’s coming true. We’re still tiny enough to dodge every US compliance regulation that I’ve seen – I don’t expect that to last forever, but hopefully just long enough for the third party ecosystem to get its act together. (I’m looking at you, WordPress.)

I made 3 big mistakes when
we launched SQL ConstantCare®.

We took on private early access customers, and then in March, publicly announced SQL ConstantCare®. Richie was finally able to show the public what he’d been working on for years. Suddenly now people could understand why I’d been so interested in Postgres, Aurora, the Serverless framework, and so on.

As year 7 came to an end, we could finally:

Looking back now, I can see a few big mistakes I made. (Well, I mean, I can see a lot, but let’s talk about three.)

First, I shouldn’t have thrown free consulting time into SQL ConstantCare®. I positioned it as “mentoring, not monitoring,” thinking that I’d gradually segue my work into being a mentor for hundreds of DBAs with thousands of servers. The math on that didn’t work: some folks had a very high expectation of the amount of hours per week that a mentor would personally spend with them. (For example, I would get a 500-line stored procedure as an email attachment along with a note like, “Can you make this go faster? We have a deployment tomorrow.”) There wasn’t a good common understanding of what a mentor does (versus what a subcontractor does.) In hindsight, this was my mistake, so I fixed that with the product relaunch solely as an email monitoring product.

Second, I should have gotten the consultants involved earlier. I should have had Erik and Tara use the SQL ConstantCare® infrastructure as part of our consulting work rather than using sp_Blitz, sp_BlitzCache, sp_BlitzIndex, etc. It would have slowed us down initially (because the data just wasn’t as good initially), but it would have forced us to build better back end tools, faster – just as using sp_Blitz, sp_BlitzCache, sp_BlitzIndex, etc forced us to rapidly improve them as we used ’em during our daily consulting work.

Doing that would have forced both Erik and Tara out of their comfort zones – writing PostgreSQL queries against the SQL ConstantCare® database structure – but it would have paid off in a higher quality SQL ConstantCare® product, faster. But this is one of the tough things about being a manager: I didn’t want to force the employees to adopt a skill they weren’t interested in. I’m 100% sure they would have done it if I asked them to, but I didn’t ask them to. I’m a bad manager. (I’m always the first to admit that, too.)

Third, I shouldn’t have bundled the training with it. I had a vision of getting the home page of the web site down to just 3 things:

In theory, this sounds great and simple. To pull it off, I removed the Recorded Class Season Pass, and only sold the self-paced video training through SQL ConstantCare®. I figured people would buy that at a nice low price, watch the videos, and then eventually get tempted to try the monitoring.

I was wrong. In practice, a good chunk of the market just didn’t want their monitoring data going into the cloud yet – but they DID want self-paced online training. I later ended up selling the Recorded Class Season Pass again, standing alone, and it outsold SQL ConstantCare®.

SQL ConstantCare launch revenue

Between those 3 mistakes, SQL ConstantCare didn’t make as much money as I’d have hoped. It was deeply discounted at launch, so from March 1 to April 30, it had $107,636 in revenue. (That’s the year 7 time span for this blog post.) That’s not bad – it’s decent money – but it obviously didn’t pay for the development in the first two months of sales.

In its first year altogether, from March 2018 through Feb 2019, it ended up making $239,507, and I’m quite happy with that. It pays for the ongoing development and the hosting (but not the sunk costs, and they’re sunk, and I’m at peace with that.) I’m utterly tickled pink with the product as it stands – Richie did a wonderful job of building it, and I wouldn’t change a thing about its construction. We got really lucky with the Serverless framework, Amazon’s continued investments in Lambda and Aurora Postgres, and the upcoming Aurora Serverless, which is a beautiful match for our bursty workloads.

In year 7, consulting was on life support.

I didn’t invest any of my time in the consulting wing of the business. Sure, I did consulting, but I didn’t invest time to improve the quality of the product. Erik, Tara, and I just kept on keepin’ on, delivering the same SQL Critical Care® that companies were happy to pay for.

With any successful product, though, you face the Innovator’s Dilemma: you can’t rest on your laurels, and you have to figure out new ways of relieving the same pain at a dramatically lower price. In year 7, I had to choose between:

I chose the first one. Today, you know how that ended – I ended up letting go of the consulting employees – and looking back, I’m comfortable with the decision. The consulting part of the business helped Erik and Tara to earn good money working from home. It was a financial risk and a time sink for me personally, but the tradeoff was worth it during year 7.

Year 7 was luckily safe,
but I realized that it was luck.

I took a lot of risks that year, and I didn’t get too badly burned. The cloud-based lab training classes online paid off, SQL ConstantCare® eventually paid off, and the consulting side of the business didn’t have too many lulls that cost us money.

As year 7 wound to a close, though, the lower-than-expected revenue from SQL ConstantCare® opened my eyes to the risks, and made me start thinking about them more carefully. From years 1 through 7, Jeremiah, Kendra, and I had always thought about growing the company to the point where someone would acquire it. With SQL ConstantCare® paying for itself, but not much more than that, I had to come to terms with the fact that we weren’t going to get acquired for huge money anytime soon.

Brent Ozar Unlimited could either be a barely-viable acquisition target, or a really successful lifestyle business. Year 7 was the last year that I still had the goal of being a startup, and in year 8, I transitioned the company over toward being a lifestyle business. But I’m getting ahead of myself! More on that next year.

Exit mobile version