Contemplations of an indie SaaS founder

Changelogs For Everything

2023-01-30T00:00:00Z

Changelogs are underrated. We software developers get some of them for free, courtesy of our Git logs and issue tracking systems. But the usefulness of a changelog extends beyond just code changes!

When building Drip, Rob and I used to maintain a Marketing Changelog. It was nothing fancy, just a Google Sheet with timestamps and descriptions of various marketing activities (changes to the website copy, ad campaigns, joint-promotional efforts, and so on). When we would notice a difference in our SaaS metrics, it was always helpful to cross-reference the Marketing Changelog to see if we could attribute it to something we did.

I recently made a round of improvements to our GDPR compliance for SavvyCal. SaaS GDPR expert Rie Aleksandra Walle recommends keeping a changelog for your compliance efforts:

Whenever you consider/check/decide on something, document it. If you decide you don’t need a DPO, the authorities might disagree, but you can significantly reduce the risk of a fine if you can prove you actually made a conscious decision.

I’m always wearing many hats in the business, so I’ve found my GDPR Changelog to be helpful for remembering past decisions I’ve made and questions I’ve answered for myself as I dip in and out of that project.

Like GDPR matters, I’ve been working on our sales tax compliance:

Investigating where we have nexus
Registering with various government agencies
Researching services to automate processes

Each time I make progress, I drop a new timestamped summary in the Sales Tax Changelog document.

You don’t need any special tools to get started – a Google Doc is plenty! My changelogs are a burden off my mind. They are a place to accumulate knowledge visible to other team members. And I can rest easy knowing the effort I put into these fuzzier projects (that don’t fit neatly into a Git history log) will not get lost in the aether.

Ship Small, Ship Fast

2023-01-23T00:00:00Z

Big, long-running feature branches are the worst. They’re challenging to tame, and they slow you down. The odds of bugs slipping in under the radar are high. Each time you return to the project, you need to load an increasing amount of information in your mental RAM to return to flow. Merge conflicts stack up.

Over time, you feel less and less confident in the code. When you ask your teammates for code review with multi-thousand line diff, you’re likely to get a quick “looks good to me!” rather than a thorough assessment.

Not all projects are inherently small, but you can always break them down into smaller chunks.

We recently built a SavvyCal feature called Workflows, which allows you to send emails at specific points in the meeting lifecycle. This project was a multi-month effort that consisted of 92 tasks! On day 1, we began shipping pieces of this feature to production.

Right out of the gate, we added a “Workflows” page to the navigation and tucked it behind a feature flag (visible only to admins).

Then, we created a few database tables to store workflow records and deployed those migrations.

Shortly after, we shipped the ability to create workflows and see them on the index page. Of course, workflows couldn’t do anything yet, but that’s a concern for a later time.

Next, we added the ability to attach a “send email” action to workflows. We couldn’t send the email yet, but we’re one step closer.

Then, we added a way to attach a workflow to a scheduling link.

Each incremental task brought us one step closer to a functioning v1. By shipping these tiny branches to production as we go, we became increasingly confident in the “bones” of the feature. As soon as a slice of the project was ready to test, the whole team hammered on it in production – an effective way to tease out bugs and rough spots in the user experience.

The benefits of this approach extend beyond the ability to QA test as you go. Shipping small parts early on builds momentum for everyone on the project. Getting incremental changes on the main branch and into production frees your mind from trying to hold all the context for the overarching project. Merge conflicts become rare. Peer reviews are quick and effective.

As the feature starts to take shape, you might even identify areas of scope that you can cut. That complex flow you initially mapped out may no longer apply now that you’ve had a chance to put your hands on a production prototype. If the feature feels good earlier than expected, it may make sense to start enabling the feature flag for some real customers to get their perspective.

Next time you’re staring down a daunting initiative, consider busting it apart into little projects and shipping as you go.

10 Questions for Teasing Out Market Opportunities

2020-02-24T00:00:00Z

