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:
- Start by solving a pain manually with hourly rate consulting
- Gradually turn it into a productized service: a standard, fixed-rate consulting package
- 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
- 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:
- Reduce the cost, enabling you to serve more customers
- Scale to more customers with less staff
- Spend a fortune on development, support, documentation, etc.
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:
- Erik, Tara, and I doing consulting work
- Me doing training
- Residual (but dropping) training income from Jeremiah & Kendra’s videos
On the expenses side, we had:
- Salaries for Erik, Tara, Richie, and Erika
- Jeremiah & Kendra’s continuing buyout payments
- Taxes (because of the way deals like this work, money paid to Jeremiah & Kendra was seen as income on my own personal taxes, so I paid a LOT of taxes)
- And I had to eat, too
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:
- Giving every student a lab VM – I would lecture for an hour or two, teaching a concept, and then have students solve a challenge with that concept in their own lab VM.
- Setting up a Slack chat room – so the attendees could talk to each other, compare notes about how they were solving the problem, and even get hints from me if they hit a wall.
- Including Instant Replay recordings – so students could re-watch the class recordings for a year. I know when I used to attend classes, I loved revisiting the slides and my notes, but there’s just no replacement for seeing the actual lectures.
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.

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:
- Start getting money in the door to recoup the 2 years of development investments
- Start converting our consulting process over to SQL ConstantCare’s back end (instead of using a data collection app, which would later resurface during year 8 as the Consultant Toolkit)
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:
- SQL ConstantCare®: long-term mentoring, monitoring, and self-paced training, say $1k/year/user
- SQL Critical Care®: an urgent emergency room for one specific server, $7k for 3 days
- Live Class Season Pass: attend all my online training for a year
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®.

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:
- Leaving the product as-is, continuing to make money on it
- Invest my time in making the product better (improving the tooling, automating the reports, changing it to more or less time, adding followups, etc)
- Paying out of pocket to make the product better (like giving company equity to a consultant and telling them to run with the consulting arm of the business, putting in their own time into it)
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.
11 Comments. Leave new
Thanks for these updates, interesting journey!
As a European, I’m really surprised that you are afraid of the GDPR. A small SQL training business is more likely to get hit by a meteor than by a EU enforcement action. Where does that fear come from?
Andomar – interesting, so you’re saying you’re willing to break the law as long as it’s unlikely that you’ll be caught?
Thanks for your reply. I’ve never heard anyone express fear of being “caught” by the EU for doing legitimate business.
If the EU targets you, they send you a letter that says what you’re doing wrong, and give you a rather reasonable amount of time to implement specific changes. This results in meetings with Data Protection Officers, inter department committee sessions, and compromises with the regulator. For example, my company argued that it was impossible to hash passwords in a decade old system, and the regulator agreed to an exception.
I don’t know of any small companies that are at all worried by this, so I wonder why you are.
Andomar – great, very cool that you have data protection officers and committees to do that work. Me, I’m a bootstrapped founder. Your best bet to understand why I’m worried is to read this: https://brentozar.com/go/gdpr
If you don’t understand after reading that, then I don’t think there’s anything I could add here to explain it. Hope that helps, and thanks for stopping by!
Hi Brent, thanks for sharing your story. If anything it shows how you’re growing as an entrepreneur and a human.
As for the GDPR, stay away. Far away. As there’s no legislation, everyone is guessing what’s what. I’ve heard a number of Dutch companies and none of them know the correct definition of a data leak. And there’s so much more going on. This GDPR thing will sting for at least 5 years… I hope you’ll still be able to fly to Europe every now and then to teach and entertain us.
Thank you Brent for your transparency and honesty in sharing your journey with us. I enjoy your blog posts don’t have the same entrepreneurial spirit to launch a business but it’s great to see someone who does achieve success in this field. I’ve done a bit of consulting but I’m much happier doing development and assisting as an internal DBA consultant where I work today. Thanks to what I’ve learned reading what you and your team have posted over the years as well as the old podcast, it was clear that we needed someone whose role was strictly a DBA. The one we hired mentioned she follows Brent Ozar as well in the interview, so that was huge signal that she was a keeper.
Nice read! Thanks for sharing your experiences, Brent. It really helps to have a “behind the scenes” look at how things happen and the thought pattern behind it.
Fascinating read, as every year. Good luck!
I do want to thank you again for all your blog posts. I’ve been an “independent consultant on steroids” for a long time. I’ve had anywhere between 1 and 4 guys working for me and I’m quite content right now with me and just one other person. (although some work I’ve done on focusing on the business may mean that I have to either work harder or hire more folks and I’m not sure how I feel about that).
As for GDPR, I’d ask Andomar if he’s ever run a small company. It’s all a question of brain cycles. The fundamental limiting factor in any organization is generally not money, it’s intelligence. Spending any of that intelligence in areas that don’t promise a major return is a a big waste of time. Of course, any small business takes compliance risks. I don’t know any small business person that hasn’t discovered that they made a mistake in regard to some filing or compliance issue that they didn’t know about before hand. Or found out the tax implication of something was not what any rational person would have expected. I’m not talking about people who actively try to game the system. I’m talking about folks who try to do their best but make mistakes. So, it just makes sense not to take on more risks where there’s no real money involved. If I were in the EU, I’d take the GDPR risk because that’s a cost of doing business. Given that the market for monitoring and training must be a lot bigger than $250K in the US alone, seems that Brent could improve his lifestyle a lot without ever learning to spell GPRD
Hmm, from my perspective I’m not really sure that you’ve marketed SQL constantcare as your main product. I only find one video on youtube about how to install it, and a few blog posts on your site about it. Does it have a dashboard that you could demo? How does it add value? Why is it better than the sp_blitz tools that I can use for free (probably the main competitor to it)? Why not use another monitoring tool that you sponsor (sqlgrease)? Is it a monitoring tool with a dashboard, or something else?
Personally right now I want to downsize servers (azuresqldb) by making a workload more efficient, but not really sure that SQLConstantcare would help me do that.
Do you have a marketer on your team to help you figure out how to position it?
I appreciate your stuff! Hope you knock it out of the park!
Dave – great question! For a lot of those answers, click “SQL ConstantCare” on the top of our site. 😀