Codetree is a launch partner in GitHub Marketplace

21 million developers across the globe use GitHub as the central hub of their daily workflow. For these developers to be productive, their tools should integrate tightly with GitHub. We believe in this vision; it's one reason we bought Codetree a year ago.

Today, we're thrilled to be one of a small number of launch partners in GitHub Marketplace. It offers a place for developers to find "best of breed" tools for tasks like Project Management (where you'll find Codetree), Continuous Integration, Code Quality, and more.

GitHub Marketplace offers:

  • A directory of vetted tools that integrate with GitHub
  • Unified billing through GitHub
  • A fast way to find and try new tools to improve and extend your workflow

Joe Wadcan, GitHub's Head of Business Development, says:

"With GitHub Marketplace, developers can discover and purchase the tools they need, all in one place. Codetree's advanced project management features empowers developers and we're thrilled to bring them closer to our community through GitHub Marketplace."

Codetree even gets some screen presence in the GitHub Marketplace launch video (see below).

We're thrilled to participate. If you want to see if Codetree gives you a better view of your in-flight software projects, you can sign up for Codetree in GitHub Marketplace here.

Using dependencies to understand the state of your in-flight features

On occasion we're going to write about how we use Codetree to build Codetree. In this article, we'll talk about how dependencies can help you answer questions like "How much work is left before this feature is ready to ship" and "who's working on what parts of this Epic".

Using Dependencies

You can use dependencies to answer several helpful questions about the state of your epics and features during planning and delivery.

In this article we'll first give you some context on our workflow so the rest of the article makes sense.

Then we'll cover how we use dependencies when structuring our relationships between epics, features, and tasks (we call them "work items").

Then, you'll learn why dependencies come in very handy during our workflow.

And finally we'll describe key questions you have about planning and delivering your features and how using dependencies can help you answer them.

Context: Our Workflow

To make sense of this article it's key that you have a sense of the workflow we use to deliver features.

  1. Untriaged. Any issue without a milestone is untriaged. This is where issues start unless the issue creator makes a judgement call and puts it in a monthly milestone.
  2. Triaged. Our triage schedule depends on untriaged issue volume. We'll do an article about our triage process later, but when we triage an issue we'll either
    1. put it in the "Triaged" milestone or
    2. move it to the current or upcoming month's work milestone. (We slot work into monthly milestones.)
  3. In Progress. Work that's been started.
  4. Resolved. Work that's been delivered as done but still needs acceptance testing and code review.
  5. Done. Work that's been deployed.

We could be a lot more granular with our workflow (for example, splitting resolved into UAT, code review, and ready for deploy stages). But our small team prefers pragmatism over dogma, so we do what works until it doesn't and then reevaluate.

Now that you understand our workflow, let's talk about the relationship between issues.

How We Structure Issue Relationships

To understand how we use dependencies, it's necessary to understand how we break a feature up into atomic units that can be coded. Here's our breakdown.

1. Create Epics

First, we create a parent Epic issue that groups together the features we want to deliver.

Epics help group together related features.
We use a label to specify that an issue is an Epic.

2. Break Epics into Features

The feature's Product Manager breaks the Epic down into smaller "feature issues" of deliverable customer value. Each feature is needed-by the parent Epic issue (to create a dependency in Codetree you type needed-by #123 or needs #456, where 123 and 456 are issue numbers. More on creating dependencies here.)

Looking at an Epic's dependencies is useful because it'll tell you what's been delivered and what's still left to work on.

A feature issue should be a deployable slice of functionality.

3. Break Features into Work Items

The Dev assigned to each feature will either use a checklist or break the feature down into smaller "work item" issues. If the latter, each work item is "needed-by" the feature.

If you use work items, the dependencies table helps you understand what needs to be completed before the feature is ready for acceptance testing.

We usually use checklists as they're lighter weight, but there are certainly more complicated work items that justify having their own issue.

Using Dependencies in our Workflow

Other than specifying relationships between issues when we create epics, features, and work items, there's one place in our workflow where creating dependencies helps us understand what's going on with our project: in acceptance testing.

Filing Issues in Acceptance Testing

When the dev marks his issues as "Resolved" and it's ready for the Product Manager to do acceptance testing against the spec, the PM will files two kinds of issues:

  1. "Feature bug" issues that are "needed-by" the feature issue. These are for things that are broken with the feature. E.g. if the spec says "do x" and the feature doesn't do x, then the PM will file a feature bug.
  2. "UX polish" issues that are "needed-by" the feature issue. These are for parts of the experience that are rough around the edges and can be improved.

In this situation dependencies really shine. You're able to see:

  • How many feature bugs and UX polish issues are open, what stage they're at before the feature is ready for code review, and who owns each feature.

  • All the bugs and polish issues logged against the feature and decide whether to punt on them.

  • The number of feature bugs and polish issues are also useful to learn more about whether the spec perhaps needed more polishing, or if perhaps the dev was in over his head. Both useful pieces of information for the next feature you build.

These are all the issues filed against our File Uploading feature.

Answering Your Key Questions

Here's how to answer some of the key questions you may have about planning features and delivering in flight work.

"How many features are left (or delivered) in a specific epic?"

The combo of open/closed and issue stage tells you what work is left to do.

"What's holding up feature XYZ from being delivered?"

Having who's responsible for what and issue stages all in one place will help answer this.

"What work do I have to do to deliver the XYZ feature?"

You can quickly answer questions like this when you look at the stage of the dependencies you're assigned to.


That should give you a good overview of how we use Codetree's dependencies to augment GitHub issues and ship software. Feel free to drop us a line if you have other questions about using dependencies or if you use them in a way we didn't describe. We're always keen to learn!

What it's like buying a $128k side project

What's it like buying a small software business? In this post we’ll walk you through the process of buying Codetree - a side project that we believe can be a big business. We'll also describe some of the mistakes we made, and unpack our thinking during the negotiation.

This is last article in a three-part series. This part covers the details of buying Codetree. Part one was about how we defined success for our new, creatively-titled venture "Next Biz". Part two was about how we evaluated the different paths to maximize our chances of success.

The process to buy a business

Here's the high level process we used to buy a software business:

  1. Finding the right business to buy
  2. Offer and negotiation
  3. Sign letter of intent
  4. Do due diligence
  5. Sign Asset Purchase Agreement
  6. Close

1. Finding the right business to buy

Three days after we decided to build an Issue Tracker, we heard from FE International. FE is a web app broker and they had a B2B SaaS Project Management tool for sale. We had talked to FE a few years back about selling another SaaS business that we were running. Since talking to FE, we’d seen 60+ prospectuses from them, but nothing had been promising enough for us to buy. We had even looked an an issue tracker. We passed on it because it seemed like it sold to agencies for project work, a segment that is prone to high churn.

But this one sounded so promising that I sent an email to my partners:

Email after reading the Codetree prospectus

It caught our eye because:

  • Codetree was a good product

  • It was in a space we had decided - three days prior - to work on

  • It had existing customers we could call up to learn from

  • The asking price was affordable and we already modeled out what the payback period could look like for various purchase prices here

  • It had a steady stream of new trials per month

  • The tech stack was familiar

  • The founder, Derrick Reimer, had co-founded Drip. We were familiar with Drip because his co-founder, Rob Walling, has an excellent podcast called Startups For the Rest of Us. Rob seems like a good guy, and so Derrick and Codetree benefitted from a halo effect / social proof of being associated with Drip and Rob.

  • The prospectus stated Derrick was selling to focused on Drip, which was a plausible reason to sell.

  • There was lots of room to manoeuvre in the niche. We could make it a great layer on top of GitHub issues, or build layers on other services like BitBucket, or build a standalone app.

The key risks were:

  • Github would improve its Issues product and render Codetree irrelevant

  • Existing customers weren’t real

  • New customers weren’t actually signing up

  • Would new users keep coming

We asked some detailed questions over email to unpack some of the above questions. We also hopped on a phone call with Derrick and his broker from FE - David - on May 18th.