What successful companies are resting on their laurels?
What products have gone so far up-market that a broad base of customers can no longer afford them?
What successful products have critical flaws for a subset of users?
What products are people using for a different purpose than originally intended?
What popular products are extensible and could be augmented to work even better for a particular niche?
What inefficiencies can be solved by borrowing new technology and applying it to an older space?
What areas have a bunch of new people looking to join who are willing to spend money to succeed faster?
What popular products have been acquired and shut down, leaving a void of demand?
What companies have stopped listening to their customers?
What companies are unable to keep up with feature demands because of legacy?

Finding My Next Bootstrapped Business Idea

2019-05-28T00:00:00Z

Most business ideas are neither objectively good nor bad. The quality of an idea for you (as a founder) depends on your goals, your skill set, and your risk tolerance.

Even the quintessential lousy idea of trying to “build the next Facebook” is not necessarily a bad idea. Someone will eventually pull it off – it just comes with an enormous amount of risk and requires one hell of a skill set.

So given a list of potential ideas, how should one go about picking The One?

It turns out humans are pretty bad at comparing things. If idea X will take three months to build and has a large addressable market, is it better or worse than idea Y that will take one month to make but has a slightly smaller market? Who’s to say? It gets even trickier the more variables you consider.

There’s a better way that I first heard articulated by Jason Cohen: instead of trying to rank your ideas, run them through a set of filters to eliminate those that don’t fit.

Why am I starting a company?

Before trying to establish my filters, I need to understand why I’m doing this in the first place.

Do I want to change the world by creating innovative new products? Do I aspire to make a life-changing sum of money and retire early? Am I just tired of working for someone else?

My primary motivation is to earn a comfortable living for my family, with a bit left over to fund causes for which I have a passion. I want to achieve predictable product revenue that does not directly correlate with the number of hours I work.

I want the freedom to build products that are interesting to me as a maker. I love to strategize, design, and create. I don’t enjoy managing people. Eventually, I want the ability to take a month off of work without negatively impacting the business.

What are my growth ambitions?

It’s glamorous to imagine coming up with a bold idea, wooing investors, and hiring best-in-class people to execute on the vision. And yet, the venture capital track comes with a high degree of risk (most fail), a strong growth mandate (fast-paced, long hours), and people management.

I know I’m not interested in trying to build the next unicorn. Paul Graham wouldn’t even call what I want to do a “startup”:

A startup is a company designed to grow fast. Millions of companies are started every year in the US. Only a tiny fraction are startups. Most are service businesses — restaurants, barbershops, plumbers, and so on. These are not startups, except in a few unusual cases. A barbershop isn’t designed to grow fast. Whereas a search engine, for example, is.

Like the barbershop owner, I want a small business – only I happen to be selling software products on the internet instead of haircuts on a neighborhood corner.

Narrowing down my options

Since I want to bootstrap my next venture, the market must already exist. There should be competitors attempting to serve the market (but perhaps not doing a great job of it).

I’m relatively risk-averse, so an MVP must be shippable within a few months. It’s hard to know upfront if this is possible, but I can confidently eliminate ideas that I know will take a long time. The product must be valuable to a particular niche, even when it’s new.

The product should not be mission-critical. By mission-critical, I mean so vital that even a short period of downtime will have a significant impact on my customers’ businesses.

Making a sale shouldn’t require more than a few decision makers. A counter-example would be a product like Slack, which requires buy-in from every stakeholder in a company to adopt.

Native apps should not be a minimum requirement. These days, users have come to expect native desktop and mobile clients for specific categories of applications (communication, project management, and note-taking, to name a few). It’s hard enough building for one platform as a small operator, let alone three or four platforms.

Since I regularly invest in growing my following on Twitter and my weekly podcast, the market should overlap with my existing audience.

Knowing when to compromise

My filters look like this right now:

The market must already exist
MVP must be shippable within a few months
The product should not be mission-critical
Making a sale shouldn’t require more than a few decision makers
Native apps should not be a minimum requirement
The market should overlap with my existing audience

There is no perfect business idea, and I may have to compromise on some of these criteria – that’s okay. I expect these to evolve as I gain more clarity.

I have a handful of filters that didn’t make it on the list (at least for now). Most of these have to do with avoiding the annoying things I’ve encountered in previous businesses.

Dealing with email blacklists and spammers at Drip was exhausting. Trying not to get obliterated by Google at HitTail was frightening. One time I prototyped a lead generation tool based on the Twitter API, only to see the APIs get deprecated not long after.

It’s tempting to keep a growing list of things I will never do again, but I’m trying to resist. It sounds counterintuitive, but I may even intentionally pursue a problem I’ve tackled in the past since I already know what to expect and how to get ahead of some of the challenges.

No business exists in a vacuum. There will always be parts that keep you up at night – but hopefully not too often!

I’m Walking Away From the Product I Spent a Year Building

2019-05-17T00:00:00Z

Here I sit, in a cabin on Lake Superior by the fire, with late-season snow pelting the windows and ominous waves crashing against the rocky shore.

Despite the treacherous terrain that surrounds me, I feel at peace with the decision I’ve been weighing. I’ve decided it’s time to take a step back from building Level as a standalone alternative to Slack.

I’ve become comfortable sharing the behind-the-scenes journey on my weekly podcast, The Art of Product, in hopes that it will be helpful to someone, somewhere. Keeping with that tradition, this my in-depth retrospective on what happened, the thought process that brought me here, and what’s coming next.

The Backstory

On March 3rd, 2018, I was filled with optimism. I had just left Drip, the company I helped start five years earlier, and I was eager to return to the startup phase.

To use terminology coined by Justin Vincent of the TechZing podcast, I had a strong case of The Madness. I was hungry to get back to designing, marketing, and writing code unencumbered by legacy.

In the short time leading up to my departure, I finally allowed myself to entertain what was next. (I held off for much of my post-acquisition earn out, lest I become too anxious to get started). I filled pages in my notebook with ideas, but one, in particular, I couldn’t shake.

When Drip was acquired, our small team of 9 joined the Leadpages team of around 150. I remember looking across the office, bewildered that there could be so many people working on a product of a similar size to Drip. I soon discovered there was a slew of challenges coordinating work, and nearly all of it was happening in Slack.

The larger my immediate team grew, the more I struggled to remain productive. My days felt increasingly chaotic. I was no longer focusing for long periods. I realized that the way we were structuring our communication was a significant part of the problem.

Real-time chat was making everything feel urgent. Moreover, the company culture had evolved to the point that people expected quick responses to all messages. Conversations were disorganized. Vital information was getting misplaced among the din of idle chatter.

We were not alone. People across the internet were beginning to recognize these shortcomings of chat. Maybe chat wasn’t the holy grail of workplace communication that so many believed it to be. There were signs that a movement was afoot, but no one was championing the cause with an alternative product in hand. Why not me?

Putting a stake in the ground

The Monday after leaving Drip, I published the Level manifesto with great fanfare: The War on Developer Productivity (And How I Intend to Win It).

The manifesto was the first step in validating that my idea had legs: make a bold statement about the problem (without too many specifics about the solution) and gather email addresses of people who wanted to join the movement.

The numbers were encouraging. Hundreds of people handed me their information and shared it on Twitter. Even a handful of haters came out of the woodwork – striking a nerve is a good sign you’ve transcended complacency.

Despite being encouraged, I was determined not to fall into the trap of proceeding to build without sufficient evidence that a reachable market exists. The next step was to email the list (about 500 people) and ask to chat with them for 20 minutes, to learn about their problems and their willingness to pay for a solution.

Around 40 people ended up booking a time slot! The calls felt productive, and by the end, I felt like I wasn’t learning much that I hadn’t already heard. Many folks echoed the sentiments from the manifesto:

Ugh, Slack distracts me so often. You’re right; everything feels urgent even when it’s not. I’m super interested in what you’re building here. We’re pretty open to change at my company – I don’t see switching being too big of a deal.

Some folks were fans of my podcast but were not really in my target market. Others were not decision makers, so I had to take their feedback with a grain of salt. However, I didn’t interpret much of what I heard as unfavorable.

Armed with lots of qualitative data, I set off to build.

I also decided to introduce an element of scarcity to my landing page: reserve your username on Level before someone else takes it. In the months that followed, over 6,000 people took the bait and claimed their handle.

Setting the public deadline

Before long, I began to feel a creeping sense of uneasiness. I was learning a handful of new technologies in the process of building, and it was taking a while. Was I still on the right track?