On our end, we had three goals for the call:

  1. Convince Derrick we could pay. When we sold our previous SaaS business, we learned that sellers get a lot of lookie-loos. If the potential buyer can’t afford the price, the conversation is a waste of time.

  2. Convince Derrick we’d make a good home for Codetree. Even if you get a check for your baby, you want it to end up in a good home. We’d been following Drip and the Micropreneur movement for a long time, so we had a lot of common beliefs. We’d also sold a business before so we had an idea of the kinds of things we wanted to see in a buyer to make us feel good about this (smart, credible, pragmatic, knowledge of the market, experienced, nice).

  3. Address some of the risks we saw above. This was an opportunity to unpack the risks we saw a little more.

After the phone call with Derrick, we debriefed (one sentence redacted for confidentiality reasons):

Debriefing after reading the prospectus

We modeled out what various offer scenarios looked like along with how long it would take to get paid back (those are the actual spreadsheets we used).

Seeing no major red flags, we decided to make an offer.

2. Offer and Negotiation

Before we talk process, let’s talk about a key element in any negotiation: your BATNA. BATNA stands for "Best Alternative To a Negotiated Agreement". The book Getting to Yes popularized the acronym. It means: if you have to walk away from this negotiation, how good are your other options?

In this case, our BATNA was not good: start from scratch, or try and find a better issue tracker to buy. It put us in a poor negotiating position and affected our psychology. You’ll see how it made us less willing to walk away from the deal and less willing to push back on terms we didn’t like.

Deciding on what to offer

The asking price was $128,000 USD or 3.5 times Seller Discretionary Earnings (SDE). In their great article on valuing businesses under $5M in revenue, FE International describes SDE:

SDE is the profit left to the business owner once all costs of goods sold and critical (i.e. non-discretionary) operating expenses have been deducted from gross income… more easily it is described as: Revenue minus Cost of Goods Sold minus Operating Expenses plus Owner Compensation.

In short, it’s the amount of money that the owner COULD pay himself after expenses are deducted from revenue.

Based on the factors in the FE SaaS valuations article we felt 3.5x was not unreasonable, but was on the high side.

We included these items in the offer in addition to purchase price:

  • Consideration (cash, terms, structure etc)

  • Closing date (this also forms an important part of the decision)

  • Source of funding (we will require proof of funds once the offer terms are accepted)

  • Due diligence requirements (an outline of any due diligence must-haves to ensure we can accommodate them for you)

  • Additional deal terms (e.g. Training hours, non compete, consulting etc)

Once we agreed on terms, we'd formalize the offer into a Letter of Intent (LOI).

Now, FE International has an "early access" list who see deals before they go out to the general public. We were on that list and thus saw this deal before it was posted on the web or sent to the general email list.

Since this went to the early access list, we wanted to make an offer for Codetree before it went to the general list. Which probably turned out to be a rookie mistake.

Here’s our first offer:

May 19, 2016

Hi Derrick,

Thanks for taking the time to talk with us yesterday. We think you’ve done a great job building Codetree and it has a lot of potential. We also like and know the issue tracking market. We’re excited to make you an offer and believe we’ll provide a good home for Codetree to grow.


We’d like to make an offer to acquire Codetree with the following terms:


We’d like to offer you an all-cash offer of $103,500 USD (2.8x SDE).

Closing Date

We’re motivated to close ASAP. Barring any unexpected issues found in due diligence, we would aim to close within 30 days.

We believe the major factors impacting close date are:

  • Your turnaround time on providing items for due diligence

  • Our respective lawyers reviewing the purchase and sale agreement

  • Our accountant reviewing Codetree’s financials

  • Our review of code and metrics

Source of funding

Cash in hand.

Due diligence requirements

Here are the items we’d need for due diligence:

  • Google Analytics, Baremetrics, Stripe, and Mixpanel data from 2015 to present

  • Income statement and balance sheet for 2015 and 2016 YTD

  • Bank account + credit card statements for 2015 and 2016 YTD

  • Visit to trial conversion %age from 2015 to present

  • Trial to paid conversion %age from 2015 to present

  • 2 customer calls

  • Live code walkthrough

Additional deal terms

We’d also ask for the following terms:

  • A non-compete prohibiting you from working on project management or issue tracking tools for two years from closing date

  • A linking agreement to keep two links to Codetree up on ScalingSaaS for two years from close date ( and

  • A non-disclosure agreement prohibiting you from publicly disclosing the selling price or number of paying customers at close

  • You make yourself available for 5 hours of training / support per week for 30 days after closing date

Factors Impacting Valuation

For us, risk is one of the key drivers that determines valuation. To understand the risk associated with acquiring Codetree, we looked at several factors that FE lays out here:


Codetree launched in Jan 2015, making it a little under 18 months old. We are optimistic about Codetree’s potential, but its track record of generating predictable and growing cash flow is not yet proven.

Owner Involvement

Although Codetree is on autopilot right now [ed: it’s not anymore!], if left in this state, it will slowly contract as competitors’ products will improve while Codetree’s won’t. We believe heavy involvement from technical owners over the medium term is required to grow it.

Trends + Churn

Growth has been flat since October 2015. Codetree appears to be growing and churning revenue at roughly the same pace.

Customer Acquisition Channels

Codetree seems to reliably generate a small number of trials via search and the GitHub Integrations directory. Codetree hasn’t yet found a scalable and reliable way to acquire customers, and that’s one of the biggest risks to an buyer.

Customer Concentration

Codetree’s customer concentration is low, which is great. Unfortunately, because the total number of customer is small, losing several customers at the highest price point presents a not-insignificant risk to revenue.

Customer Competition

Codetree has several direct competitors (ZenHub, Huboard, Waffle), a potentially reasonable substitute (GitHub Issues), and other major players in the Project Management space (JIRA, Pivotal, etc). We believe that competition for customers is high.

Product Lifecycle

You’ve built a great foundation for Codetree, but it’s not yet a mature product. There’s lots of product development to be done before an owner would be able to focus more on other parts of the business.

Technical Knowledge

Because Codetree is a tool for developers and development managers, we believe technical knowledge in an owner is highly desirable.


We believe the GitHub Issues niche is competitive and becoming more so. ZenHub is the biggest direct competitor given their access to capital. We believe GitHub Issues presents the biggest risk because it’s heavily funded and presents major platform risk.


Codetree’s MRR-to-ARR ratio is healthy.

There are significant risks associated with a purchase of this size, but we’re excited about this opportunity. We think our combination of Micropreneur mindset, SaaS experience, and interest in the dev tools space will make an excellent home for Codetree to grow and thrive.

We’re aligned with you in wanting to close quickly. We think that our 40+ combined years of software development experience will make this a fairly painless and fast transition for you, and we’re excited to move forward as soon as possible.

Thanks for your consideration,

Arif Bandali
Kareem Mayan
Ryan Stocker

David and Derrick declined the offer.

The 2.8x multiple was based on the comparables that we’d been looking at along with Codetree’s risk profile. We asked David to help us understand the asking price:

Help us understand the asking price

A brief aside: turns out the early access list is brilliant – for the sellers. FE’s job is to get the best terms possible for the seller. One way to do that is to test the market and see what price your deal will get in the early access period. If you don't get an offer you like, you get to go to the wider market at the end of the week. This gives the seller more information about what the market says their app is worth. It also creates urgency in the mind of the buyers ("if we don't buy it now, then it's going to a wider pool on Monday!")

Or at least, that’s what it did for us. Remember how bad our BATNA was? We really didn’t feel like walking away from this deal, but we had made a mistake.

Before making the offer, we had failed to play out the scenarios to their conclusion and determined our next move.

For example, it could have gone like this:

Scenario: we offer 2.8x SDE

Potential responseOur options
They accept.Celebrate!
They don’t accept, but lower the asking price.1. Accept their counter
2. Try and negotiate a lower price
3. Walk away
They hold firm on asking price.1. Increase our offer
2. Walk away

Doing this would have helped us understand the ways the negotiation could unfold. We would have been able to discuss the scenarios more rationally with biases like Scarcity Bias playing less of a role in our decision making.

But, since they were holding firm on price, our options were to increase our offer or walk away.

The difference between asking and our initial offer was $24.5k, or a little over $8k for each of us three partners. The question for us became: was it worth $8k each to walk away from this deal and start a product in this space from scratch?

The answer: heck no.

We believed that in the our hands Codetree could be a very good business. Given our BATNA, we decided to offer Derrick’s asking price. It was Friday around 6p when we sent over the offer, and we gave Derrick until Sunday at 9a to answer. We didn’t want him to have a full-price offer in hand to negotiate against when the deal went to the wider market on Monday.

On Saturday at 930a, Derrick accepted.

3. The Non-Binding Letter of Intent (LOI)

FE International supplied a template for a non-binding letter of intent. Since it was non-binding, either party could pull out of the deal at any point for any reason. The letter spelled out the terms and conditions that we agreed to in principle.

The deal was set to close on June 7th after about two weeks of due diligence.

Due diligence helps you find where the bodies are buried
art by revangale

4. Due Diligence (DD)

Due diligence is where you try and discover where the product, marketing, and revenue bodies are buried.

Here were the key risks we needed to understand:

  • Github would improve its Issues product

  • Were the customers real? How engaged were they?

  • Were users regularly signing up?

  • Would new users keep signing up?

To address these FE offered:

  • All supporting financial, operational and technical documentation

  • Live screen share sessions for source code review (as many as we wanted)

  • 1-2 customer interviews where we posed as Codetree customers satisfaction agents

  • Whatever else we needed within reason

FE has a great article on advanced due diligence here. We pulled their spreadsheet template for tracking DD tasks. Here’s our list:

Due Diligence Checklist

The bold items were things we needed to really feel good about to proceed with the deal.

Here’s what we looked for for each bold item:

Traffic sources

Is traffic highly concentrated in a handful of sources? If so, how likely was it to go away?

Visitor → Trial conversion and Trial → Signup conversion

We wanted to know how many visits we needed to get a signup so we could a) see how much upside there is in the funnel, and b) model customer acquisition costs.