I decided to run a small alpha in early October. It quickly became apparent that Level would have to be further along before anyone could try it earnestly with their team. Without trying the product for real, they couldn’t accurately predict whether Level was going to be a good fit.

It seems like you’re on to something here. I’m interested in trying it out when it’s further along!

I was frustrated, but not deterred. I felt confident that I could get Level mature enough for at least some teams to start piloting it by late January. To keep myself honest, I set a public deadline on my podcast and sold $49 pre-orders to those who wanted to be in the first batch. Around 50 people bought the pre-order.

By the time the deadline rolled around, I was feeling good about where the product stood. It was still early, still missing trivial things like password reset, but the core mechanics were in place.

I decided it was essential to manually onboard each customer to ensure they started on the right foot, so I began scheduling onboarding calls with the first batch.

The response did not live up to my expectations. Only a subset of people who paid booked an onboarding session. Of those who did, some never touched the product. Some who did poke around the product never gave it a real go with their team (and didn’t show much interest in following up with me). A handful did convert.

Every conversion funnel leaks, but I was admittedly disheartened. There seemed to be a curious mismatch between the sentiments I gathered early on and the actions people were taking. If people were ravenous for a solution, why weren’t most people even attempting to pilot Level?

Getting a larger sample size

I knew I needed a larger sample size before drawing more profound conclusions, so I decided to forge ahead with my next goal of making the small base of currently paying customers happy.

Those who did latch on to Level had a plethora of feature requests, most of which were in alignment with my vision for the product. I spent the next six weeks building. By that point, my customers were loving the product – even my largest customer that started out highly skeptical of the paradigm. Everyone who had converted so far applauded the user experience and agreed Level was a beautiful product.

I decided to invite the 500 most recent people to try Level, in pursuit of more data. (I chose the most recent ones because Level would be relatively top-of-mind for them).

I sent a warm-up email to the first batch on the Thursday before Easter, in which I reintroduced Level and informed them that an invitation was coming on Monday. At 10 am on Monday, I sent the invites.

I observed how people were using it for about a week. There was a lot of poking around and, once again, virtually zero evidence of anyone piloting it with their team. I reached out directly to everyone who made it into the product: are you planning to test Level out? What can I do to help?

It became clear pretty quickly that the gap between interest and implementation was of canyon-like proportions. The next week, I repeated the process with another batch of 500, with very similar results.

Small teams (who have a much easier time making the jump due to their size) didn’t seem that compelled by Level. In follow-up conversations, I discovered that Slack was at most a minor annoyance for them. Suboptimal? Yes. Worth going through the trouble of switching? Probably not.

Every large team I spoke to had an exceptionally high bar and was unwilling to entertain Level until it was significantly more “mature.” They are the ones who need Level the most, and yet it was looking like I wouldn’t have a shot at converting them without months (or years) of development work.

The Turning Point

I knew what my gut was telling me. However, I’m far too rational to make such an existential decision based solely on intuition. I had to feel confident that I was not just weary from the slog and seeking greener pastures. I had to be sure I was not giving up prematurely.

Everyone is lying

As I was confiding in my friend, he recommended a book called The Mom Test by Rob Fitzpatrick. Once you understand the premise, the title makes more sense. The subtitle is more blatant than the title:

How to talk to customers and learn if your business is a good idea when everyone is lying to you

It’s a quick read and should be a mandatory prerequisite for anyone embarking on the startup journey. The gist is that it’s tough to get unbiased feedback during customer validation. I already knew this to be correct, but I underestimated to the degree to which everyone lies.

Reading this struck a chord. I felt betrayed by my early validation efforts since reality proved to be radically different.

Publishing a manifesto from the onset made getting untainted data more difficult. Of course, you have to get people in your pipeline to talk to them somehow, but coming out with a strong hypothesis meant that I needed to be extra vigilant and mostly ignore sentiments that tacitly confirmed my manifesto.

Instead of seeking confirmation, I needed to focus on specific scenarios in that past:

“What is your team communication workflow?”

As they point out flaws, follow up with, “Tell me about the last time that happened. How did you respond? How have you tried to fix that problem to prevent it from happening again?”