Signups by referrer

We know where traffic is coming from; where were signups coming from?

Source code review + GitHub API integration

How hairy would it be to learn the codebase and start fixing bugs and adding features?

GitHub Issues Risk

How does GitHub view partners who build on their platform? How likely is it that they’ll improve Issues?

Revenue and expense verification

Do revenue and expenses line up with the Profit + Loss statement in the prospectus? We found a red flag here that we’ll get to.

Cancellation reasons

Why are customers leaving? Are the reasons fixable or not?

Stripe revenue verification

We needed to make sure that the revenue from the bank account was from the Codetree Stripe account. A formality - Derrick was trustworthy - but we’d be stupid not to confirm.

Support ticket analysis

What kinds of problems were customers having? How did they talk about the product? Were the happy or unhappy?

Customer phone calls

How do customers talk about Codetree? How is it integrated in their workflow? How could Codetree help them even more? We spoke to two customers who gave us pretty fair and balanced views on the product and how it worked for them.

Engagement data

How often are customers using Codetree? What are they doing in it?

Due diligence was a pain but gave us peace of mind that we were making a good decision.

Revenue and Expenses Red Flag

We only found one red flag in due diligence. It was a discrepancy in actual revenue and expenses vs what was in the profit and loss statement (P&L) in the prospectus. Since the purchase price was a multiple of earnings in the P&L, this had the potential to non-trivially lower the price.

Red flag with the expenses

Credit card statements showed that SDE was overreported by $652. Based on a 3.5x multiple on SDE, our $128,000 offer should actually have been $2,282 less ($652 x 3.5).

We pushed back on this, and on adjustments at closing.

Adjustments at Closing

Codetree collects money before the service gets delivered. An annual customer would pay for a year on e.g. January 1st for service over the next 365 days. And a monthly customer would pay on e.g. June 1st for service over the next 30 days.

Adjustments at closing are a money transfer from seller to buyer. This is so that the buyer gets the revenue for the service he’s delivering after the purchase occurs. Adjustments are usually reflected in a lower purchase price.

Here’s an example:

Let’s say the seller collects $1200 from a prepaid annual customer on Jan 1st. The seller ends up selling his company on June 1st. The seller has only delivered service for 151 days, but has collected payment for 365. So the seller would transfer (365-151)/365 * 1200 = $703 to the buyer at closing. This $703 represents 214 days of revenue that the new buyer would service after the purchase, until the customer was up for renewal again.

Revenue collected but unserviced by Derrick totalled $4,223 as of our June 7th closing.

Negotiating the Revenue Discrepancy and Adjustments

We let David know about the discrepancy and adjustments and expected the price to be lowered accordingly.

David pushed back, basically saying that May’s earnings were up, so if FE listed the business on June 1st, the actual asking price would be $135k. He ignores the annual unserviced revenue and says that if we took the $2.1k in unserviced monthly customer revenue, and multiplied it by 3.5x, and subtracted it from the "new" purchase price, we’d net out at roughly 128k (135 - (2.1*3) = 128.8k).

Remember, FE’s job here was to get the best price for their client. Let’s unpack this response a bit:

  1. The purchase price was $128k, not $135k. One reason for the big earnings bump in May was an annual client. Their revenue for valuation purposes shouldn’t really be lumped into a single month - 1/12th of it should be booked every month.

  2. We were asking for unserviced revenue to be removed from the purchase price, not unserviced revenue * 3.5x.

  3. We weren’t sure how to value the impact of collected but unserviced revenue on purchase price. It inflated the purchase price because there were no expenses booked against it yet, but we ran an analysis and found the difference to be not worth negotiating.

  4. He ignores the fact that unserviced revenue is actually 4.2k, not 2.1k.

tl; dr - we thought David was using convenient numbers to get the best deal for his client.

Our crappy BATNA loomed large, and we weren’t willing to lose the deal over a few thousand dollars. We didn’t even push back on the expenses discrepancy - we conceded it.

But we looked at the data and called David out on booking an annual sub in May to inflate MRR. We also pushed back on the adjustments at closing.

Adjustments at closing

David responds by ignoring the fact that he’s counting all of the revenue of an annual sub as profit and reiterating his point.

We respond once more:

More adjustments at closing

David says no to adjustments at closing. He concedes the point that in "normal" deals of this nature we’d get $4k off the purchase price. This deal, apparently, was abnormal because there were other buyers in play.

Gut-check time

So, gut-check time. How hard did we want to push back on this? Were the other buyers really serious, or had they just expressed some interest? We were at the end of the due diligence period. If we pushed back, would Derrick really want to go through all this with another buyer, only to end up with them insisting on the same adjustments?

Odds are high that if we pushed back, David would have either conceded at least some the adjustments. But maybe not - maybe it would have been take it or leave it, in which case we'd be no worse off.

In the end, we didn’t even bother to find out what David would have done if we made the adjustments a point that we were willing to walk away over (or at least had them think we were willing to walk away over it). We decided that it wasn’t worth $1.4k each to potentially lose the deal so we conceded the $4.2k adjustments at closing.

Lesson: if you’re going to push back on price you need to be willing to walk away if you don’t get what you want. (click to tweet)

David did a great job for his client. If we ever sell a SaaS business, we’d definitely look to him and/or FE as representation.

A poor BATNA makes it more likely that you'll come out on the wrong end of a negotiation
art by revangale

5. Asset Purchase Agreement

After getting beaten like rented mules on the purchase price, David sent us an Asset Purchase Agreement. It’s a legally binding contract to purchase the Codetree assets from Derrick’s LLC. There were a few minor clauses that we wanted tweaked (clarifying Derrick’s non-compete, making sure we had enough time to evaluate the assets, confirming that we could talk about the deal publicly in articles like this), but we sorted them out in a day over email.

6. Closing

We funded an account with the agreed-upon amount. On closing day, once the funds in Escrow had been verified, Derrick sent over passwords to Codetree and all the services it uses. We started the "inspection period" in Escrow, which was set to three days. We had three days to verify the assets were delivered as promised. At the end of three days, if we hadn’t raised a red flag with, they would release the funds to Derrick. The assets were great, and funds were released after three days.

We were officially the new owners of Codetree. It felt good to know what we were going to work on for the next 7-10 years of our lives, but the real work was just beginning.

What's next

We’ve owned Codetree for almost four months. In the upcoming month we’re going to share how we've gotten up to speed with the business, and some of our successes and failures. Drop your email in the box below to follow the journey.

Thanks to konczykp, ezrabg, ashr0se, kevhuang, BryanBurke, gdecampo, Andrew Ritchie, dnlhtz, ajwaxman, scottraio, and alberthong for the questions.

The Important Differences between GitHub Projects and Codetree

You may have seen that GitHub launched a feature called "Projects" at their recent conference, GitHub Universe. On the surface Projects appears to be a Kanban board that lets you manage your project. But if you dig a little deeper, GitHub Projects is different from Codetree's Kanban boards in several significant ways.

Click here if you want to skip to a table that summarizes the key differences between Codetree and GitHub Projects.

In this post I’m going to unpack GitHub Projects (GHP going forward) and cover four things:

  1. What is a GitHub Project?

  2. How do Projects work?

  3. What can I use them for?

  4. How is Codetree different?

1. What is a GitHub Project?

GHP lets you create multiple Kanban-style boards within a repository. Each board can have custom stages. It’s a very lightweight Kanban tool, like GitHub Issues is a lightweight issue tracking tool. It is very Trello-esque: a card can be an issue or a note (more on notes below), and cards can be dragged and dropped from column-to-column.

2. How do GitHub Projects work?

They’re Kanban boards. We’ll cover how to create a board, and then talk about three wrinkles that you might not expect:

  1. Boards exist within repos

  2. Boards contain a subset of issues

  3. Issues can belong to multiple boards

Creating a project

There’s a new Tab in the GitHub UI called Projects:

New Projects tab in GitHub UI

When you create a Project, you first define the stages in that project.

Customize your GitHub Project workflow

Boards can have different stages from other boards in the same repo.

Boards exists within a repo

A GHP lives within a repo. Which means you can only add issues from a repo to a board that lives in the same repo.

In other words, if you need to see a rolled-up view of issues across multiple repos, GitHub Projects won’t work for you.

Boards contain both notes and a subset of issues

You can create as many Kanban boards as you want within a repo. Each board contains a combination of a subset of issues in the repo, and a new construct called a "note". We'll cover both.

Adding an Issue to a Project

Issues need to be manually added to a project - a GHP has no issues when you create it.

Add issue to GitHub Project

If you’re trying to use a board to manage your entire project, you’ll probably be frustrated at having to add every issue to your board manually.

Adding a Note to a Project

GHP introduces the concept of "notes". Notes are simply plaintext snippets that you add to a board. They can be easily converted to a full-fledged Issue.

Add Notes to GitHub Project

Issues can belong to multiple boards

An issue can belong to multiple boards at once. You can see what stage and board(s) an issue belongs to on the Issue page:

View project and stage on an issue

3. What can I use GitHub Projects for?

There are three obvious ways to use GitHub Projects (and plenty of non-obvious ones, I’m sure!)

  1. As a proxy for Epics

  2. To track an assignee’s work

  3. To track issues within a milestone (e.g. a Sprint)

GitHub Projects as a proxy for Epics

GHPs are simply a way to group together a set of related issues and to visualize them. One way you may want to group issues together is if those issues are children of a larger feature. You can use a board to track the N features that need to be finished to deliver some larger feature.

Tracking an assignee’s work

You could create a board for each developer on your team and track their work as it gets delivered.

Track issues within a milestone

You could create a board for each milestone and see the work remaining before closing that milestone, what stage it’s in, and who it’s assigned to.

4. How are Codetree’s Kanban boards different from GitHub Projects?

There are several differences between Codetree and GitHub Projects that may be important to you.

Multiple repos

First, Codetree will show you all your issues from as many repos as you want rolled up into a single Kanban board. GitHub Projects can only show you a Kanban board that contains a subset of issues from a single repo.

Define your Kanban workflow once

In Codetree, you define your workflow once. All issues go through that workflow. In GitHub Projects, you need to define the columns on your board for every board you create.

See all your issues, automatically

Codetree’s Kanban board will automatically show you all your issues from your repos. You don’t need to add issues to your board - you can see them all.

With GitHub Projects you need to manually add issues to a board.

Filter your issues

Codetree lets you filter your board by multiple criteria to see the issues you want to see. Filter by milestone, assignee, and a whole lot more. You can combine your filters too - "Show me issues assigned to Joe for the Oct milestone with the ‘UX’ label". You can save your filters for quick access later.

GitHub Projects doesn’t offer any of this.

image alt text


Here are the key differences between Codetree and GitHub Projects.

TaskCodetreeGitHub Projects
Multiple Repo Support Shows all your issues from multiple repos in one view Shows subset of issues from single repo
Defining your Kanban Workflow Smart default. Just need to do it once No default. Need to do it for every board you create
Adding issues to a board All issues added automatically Need to add every issue manually
Filtering your issues on a board Filter by milestone, assignee, labels, creator, and more. No filtering
Combining filters Combine as many filters as you want, e.g. "Show me issues assigned to Joe for the Oct milestone with the ‘UX’ label" No filtering
Save shortcuts to filtered boards As many as you want - your filtered boards are a click away after you save the shortcut. No filtering or shortcuts

Use Codetree to Manage your entire project

If you want to:

  • Define your Kanban workflow once…

  • And automatically see all your issues in a single Kanban board…

  • Across the repos you choose…

  • While being able to filter them down to the issues you want to see…

  • And saving shortcuts to those views…

Then Codetree may be a better fit for you than GitHub Projects.

You can try Codetree out for free for 14 days here.

A framework for picking and funding your business idea

How do you decide whether to work on an idea you have? And how do you finance it? These are key questions that every entrepreneur has to answer. Here's the framework we used to pick a good idea to work on, and the four financing options we explored.

This is part two in a three-part series. Part one was about how we defined success for our new, creatively-titled venture "Next Biz". This post is about how we evaluated the different paths to maximize our chances of success. Part three covers the details of buying Codetree.

Best Path to Accomplish Our Goal

The first step was to define what success looked like for us. The next step was to figure out the path that would give us the highest chance of getting there.

There were two things we need to figure out:

  1. What problem would we work on solving, and

  2. What financing model would be most likely to lead to a successful outcome?

Choosing a good problem to solve

We’ve built four successful SaaS businesses, and consulted with companies that have done $100M+ in revenue. We have the battle scars and seen them on others. Based on these mistakes and wins, we built a set criteria to evaluate opportunities. We broke these criteria down into the "must haves" and the "very nice to haves".

Must-have criteria

Here are our must have criteria:

1. Does the business HAVE to solve the problem?

Does the product solve a hair on fire problem ("I'm a sales person and need a CRM to track my deals")? Or is a must-have ("I need to process credit cards online")? Or core to business ("I need a member management system to run my gym")? Are we selling something where the customer’s thought process is "which [blank] are we going to buy" rather than "do we need to buy [blank]"?

In short: you want to make sure you're solving a hair-on-fire problem (click to tweet).

Make sure you're solving a hair-on-fire problem
art by revangale

2. Clear return on investment

It’s much easier to sell revenue growth or directly-attributable savings instead of time savings.

3. Market size > $30M

Sequoia invests in large markets because your upside is not capped by a small number of potential customers. Large markets also have lots of niches to serve - especially important for bootstrappers.

4. Can we segment and reach customers?

It’s much easier to e.g. make a list of your potential customers and call them up (e.g. "a tool for VPs of HR") rather than a horizontal tool where “anybody is your customer”.

5. High Lifetime Value (LTV)

It should be valuable enough and core enough that customers rarely churn.

6. 10 year check

Can we imagine yourself doing this for 10 years and enjoying it? We’re in this for the long haul so let’s enjoy the ride.

7. Is the nature of the work required generally enjoyable?

If not, why on earth would you start?

8. Operationally simple

CRUD apps are preferable to businesses that scale with humans, or that have lots of software complexity.

9. Software errors aren't catastrophic

If you’re running Heroku and it goes down, your customers bloody hate you because they’re losing money. If you’re running a help desk and it goes down, it’s an all-hands on deck emergency. It's only marginally less stressful than if you’re running Heroku. But that margin lets us sleep better at night.

10. Gut check - does this feel right?

Pretty straightforward.