I did another round of calls, this time running the Mom Test playbook. What I found was troubling. Everyone expressed being “annoyed” by Slack, even calling it a “big problem.” However, when pressed with the question of “what have you done about it so far?”, almost universally the answer was “nothing.” No process changes — no trials of Slack alternatives.

I spoke to a handful of companies who have successfully tamed Slack — the outliers.

An engineer at Stripe told me about their careful balance of email, forums, and Slack. They recognize that Slack is not suitable for meaningful conversations, so they automatically delete chat messages older than a few weeks to discourage relying on it for long-term archival. In retrospectives, team members often reflect on whether they chose the right medium (email, chat, or forum) for various conversations.

The team at Honeybadger is small but acutely aware of the cost of distractions. They use Slack for chat-ops and quick back-and-forth conversations, but they are always experimenting with different tools (like Basecamp) to organize more permanent discussions. Most of the Honeybadger team has removed Slack from their phones, and they make a habit of frequently closing it on the desktop (or using Do-Not-Disturb) when it’s time to focus.

Each has clear policies around internal communication and consider deep work to be part of their cultural DNA.

Is this a problem I want to tackle?

If there is a growing movement around valuing deep work (and I hope there is), it’s still in its infancy. I’ve spent hours brainstorming the path forward.

Should I offer a service to train companies and help facilitate that cultural change?
Should I go freemium with the hopes of igniting grassroots adoption and someday converting 1% of them to paying customers?
Should I hire a salesperson to help sway key stakeholders in larger companies that only have one champion?

Some of these might be good ideas, but none are compatible with my goals as a founder. I aspire to stay small, abstain from raising outside funding, and achieve profitability quickly.

For me, profitability means covering my family’s cost of living, necessary business expenses, and taxes – in the neighborhood of $10k - $15k MRR.

I’m fortunate to have a relatively long runway from my previous business sales. However, it’s still a finite one.

That means, given my constraints, I can’t reimplement all the parts people love about Slack before reaching profitability. I can’t hire a team of engineers to move faster. I have no desire to run a consulting practice.

Having robust filtering criteria is ideal when making hard decisions. I’m happy to be discovering my constraints early on before I find myself years into running a business that doesn’t fit me, and I wind up hating my job. I only wish I had this much clarity a year earlier, but you know what they say about hindsight.

What’s Next

One of the unique aspects of entrepreneurship is uncapped earning potential. (The opposite would be something like working in public bureaucracy, where you can look at a chart and know what you will make in 10 years.)

I find uncapped potential to be one of the most motivating parts of starting a business. If I do my job well, I can find a pain point that a large market will pay to solve, build the solution, figure out distribution, and watch the recurring revenue-based profits rack up while I retain the freedom to work on what I want, how I want.

The startup news cycle bombards us with unicorn stories about massive, unexpected growth experienced by a small team with a big idea. It’s an intoxicating fantasy. I would assert that even the most disciplined entrepreneurs hold on to a shred of hope that their company might blow up beyond their wildest dreams. I don’t think there’s anything wrong with that.

However, I do think it can yield trouble when that small hope of a big success starts to influence your decision making. Unless you are raising venture capital and planning to shoot for the moon, unicorn dreams shouldn’t bias your decisions.

On this much-needed retreat where I am writing these words, I reread Paul Jarvis’ Company of One. It’s a beautiful masterpiece that breathes new life into what many pejoratively call “lifestyle business” and is chocked full of tips for starting small and staying intentionally small.

In hindsight, I took on an unreasonably audacious endeavor with Level in part because of my internal “this might get big if I play my cards right” dialogue. It would have been far better to either deliberately go for the big idea (and probably seek venture funding to make it happen), or start far smaller and build my way into a sustainable company of one.

At the time of writing this, that is all I truly know about what’s next. I’m passionate about serving the needs of makers (developers, designers, founders, indie hackers, and the like) so I will return there. Perhaps there’s a way to deliver on the Level vision that is compatible with my goals – I am exploring that as well.

About one thing, I am sure: I can’t wait to see what’s in store in my next chapter.

Choosing Your Technology Stack

2016-03-21T00:00:00Z