Secondary Criteria

We also ranked every opportunity against these "nice to have" criteria.

11. Growing Market

A rising tide lifts all boats.

12. Self-service signup

Can we imagine a scalable acquisition channel that doesn't involve Inside Sales or Field Sales? We don’t enjoy inside or field sales, so self-service sales is preferable.

13. Recurring revenue?

It's great that you're not starting every month at 0, but with a cushion of revenue to budget against.

14. Straight software

One of the last businesses we ran was essentially a data-entry service for gyms. We had a team of 10 people who entered data and thus delivered value for our customers. Without them the business didn't work. This was a more complex business to run than one that only used software to deliver value to customers.

15. Average Revenue Per User (ARPU) per month > $300/m

It’s hard to get to scale when ARPU is low.

16. Selling into departments at companies

A manager spend his or her company’s money for their team is a low-friction sale. Much lower than spending your own money or buying for a large company. This also enables a land-and-expand strategy where you spread from department to department.

17. Decision maker doesn't need approval to buy

The price point is "cheap" (under $1k/m). This is low enough to fly under most companies’ expensable limit.

20. SaaS

On-premises software? No thanks!

21. No critical partners or regulation

The fewer obstacles between us and success, the better.

22. MVP Bootstrappable in < 3 months

This lets you get customer feedback (and revenue) ASAP.

23. Are we good at it?

We wanted to stay in our "Circle of Competence" to have a high chance of success.

25. Are we interested in the problem?

This helps, a lot. When a problem is intrinsically rewarding to work on, the hard times are easier to get through than if there's an extrinsic rewarded.

25. Do you feel good about solving the problem?

Where are we on the spectrum of selling cigarettes to children (bad) vs curing cancer (good)?

26. Do we like the customer and would we enjoy helping them?

Always good to like the customers you spend your days talking to and helping.

27. Is this a good fit for our skills and temperaments?

We like businesses that will do well if you put one foot in front of the other. Build a good product for a painful problem, know who you’re selling to, and sell it. The alternative is a business that has an inflection point that may or may not happen. For example, a social network that makes money only after it gets to a certain size.

We tried not to make stupid mistakes

You can see that most of our criteria were relentlessly focused on helping us avoid being stupid. We’re big fans of saving our cognitive cycles. One way to do this is to use checklists, so we made a spreadsheet to evaluate the businesses we thought about starting.

You can view and copy our 27-criteria checklist for vetting business ideas here.

Generating Ideas

Once we knew our criteria, we needed some ideas. The basic process we used for finding an idea was:

  1. Generate ideas

  2. Run them through our criteria spreadsheet

  3. Do a deep dive on ones that passed the filter.

We took three approaches to generating ideas:

  1. What problems did we had in our own lives, our clients’ lives, or running previous businesses?

  2. What internal tools had we built to solve our own problems or have we seen others build. This is indicative of such a painful problem that they took steps to build something to make the pain go away.

    As an example at our last business we built these internal tools:

    • Customer retention email tool (e.g., Vero)
    • Outbound cold email tool (e.g. Tout)
    • Dunning tool (e.g. Churnbuster)
    • A set of monthly SQL queries to calculate new signups, churn, etc. (e.g. Baremetrics)
  3. We sorted a list of SIC codes by market size and looked at businesses who sold to those customers

We generated about 30 ideas. Here are the ones we seriously considered:

Tool for Product Managers

Having been PMs before, we identified five problems that we know most PMs faced during their day to day. We spoke to ~20 Product Managers at companies like Slack, Hootsuite, and GoDaddy. Ultimately we learned that the biggest pain PMs have is around communication. The other pains needed vitamins, not painkillers. We weren't excited about solving the communication problem, so we passed.

Influencer CRM

This tool would help a marketer build relationships with people who had an audience that the marketer wanted to reach.

Here’s how we stumbled on this pain. When we were exploring the PM tools idea, we built This was to build an audience of Product Managers. The idea came from this excellent talk by Iris Shoor. has 120+ evergreen categorized resources to help PMs get better at their jobs.

To get the word out, we took this excellent advice from Alex Turnbull to start building relationships with influencers.

This process was a royal pain in the butt, but massively valuable. A tool could automate a lot of the grinding and we think this could be a big business. We ultimately passed because serving marketers is not in our Circle of Competence.

Recurring Processes Tool

Many businesses run on recurring tasks that involve moving data between systems. We think there’s an opportunity for a recurring-checklist-meets-API tool so managers can:

  1. Make sure the right work is getting done to the right level of quality and

  2. Save line employees a ton of time when doing the work

The problem here is that there aren’t a ton of people looking for a solution, so the sale is educational. First, people need to understand they have the problem. Then they need to understand why your product will solve that problem better than other products. This business fails the "which [blank] should we buy" test. It's more like "I didn't even know that we have a problem that your tool would solve."

WeChat on North American Platforms

We think there’s a big opportunity to be had by connecting local service businesses to their customers via a messenger app. Why? Because you just need to look at Wechat to understand that the future’s here, it’s just not evenly distributed yet.

In the last few months both Facebook and iMessage opened up their platforms to "bots". If you believe WeChat is the future, the winner won’t be AI-driven bots, it’ll be mobile-optimized apps that run in a messaging platform. Dan Grover, a Product Manager at WeChat has an excellent overview of what he thinks will be successful. Another great resource is this great a16z podcast where analyst Connie Chan talks in detail about why she believes the WeChat model will be successful in North America.

We think this is a legitimate billion dollar business opportunity. But we passed on this because our definition of success doesn't include taking a homerun-or-strike-out swing.

Software Issue Tracker

We’ve done a bunch of engineering management work over the years. We've looked for issue tracking tools that are easy to use and just opinionated enough. JIRA is the beast in the space, but it doesn’t work well for the approach we use. It's also frustrating to use. Fogbugz is probably the closest to what we’d use. But it seems like the redheaded stepchild in the Fog Creek family (apologies to redheads, we ❤️ you). Pivotal is a good tool but too opinionated.

As more companies become software companies, issue tracking is a large, growing market. It's a must-have, and it seems like there’s lots of opportunity. We’ve been devs and run teams at bootstrapped, venture-funded, and big companies. This was squarely in our Circle of Competence.

What we decided to build

Ultimately, we decided to build an issue tracker for software teams. An issue tracker checked all the boxes on our spreadsheet except "ARPU > $300" (which we could probably fix in the long term) and "MVP Bootstrappable in 3m" (the surface area of an issue tracker is broad).

Other reasons we decided to build an Issue Tracker

  • Every company is becoming a software company. Those developers will need tools to use to build said software. The market is huge and growing.

  • Once you get past a team of 1, an issue tracker is a must have. It’s not "do we need an issue tracker" but “which issue tracker will we use”?

  • We recently tried to find an easy to use tool to fit a fairly straightforward workflow. It was painful.

  • We have informed opinions from 45 years of combined software dev experience about what works and what doesn’t. We know how a tool can be paved to make it easy to do the right activities that encourage shipping good software.

Does the world need another Issue Tracker?

The biggest risk to building something is that nobody wants it. To de-risk this, we're big fans of resegmenting an existing market. To do this, we slice off a piece of an existing large market that is underserved by existing solutions. A good example is Pipedrive making an easy to use and cheap CRM for SMBs who would find using Salesforce to be overkill and expensive.

Is his excellent podcast called Seeking Wisdom, David Cancel calls this concept "innovation vs invention". Innovation means taking an existing solution to a painful problem and making it better. Invention means you're creating something brand new, and is a lot riskier. (click to tweet)

We think there's room for innovation in most large markets. Issue Tracking checked all the necessary boxes for us and we didn't want to take the higher-risk path of inventing something from scratch. So Issue Tracking was the problem that we wanted to solve.

The next question was: what financing approach should we take?

Build or Buy or Bootstrap or Raise

The mythologized entrepreneur’s journey involves a flash of inspiration, a boatload of VC money, and some hard work. A multitude of riches are the spoils. But it turns out there are more options to finance a company than the ones shared by your favorite breathless journalist. (click to tweet)

Here are the four options we considered:

  1. Build from scratch and raise angel / VC money

  2. Build from scratch and bootstrap

  3. Buy a large business with debt and / or equity financing

  4. Buy a small business outright

We ended up on #4, but we'd like to share our thinking on all four options.

1. Build from scratch and raise angel / VC money

This is the path that most tech entrepreneurs in 2016 think is the only path. Our definition of success made this the least attractive option. Two of us have had experience as execs at VC-funded companies. The challenges go beyond finding product/market fit, which is tough enough. They also include fundraising, managing a board, being fireable, having a diluted equity stake, and being pressured to spend money faster than necessary. These were all problems we didn’t want to deal with. We’re not averse to raising money as growth capital, but raising from scratch didn’t make a ton of sense for us.

Venture returns follow a power law distribution. This means the vast majority of returns re from a few winning portfolio companies. For example, as of Jan 2016 AirBnB was worth $25.5B, while the other 939 YCombinator-funded companies were worth $40B combined. What are the odds that we’d be an AirBNB? Slim to none: it’s a lottery ticket. If we weren’t going to and didn't want be an AirBNB, the odds of a successful outcome going the venture route were zero. (click to tweet)

2. Build from scratch and bootstrap

We'd gone down this path a few times and was our default. Back in the day building from scratch was exciting. But now, older, possibly wiser, with more family and less time, it was daunting. We’d spend a year to figure out if there was really a "there" there. Like a solid safety school, we were resigned to this path if none of the preferred choices worked out.

3. Buy a large business with debt and / or equity financing

Constellation Software is an interesting company that does private equity-esque transactions in tech.

They’re an $11B publicly traded company whose model is to:

  1. Buy software businesses making ~$200k+ ARR in desirable markets

  2. Incentivize the business owners to grow the business while being hands off

  3. Profit

Their model is similar to Berkshire Hathaway's, but for software. If you want to learn more, their IPO Prospectus (CMD-F to search for "apr 3 2006" in the page) lays out their strategy. To an outsider’s eye, it seems fairly consistent even 10 years after they’ve gone public.

Running across Constellation piqued our curiosity. We modeled out what kind of cash flow we'd have if we bought a large business. We even cold emailed and spoke with a few companies in segments that we thought would be good acquisition targets. (Dental Practice Management systems was one space - thank god we didn’t end up there).

Here are the problems with buying a large business with debt and/or equity capital:

  • First, the core skill you need to make this fly are finance skills, not software.

  • Borrowing a lot of money - likely with personal guarantees - made us think it’d be hard to sleep at night.

  • We’d most likely buy a slow growing but stable, vertical solution. This is because growth is expensive. A fast-growing tech business is going to sell for a crazy revenue multiple. This high multiple will prevent you from paying down your debt from the business's cash flow. For example, we talked to a high-growth SaaS business that had negative earnings. Their asking price was $15M. If we financed that purchase there would be no way to pay down the debt financing because all the cash flow was going to fund growth.

  • If we raised debt and equity, we’d spend 7 years paying back a ton of debt. And unless we got an unlikely sweetheart deal from investors, our ownership percentage would have been less than 50% combined. Based on how we defined success, this scenario wasn't what we were looking for.

This was an extremely useful exercise to go through. We’ll likely go down this road later. Buying stable and predictable cash flows with leverage can pay massive dividends over time (click to tweet). It was a worthwhile investment to learn about Constellation and a little about private equity.

If you want to see the spreadsheet we used to model out what it’d be like to buy a business, you can view and copy it here.

4. Buy a smaller business outright

"The reason for buying small SaaS businesses is that it's so hard to start anything from scratch. Even a business doing only $5,000 in MRR has validated something significant, and that makes the business valuable." (click to tweet)
- Hiten Shah

After Rob Walling started Drip, he said something like "now that I know how much work it’ll be to start something, I’ll never do it again". He had a good basis of comparison because he bought and grew HitTail before starting Drip. We sold a SaaS business a few years ago and were curious about how big a head start we could get if we bought a business.

Buying a small business can give you a good headstart
art by revangale

So while we explored buying a large business, we also explored buying a smaller business outright. This was the most attractive option. It enabled us to control the company without taking on massive debt. It also giving us a headstart on finding product/market fit. Being able to phone up just ten paying customers on day one to understand how to make the product better is a big win (click to tweet). Plus, revenue on day one is always nice.

When we ended up

So on Friday May 13th 2016 we had decided to focus on the problem of building an issue tracker for software teams. And we had a preferred approach: buy a small business, with bootstrapping as a backup plan.

It took a year

To get here took introspection, many (frustrating) conversations with each other, lots of spreadsheet modeling, conversations with all kinds of willing customer development subjects, tons of reading, research, and cold emailing, and a bunch of dead ends (or "learning opportunities"). It took us a year working part time to get to this point. But we felt good about where we ended up.

Next up

Part three is about how we ended up buying Codetree. We'll talk about how we ended up at the purchase price, share actual emails from the negotiation, talk about the risks of buying Codetree, and a whole lot more.

To get the next part of the series when it drops, leave your email below.

How to avoid building a company that you'll hate

How do you know if the business you're running will enable you to live the life you want to live? This was a major question we grappled with during our year-long search for our next business venture, a process we imaginatively termed "Project Next Biz".

This is the first in a three-part series. In this post, we'll talk about how we defined success for "Project Next Biz". We'll also share the framework and exercise we used to figure that out.

Part two is about how we evaluated the different paths we could take to maximize our chances of success. We'll share the framework we used to choose an opportunity to work on for the 7-10 years it takes for a SaaS business to hit its stride. We'll also talk about how we arrived at our ideal financing approach. Hint: venture-backed isn't the only road.

And part three will unpack the details of how Next Biz led to buying Codetree. We'll talk about:

  • how we ended up at the purchase price
  • our psychology during the negotiation
  • the risks of buying Codetree
  • and a whole lot more

A little about us

A little about us before we jump in. We're three business-minded software devs with 45 combined years of professional experience building software. We've started, run, folded and sold several SaaS businesses. We've done venture backed and bootstrapped startups. We've worked at companies like Microsoft, ESPN, and MySpace. We've worked together before and we wanted to work together again.

Defining Success

"It is remarkable how much long-term advantage people like [Warren Buffett and myself] have gotten by trying to be consistently not stupid, instead of trying to be very intelligent." -- Charlie Munger

We're big fans of Warren Buffett's business partner Charlie Munger. Charlie is big on avoiding mistakes and our past ventures had given us a long list of mistakes to avoid. One mistake we'd made is that we'd never defined success when starting previous companies. We'd skipped this step and headed right to the problem/solution and financing approach.

With Next Biz, we didn't want to make that mistake again.

Munger talks about the concept of "inverting". He borrowed the idea from German algebraist Carl Gustav Jacob Jacobi, who said "Invert, always invert." In a 1986 speech Munger said: "It is in the nature of things, as Jacobi knew, that many hard problems are best solved only when they are addressed backwards."

In other words, begin with the end in mind. If you don't know where you're going, you'll end up in the wrong place by definition. (click to tweet)

Before you begin, decide where you want to end up.
art by revangale

A useful exercise

One exercise we did to figure out where we wanted to be was to write down what a day in our lives looked like when Next Biz was successful. We answered things like:

  • Who were we working with?
  • What kinds of things were we doing? In what parts of the business?
  • What kinds of customers were we serving?
  • What kinds of problems were we working on?
  • How much were we making?
  • What was the culture like?
  • What kind of office did we have?
  • Who did we talk to regularly?
  • How many reports did we have?

Each of us did this independently and talked through our answers with each other. We drew on our own previous founder experiences, conversations with other founders, and things we'd read to paint a picture of what an ideal day looked like.

We all had similar ideas about what we wanted our world to look like. There were also factors that one of us raised that the others hadn't thought of and agreed on. We'll cover those below.

This was a helpful exercise to realize that we didn't care about being on TechCrunch, or managing a board of directors, or ringing the bell on the NYSE, or having a company with 500 employees.

After doing this exercise, it turned out that the things we talked about fell into two buckets: the non-financial success bucket, and the financial success bucket.

Non-Financial Success