Nothing quite compares to greenfield software development. The canvas is blank and you finally have the opportunity to do it “The Right Way” from the ground up. If you’ve been building web apps for a while, you’ve undoubtedly found yourself working with technologies that you’d never use again, given the luxury of a blank canvas. And if you follow the open source world, there’s probably a brand-spanking-new boutique framework you’ve been itching to take for a spin.

With all the excitement of a blank canvas comes an equal amount of anxiety. You know you are one ill-advised choice away from being stuck with the “imperfect” tech stack. You have a hunch about what you want to use, but being the dutiful engineer that you are, you spend a few hours verifying your assumptions by Googling “Ruby vs Go” and “nodejs vs haskell” only to find yourself with net loss of clarity. (Don’t do that.)

Take a deep breath, it doesn’t have to be this hard.

Stick with what you know

I know you’ve heard it a million times and I’m going to repeat it because it’s true: any modern web stack is perfectly suitable for most web applications. Don’t get me wrong, I love a good “my language is better than your language” debate as much as the next engineer. And when you scour the web for objective comparisons of different technologies, that’s exactly what you will find. But the truth is, that will lead you no closer to the “right” answer because there is no right answer.

If you’re a Ruby developer, build it in Ruby. If you’re a PHP developer, build it in PHP. Breaking ground on your new SaaS app is probably not the best time to decide to learn a new language or framework.

In the early planning stage for Codetree, I considered using Sinatra instead of Ruby on Rails. At the time, some members of the Ruby community were espousing that Rails is too heavy and I was beginning to buy into the hype. I had visions of a perfectly clean codebase with just the components it needed and nothing more. It was going to be great. And then I came to my senses.

I had never built a Sinatra app before, I was probably going to move at least 20% slower, and my volume of Stack Overflow searches was probably going to double. After all, I had spent the last three years of my work life building Rails apps and polishing my skills with that framework.

My point is not that Rails is superior to Sinatra for everyone, but it definitely was for me when as I was trying to build and launch a profitable SaaS app.

Favor stable over new

Dan McKinley (formerly with Stripe) wrote an excellent piece about this concept that really helped solidify my thinking on the topic. Many other titans of the tech industry have expressed similar sentiments.

We don’t need to reinvent the wheel, we don’t need to write our own databases, we don’t need to start writing our own frameworks — because they’re all in domains that are usual. It’s a website, it’s web hosting. In the domains that are unusual, we fully embrace the need to write custom applications or build bespoke apps for that.

— Sam Lambert, Director of Technology at GitHub

Remember that brand-new framework I mentioned before? Don’t use it. Especially if it’s a JavaScript framework – it’ll probably be obsolete in two months anyway.

But seriously, that last thing you want to do is introduce more variability into the system than is absolutely necessary. When you are building features, finding product-market fit, and trying to get to launch, the last thing you want to worry about is a flaw in the pre-1.0-with-almost-no-documentation database system you just adopted.

Here's to the sane ones, the PostgreSQL-users, the troubleshooters. The placers of square pegs in square holes.

— Stripe (@stripe) March 30, 2015

What’s great about this approach is you’ve certainly worked with a handful of these “stable” technologies before. They are battle-tested, actively maintained, and you can probably find a book on them published more than 20 years ago.

Worry about scaling later

To say software developers have the tendency to over-engineer things is an understatement. It’s in our nature and I don’t think it’s a bad thing when channeled correctly. Writing robust, well-factored code for the sake of maintainability and stability is great. Architecting your codebase to withstand the load of millions of users while building out your minimum viable product – not so great.

I’m sure you have been told this before. I bet it was framed like this:

Don’t put too much effort into over-architecting your code. Chances are you wont have many users anyway. Most startups fail.

I actually think that’s a really lousy way to look at it. I’ve never bought into such a cynical argument and the logic does not play out for me. If I’m to operate as if the business is going fail anyway, should I opt to skip writing tests?

No, the reason is that no matter how experienced you are, it is impossible to foresee the exact scaling challenges you are going to encounter until you make it there. This principle is articulated well by the Extreme Programming (XP) movement.

There is no perfect stack

The irony of it all is there is no perfect tech stack. Stop striving for perfection.

Instead, stick with what you know and avoid shiny new technologies. That will put you in the best position to tackle scaling challenges as they arise.