We admire companies that focus on making customers happy, charge for it, and do it on their own terms. Their owners can control how they spend their scarcest resources: time, attention, and energy.

Companies that we look to as models are FogCreek, Basecamp, Wildbit, Help Scout, Buffer, and Zapier.

Every business has criteria that determine whether your day will be painless or painful. Will you jump out of bed, excited to face the day at the office? Or will every minute at the office be soul-crushingly painful?

Here are the criteria we used to determine whether we'd enjoy working on the business or not:

  1. Sales Model

  2. Operational Complexity

  3. Accountability

  4. Company Size

  5. Team

  6. Nature of the work

Of course, your criteria may be different. There isn't a right and wrong here, just better and worse for you (and for us). Our goal here was to identify what would constitute non-financial success for us.

Let's unpack the criteria.

1. Sales Model

Do you rub your hands in glee at the thought of coming into the office and talking to prospects all day? If so, you're probably better off selling to customers with a high Annual Contract Value (ACV).

Perhaps unintuitively, ACV drives a lot of the mechanics of your business. Nick Mehta from Gainsight says "ACV is everything". What he means is that when you have customers with a high ACV:

  • You're probably selling to Enterprise customers

  • You have longer sales cycles

  • You have contract negotiations, and they're often painful

  • The buyer isn't the user. This means sales skills are often more important than building a great product

  • Churn is probably lower

  • You can get to scale quicker

When you're selling to customers with a lower ACV:

  • A great product is important because the buyer is often the user

  • It's harder to get to scale

  • Churn is often higher

  • A self-service sales model is possible

  • Marketing is important to drive traffic and potential customers to your site

Christoph Janz says you can build a $100M company by selling to one of five sizes of customers. He calls them Elephants, Deer, Rabbits, Mice, and Flies. Elephants are the biggest customers that pay the most; Flies are the smallest and pay the least.

The 5 sizes of customers

The way to sell to these customers differs. On one end of the spectrum, Elephants require in-person sales people. On the other, Flies either have a high viral component, or user-generated-content component that fuels huge SEO traffic.

Mark Suster also talks about this in Most startups should be deer hunters.

We know that while we love talking to customers, hand-selling doesn't give us energy.

There's a lot of good that comes with selling to customers at a higher ACV. But we knew we'd be happier making a great product and focusing on marketing. So we decided to start with smaller customers. Janz calls the approach we're taking "hunting rabbits". We wanted to start off "hunting rabbits", knowing that we might grow to "hunting deer", and that we don't want to "hunt elephants".

2. Operational complexity

Operational complexity can dramatically impact quality of life. We've run operationally complicated businesses. One business has hundreds of software scrapers that often break. Another was a web app that relied on people to do a lot of data entry. Those were more painful than the straight software businesses we'd run.

We'd much prefer to run an operationally simpler, straight-software business.

This was a factor that one of us raised as being important to him that the others hadn't thought of. After contemplation and discussion, we agreed that it impacted happiness enough to weigh it heavily when considering non-financial success.

3. Accountability

We wanted the people we work with and our customers to hold us accountable, not investors.

4. Company size

None of us want to run a huge company. 100 people would be pushing it. We'd prefer to work on the business than manage people and deal with the inevitable politics and bureaucracy that comes with that. So having a small, excellent team was better than a large one.

5. Team

We like the idea of working with nice, talented, motivated, self-managing people. Buffer, Zapier, Help Scout, and Basecamp are companies we admire who do this well.

6. Nature of the work

In every business there are going to be some tasks that you really don't want to do but that you'll have to do anyway. But to the extent possible we'd prefer the business we're working on to reward us for focusing on the tasks that we actually enjoy doing. For us, those tasks are:

  • talking to customers to understand their problems

  • using that knowledge to make the product better

  • and marketing the product

Non-Financial Success: where we ended up

Here's what we netted out:

  1. Initially, a low-touch sales model that plays to our strengths: building and marketing a great product

  2. A business that's operationally simple

  3. Being accountable to our customers, each other, and our team

  4. Having a small company of well paid, professional co-workers

  5. Enjoying the nature of the work

Seeing these written down may seem obvious. But optimizing for these doesn't happen by accident. We determined that these criteria were important because we'd run businesses that operated under different, less pleasant circumstances. And we ended up running those businesses because we hadn't taken the time to ask ourselves – before we started – what success looked like.

Financial Success

It's difficult to isolate success in financial terms because it's tied up in non-financial success. For example, if you're aiming to be a billion dollar company, you probably need to raise money. This means you'll have investors and a board that you need to manage (and that can fire you). Below, we share how we tried to tease out what financial success looked like to us.

Venture backed tech companies are built to get huge or die. Like a lottery ticket, you either win big or lose. But outside of tech, it's common to run a business to generate free cash flow for its owners (click to tweet).

Interestingly, huge markets where subscription SaaS is the dominant business model aren't winner-take-all. Look at the CRM market. There are many billion dollar companies (Salesforce, Veeva, Oracle, MS Dynamics, etc). But there are also many companies making $1M - 10M in ARR whose owners can choose how to spend their time. You can find similar examples in huge markets like project management (Basecamp), help desk (Groove), time tracking (HubStaff), marketing automation (ConvertKit), etc.

Jason Cohen's Rich vs. King post is helpful here. Essentially, the choice is between having a lottery ticket ("Rich"), or having control of your destiny and earning a good income while building an asset ("King").

Company founders are either in it for the money ("Rich") or in it to build a lifestyle and personal identity ("King"). FogCreek and 37signals are built to be "King;" all venture-funded companies are built to be "Rich."

At his last company, Smart Bear Software, Jason became both Rich and King by initially focusing on being King. He retained control and focused on profitability. He didn't raise a boatload of VC money and hope his company would be acquired. His company's profits enabled him to build the kind of company he wanted.

Do you want to be rich, or be king?
art by revangale

Ironically, Jason discovered that Rich vs. King is a false choice. Jason focused on being King and building a great, profitable company. Because he did, he ended up becoming Rich when his company was acquired for life-changing money. Jason ends his post with this:

I can stay home with my wife and new baby girl for as long as I want, having all the precious time and experiences and memories that they say money can't buy.

We asked ourselves two questions to figure out whether we wanted to be "Rich" or "King":

  1. How important is controlling our own destiny?

  2. Do we want to optimize for steady cash flow, or for a billion dollar company?

We had already figured out that controlling our destiny was important to us.

To answer the second question, we looked at the chances of achieving steady cash flow versus becoming a billion dollar company.

Steady cash flow

We'd already started four cash-flow generating companies. We'd made upside-limiting mistakes with previous businesses, so none of them got as big as we would have liked. (We'll cover these mistakes in part two.)

But building a company than generated substantial cash flow seemed achievable. Especially if we did it in a large market with a must-have solution to a painful problem.

Billion Dollar Company

There's nothing wrong with wanting to build a billion dollar company. We need people that want to do this. But before you go down this road though you should make sure you really are one of those people. You want to make sure you're doing it for well thought-out reasons and that you have a firm grasp on the math. Don't be fooled by survivorship bias or breathless media sensationalism about the latest rags-to-riches entrepreneur - those are the exceptions, not the rule. (click to tweet)

To build a billion dollar company you need to:

  1. Pick the right problem and solution

  2. Get lucky

  3. Catch lightning in a bottle

  4. Have your investors' agendas stay similar to your own

Let's drill down on each of these.

1. Picking the right problem and solution

If you don't offer a must-have solution to a hair-on-fire problem in a huge market, the odds of joining the tres commas club are zero. Picking the right problem and market aren't hard if you're resegmenting an existing market. You pick a big, existing market and serve a smaller slice of it better than the incumbents. But finding the right solution for that slice of customers is tricky and time consuming. Plus the slice needs to be big enough to eventually become a $1B company.

2. You get lucky

You have to get lucky to cash out. What if Yahoo decided to take Larry and Sergei up on their offer to buy Google for $1M? Or if Mark Zuckerberg sold Facebook for any of the offers he had before the company became a beast?

Founders who build billion dollar companies get thousands of lucky bounces. Did we want luck to be a necessary component of a successful financial outcome? Remember Charlie Munger, who has gained "long term advantage… by trying to be consistently not stupid"? We didn't want luck to be a necessary component of Next Biz to be successful (click to tweet). Though if the gods smiled down on us every so often we'd be ok with that.

3. Catching lightning in a bottle

Most massive companies timed the market. They provided what became an excellent solution to a latent, unmet need. AirBNB stumbled into becoming VRBO 2.0 just as the sharing economy was taking off. Dropbox built an excellent file syncing product as smartphone and tablet growth exploded. Files needed to be on many devices and Dropbox solved that problem. Palantir exploded because defense spending increased to analyze the terabytes of internet data to combat the rising threat of non-state actors.

Did we want to have success hinge on a rare event of being right at the right moment in history?

4. Your agenda stays aligned with your investors'

VCs need massive exits to generate the necessary returns for their Limited Partners.

Mark Suster has a phenomenal presentation on this. You must read it if you're considering raising money. Slides 24-33 are key:

How VC Actually Works from Mark Suster

Here are the highlights:

  • In Suster's example, assume a 300M fund size where the VCs need to return 1.2B to their investors

  • An $80M exit where the VC owns 20% of the company yields $16M back to the VC's LPs. This $16M makes up 1.33% of the $1.2B that the VCs need to return. In other words, an $80M exit which most entrepreneurs would be proud of is inconsequential to a VC. (click to tweet)

  • A $3B exit (assuming 15% VC ownership) yields $450M to LPs. This is a little over 33% of what the VC needs to return to his investors

Suster says that "Venture is truly only aligned with enormous outcomes." A VC's incentive is to figure out whether you're going to be a $3B company as quickly as possible. And if you're not, it's to spend as little time as possible with you. Is that the agenda you want in a partner and board member?

VC Heidi Roizen describes how investors become misaligned with founders in this "grim fairy tale about a mythical company and its mythical founder".

Here's what she says about alignment:

You are betting usually 10 years of your life and all your available assets on your startup. Your investor is likely investing out of a fund where he or she will have 20-30 other positions. So in the simplest of terms, the outcome matters more to you than it does to them.

If you've never raised VC before, this is a worthwhile read with some great recommendations. Here's what Roizen closes with:

Understand your own motivation… your own goals will dictate whether you should even raise venture at all, how much to raise, and what to spend it on. If you raise $5 million and sell your company for $30 million, it will likely be a life-changing return for you. If you raise $30 million and then sell your company for $30 million, you'll end up [with nothing].

So: were we confident that our agenda would stay aligned with potential investors'? An investor's agenda could change because of many variables that we couldn't control. Answering this question boiled down to how much we wanted to control our own destiny.

Financial Success: where we ended up

Heads I win, tails I don't lose that much.
- Monish Pabrai, author of The Dhando Investor

Another way to figure out the Rich Vs. King question is to ask yourself which of these two scenarios is more appealing to you:

  1. You're diluted down to 1% ownership. You go public. Your name is in the press. You ring the bell on the NASDAQ. Your company is worth $1B, and your stake is worth $10M.

  2. You're a founder of a closely held company. You own 33%. You're only known in your own niche. Your name's not in lights and no press writes about you. Your company is worth $30M. Your stake is worth $10M.

We decided that a business that could reasonably grow to $10M in ARR would be a success. Much more so than a "big swing" business with a bimodal distribution of outcomes. Especially since it's easier to build a $30M company than a $1B company.

Our combined definition of success

After walking through this process, here's how we defined success for ourselves:

  1. The business can conceivably grow to $10M ARR. It's growing at a natural pace and isn't a grow-at-any-cost rocket ship.

  2. We're working with a small number of well-paid, well-treated smart co-workers who work at a steady pace.

  3. We get to enjoy the day-to-day work of making and marketing software.

  4. We're in control of the company, not investors.

This may seem like a no-brainer when laid out like this, however we think it was a worthwhile exercise. It's too easy to end up working on a business whose characteristics you don't like, or working towards an outcome that is ill-defined and perhaps not what you actually want. (click to tweet)

Next Up

Part two is about how we evaluated the many paths we could take to maximize our chances of success. We'll share the framework we used to determine the problem that we chose to solve. We'll also talk about how we arrived at our ideal financing approach. Read part two here.

Codetree has new owners

Exciting news! We've acquired Codetree from Derrick, its founder. We're Arif, Ryan, and Kareem - three devs who have 40+ years of combined experience building software. We've also previously founded four successful SaaS companies. We're going to build on the great work that Derrick started with Codetree. Our goal is to make Codetree an even better tool to help you ship quality software.

Here's a note from Derrick:

Codetree began as a personal side project of mine, with the goal of making the issue management process a bit easier for my team at Drip (and hopefully others, too!) It wasn't long before Codetree became a vital part of my workflow, along with countless loyal Codetree customers. Over the past two years, it has become clear to me that Codetree has a great deal of untapped potential and deserves more attention than I am able to dedicate to it. I am thrilled to be handing Codetree off to a team of experienced, passionate software entrepreneurs who are poised to take Codetree to new heights. It has been an absolute pleasure engaging with customers who share the same passion for refining their developer toolset, and I cannot wait to see where Kareem, Ryan, and Arif take Codetree next.

What’s the Plan for Codetree?

Our first order of business is to do no harm. We're talking to as many current and former customers as possible to understand what they like and don't like about Codetree.

The longer-term roadmap is still emerging, but based on what we've heard so far, here's what we're going to build in the short-term:

  • Drag and drop files uploading for issues
  • Make issues draggable between milestones
  • Improved synchronization performance and robustness
  • UI improvements to make Codetree more enjoyable to use

Learn more about the acquisition

In the upcoming weeks, we'll be writing in more depth about the experience of acquiring Codetree. We'll share why we decided to buy Codetree, specific numbers, our negotiation strategy, our financial models, and a whole lot more.

If you don't want to miss these posts, sign up for the email list here.

Not a Codetree Customer?

Try our free trial if you're looking for a lightweight Project Management tool built on top of GitHub Issues. You'll get the best multi-repo support in the business, dependency tracking, powerful searching and saved queries, a table view and Kanban board, and a lot more.


If you have any questions, please get in touch! You can email us at

Arif, Ryan, and Kareem

Boost your productivity with keyboard shortcuts

You don't have to be a hardcore vim hacker to appreciate the value of a good keyboard shortcut. Now, you can navigate your way around Codetree without lifting your fingers from the keyboard — because who needs a mouse, anyway?

List/board view shortcuts

Shortcut Key Action
n Compose a new issue
q Search
\ Clear all filters
f + l Switch to list view
f + b Switch to task board view
s + o Show open issues only
s + c Show closed issues only
s + a Show open and closed issues
t + i Show issues only
t + p Show pull requests only
t + a Show issues and pull requests
e Expand all issue/pull request references

Issue Modal Shortcuts

Shortcut Key Action
a Show the assignee filter menu
m Show the milestone filter menu
j Show the next issue in the group/column
k Show the previous issue in the group/column

Task boards now available everywhere

I'm thrilled to announce that our "global task board" feature is finally live! This has been a top-requested feature for quite some time.

Prior to releasing this feature, you could only view task boards when filtered by a single milestone or assignee (depending on how you chose to prioritize your project). We originally put this restriction in place to avoid confusion and unexpected behavior when attempting to sort issues inside of columns.

Now, you can toggle between the list and task board view for any collection of issues.

Global task boards

To get around the confusion problem mentioned above, we put a simple restriction in place: if the task board you are viewing is not filtered down by a single milestone (or assignee, depending on how your project is prioritized), then sorting cards within columns is disabled. Everything else, however, will continue to work as expected.

I hope you find this new feature useful!

Custom task board stages have arrived

Task boards are an awesome tool for organizing agile sprints and quickly seeing the status of your project. By popular demand, we've upped our task board game with custom stages!

All projects come preloaded with an In Progress stage that aptly corresponds to the in progress label. Each custom stage corresponds to a GitHub label for maximum flexibility. To customize your workflow for any given project, head to Settings > Workflow.

Custom stages

Once you have configured your custom stages, they will appear between the To Do and Done columns on all your task boards.

Happy hacking!

Page 1 of 2

Next page