One of my core beliefs is that a business needs to care about more than just their customers and their people. They need to care for the local environment they work in, and they need to care about people (in their local area if possible) less fortunate than them. It's part of being an ethical business. A healthy business shouldn't be about hoarding money, it should be about doing good with it.

At Travis CI we started a program a last year. Each of our employees gets to choose a charity where we donate an equal amount to. We did the same again this year. While we encourage focusing on local charities (with regard to where each of our team member lives), it's up to everyone to pick their favorites.

And because we think it's important to set a good example, and because anonymous donations are bullshit, below you'll find the breakdown of what we gave to, as a commitment of regularly doing good and hopefully giving even more next year.

As part of our employee program, we gave to the following charities:

Beyond these donations, we wanted to make true on one of our commitments as a company, to help increase diversity in technology and software development. To that end, we donated to the following organizations:

We also supported a few local organizations:

Throughout the year 2014 we also increased our sponsorships of diversity tickets to conferences, giving people an opportunity to attend who otherwise may not have the resources to do so:

In total, that comes down to roughly 22,000 EUR or $27,000 in 2014, or about 1.25% of our total revenue in the same year.

Whither 2015?

We've been doing our donation rally towards the end of the year both in 2014 and 2013, which ends up being a stressful experience. In 2015, we'd like to increase the percentage of our revenue that we give away to charitable causes and to support increasing diversity in software development, supporting open source and more (by way of the Travis Foundation.

We'd also like to increase our support of more local organizations that help more people to get into software development and technology. Send me an email if you have or know of an interesting project!

We're also reconsidering how we're approaching donations, possibly switching from an annual schedule towards making it a quarterly thing, and giving our team members time that they can devote to help in communities or help organizations in need of the most valuable of all goods, our time.

How about you?

Has your company been doing good? Why not lead the charge and tell the world about it? When a company is doing well, that should reflect on their surroundings too.

I've been inspired to share our numbers by Amy Hoy's openness on what they donate. If you're interested in what we donated to in 2013, you can find the list in the comments on her post for 2013.

Tags: smallbiz

Portland I

When we set out to build Travis CI into a product and a business, I had one thing on my agenda that I wanted us to be good at, and that's customer support.

Offering an infrastructure product, we knew upfront that customers are going to have problems setting up their projects, and we knew that there'd be the occasional hard problem to solve.

Customer support turned into our number one priority to get right, and here's how we approached it.

Below are the simple hacks we've learned and applied over the last two years to make sure customers have a good experience when they interact with us. You can apply any and all of these steps instantly to improve your own customer support.

Remember Your Last Bad Support Experience

The simplest thing to help you how to do great customer support is your last bad experience with another company.

We've all had them, responses with blunt links to knowledge bases, canned responses seemingly matching keywords, and a customer support representative who's driven more by the number of calls he's making per hour than by the amount of happiness he's brought a company's customers.

If I'd ask you to sit down and jot down your last five bad experiences with a product and their customer support, the last tweets you fired off into the ether about a bad experience, you'll have a useful list in no time.

All you need to do now is figure out what annoyed you about these responses and incidents and figure out how you'd do it differently, how you would've wanted to be treated.

Great customer support people go out of their way to help a customer, they're the frontline of delivering happiness directly to people beyond simply selling them a good product.

First, Admit You're the Problem

When a customer is frustrated, you can read it in their emails asking for help. Some customers prefer to be snarky, others can say things that aren't very nice. People will say negative things about your product. We may not like it, and we may get easily offended when they do, but that shouldn't impact a positive response.

When your customer is having troubles, you need to think about their pain. When they're frustrated, it's because of your product and your decisions. Always assume that the problem is on your end when a customer is having troubles.

Adopting this approach makes you think twice about your response. It removes a barrier, it frees you from responding with a snarky email or tweet and helps you focus on the problem.

Empathy, Empathy, Empathy

The most important value of interacting with customers, heck, with people, is empathy. Understand that your product is getting in their way rather than solve a problem, and really think about the issue.

It's okay to take a step back, look at all the details you have available and consider the view of the customer.

Empathy means taking the time to understand other people's emotions, their train of thought.

Empathy is the core value of customer support. It's the one thing that makes you great at customer support.

Just coincidentally, empathy also makes you a great customer to work with.

We're all humans, we're all driven by our own goals, and customer support is your one means to align them.

And Honesty Too

If your product can't do something your customer wants, or you can't give them a solution right now, be honest about it.

There's nothing wrong with saying "I don't know", as long as you're willing to take more time to investigate a possible solution.

If you can't find one, it's okay to admit that. We're all humans, and not every problem can be solved. Not every problem should be solved, at least not by your product.

Offer Solutions rather than Excuses

Customers aren't interested in hearing excuses, they're interested in one thing and one thing only, a solution to their problem.

If you can't offer one, that's okay, but a great customer support person goes out of their way to find one, even if it means using another product.

Giving a customer a solution, even if it doesn't involve your product, will make them happier than giving them none, than giving them excuses.

Learn How to Talk to People

You won't turn into a great customer support person overnight, but you can give your brain gentle nudges on how to talk to people better.

For me, reading a few books has helped a lot in shaping my languages. Two in particular have been invaluable, and I'd recommend them to anyone. They're useful not just for customer support interactions, but for all kinds of people interactions.

"How To Win Friends and Influence People" is a timeless classic, and it taught me a lot about empathy and how to approach people in general and disgruntled customers in particular. It's the one book you should read no matter what you do. It shaped my interactions a lot.

"Drop the Pink Elephant" is the perfect companion. It teaches you about saying what you really mean rather than focus on things that remove clarity from a conversation. It's shaped customer interactions and the way we write our public postmortems.

Customer support is your number one differentiator as a company. It takes a lot of work and effort, but it's your best way to make your customers happy, to have meaningful interactions with them.

It pays in the long term to make sure you're doing it right. Great customer support experiences can't be measured in money or in any meaningful way, but it'll help you get loyal customers. Knowing that you're willing to help no matter the problem gives every customer the incentive to come back for more.

But most importantly, great customer support makes your customers feel like they're treated as humans.

Tags: smallbiz

For the first 15 months of Travis CI's existence as a paid product, customer support went a little like this:

  • New email from customer.
  • Open a console on Heroku to fetch the relevant data.
  • Respond to email.
  • Repeat upon next email.

We didn't have any support tools, if you can imagine that. Nothing that gave us quick access to the data we needed to look into and solve a customer's issue.

But you know what?

It was okay. It was okay to fake it until we had the time to sit down and make it.

We could've spent the time building these tools much earlier on, no doubt. But with an unproven product it was hard to justify the time when we weren't fully sure yet if our product would help us build a sustainable business.

Instead we chose to spend the time improving our product to the point where we had enough happy customers that we could pay the bills and had a good feeling that the business would work out.

Of course we also pushed back on working on these tools over time for other reasons, but eventually, we sat down and invested the time to build better support tools.

In the end, that time was well worth it, as better support tools that everyone could use meant that less technical people could jump in on support and learn more about our customers' problems and how Travis CI works.

In the end, the effort benefited everyone. But initially, there was a trade-off between spending time on product to prove its viability vs. spending time on tooling around a product you're not certain yet whether it'll take off.

Tags: smallbiz

Once you've figured out what kind of product you want to create, the biggest hurdle to get it in front of customers is finding the right price.

How much you should charge for something can be a paralyzing question, keeping you from either shipping or making you offer your product for free longer than is healthy. Remember, you should charge even for a beta product.

It took us months to settle on a price for Travis CI, and it was a grueling process at times. We didn't know what to base our price on, and we didn't know what to charge.

Here's what helped us figure out what to price.

Narrow down your target audience

Ideally, this has happened before you even start thinking about the price. Finding an audience for your products is an important step, and it requires research. We like getting lost in what Amy Hoy calls the idea quicksand, without making sure something is ready to pay for what we're trying to build.

In the widest sense, Travis CI's target audience are developers. We narrowed it down further by focusing on people using GitHub as well.

While our open source platform is free for everyone, our product had a slightly different focus. We narrowed it down further to businesses.

That allowed setting a higher price than if we were to focus on serving all kinds of developers.

Don't get me wrong, we'd love to do that eventually, but narrowing down our initial product audience allowed us to validate the product quickly and ramp up revenue to a point where we can focus on possibly starting to sell the product to individuals as well.

Ignore your instincts, focus on value instead

Your gut will tell you silly things like asking yourself "How much would I pay for this?" or "No one will pay X amount for this." or "Lower price equals more customers, right?"

Those things are really silly, and your gut is a liar.

Products, especially the ones targeting businesses, focus on either reducing a pain or burden, or at giving a customer better means to make more money with their business.

That in turn means your product has a value to these businesses. While you may never be able to fully evaluate how much exactly your product saves your customers, you can get an idea when you're familiar with their business. This requires research as well, so it helps choosing an audience you're already familiar with. It's the one reason why I like focussing on building tools for developers.

Developer tools speed up parts of a team's workflow by removing either an operational overhead or by automating something that the team would otherwise spend tedious amounts of time on.

That time can be put into numbers, even just with rough calculations.

Values goes further than just thinking about these numbers, but they give you an idea on where to put your price.

If your product frees up 10 hours every month that a team can spend on their core business, you have an idea of what you can charge given a normal price for a developer hour.

If your product allows someone to learn a new technology quicker than having to scrape together a bunch of resources, tutorials and articles from the interweb, you probably saved that person some time with your product.

That's where you can start getting to a better price than what your gut is telling you. Focussing on value gives you another benefit, you can drive your marketing based on what your product does for your customers rather than just its features.

Charge more than you're comfortable with

Amy Hoy put it very succinctly. Once you've narrowed in on a price, double it.

Back when I launched the Riak Handbook I originally had much grander ideas in my head. I set out to write the NoSQL Handbook, a hands-on guide covering five different NoSQL databases.

My initial price ideas were to charge $12 for the final product and $9 during the beta.

If you ask me now, I have no idea what I was thinking. My mind was anchored by what publishers charge for their books, and by what some fellow self-publishers charge for theirs.

I eventually decided to cut a smaller book from the bigger version to have something to ship. I decided to publish the Riak Handbook, clocking in at 120 pages of content focussed on practical Riak usage. The NoSQL Handbook would follow later.

Rather than charge $12 for the Riak Handbook, I doubled the price to $24. Later, I figured that $29 is a much more appealing number. The book sold 1500 copies so far, making much more money overall than if I'd have sold it for $12.

Hold on, you say. Surely, cutting the price in half would get more people to buy it, yes?

To make the same revenue the book made with a price of $29, it would've needed to sell more than 3600 copies, close to 150% more.

Charging less doesn't mean you'll get more customers, it just means that your profit margins per customer are much smaller.

For Travis CI, we applied similar thinking, and we spent time calculating margins. We even got advice from someone who wanted to invest in us to not charge less than $99 per month.

We settled on that number, but eventually raised it even further.

The beauty about charging more now is that you can always charge less later (though you should really charge more). You can always introduce versions of products for people who want to pay less by reducing the scope of features.

Charging more than we're comfortable with is frightening, we fear someone saying no to the price.

But what really matters is not the people saying no, it's the people who say yes, the people who are willing to pay what you ask for.

Fewer customers at a higher price means getting to sustainable revenue levels faster.

Read, read, read

Pricing is a broad topic, and I've only scratched the surface. Things get much more interesting when you get into the realms of anchoring, using free as a means to sell, upsells, cross-sells, and all that jazz.

A few books helped me greatly to figure out pricing, or at least to get better at it, and I wholeheartedly recommend you read them too:

If you're interested in learning how to find audiences, building, marketing and pricing products, I highly recommend Amy Hoy's 30x500 class.

Tags: smallbiz

We love grand ideas. As engineers in particular, we like the idea of building something big that solves an idea we've had. We love sweating the details, we love refining architecture, we love building the right tools for the job.

When you start a business, this approach can foil your grand idea before you even hit a market. This ignores that ideas alone are worth nothing without a market for them.

What if, instead of working on your grand idea right away, you start working on something small?

When you've found a market you don't instantly need to build a big product to serve it, you can start much smaller than that. Starting small has the benefit that you can gauge out the market and its interests and that you keep risk lower than with building something big right away. Products are shrouded in uncertainty, keeping the risk low means keeping your losses low, which is rather beneficial when you're bootstrapping.

Building something small initially and slowly increasing the scope of what you build has another benefit. Your initial products start feeding into the work for the subsequent products. The money made from your first products helps you to build more products.

Smaller Products can beget more, slightly bigger products. I love this idea, also called "stacking bricks."

The Riak Handbook turned out to be such a product for me. Working on it took the better of three months, a big part of that spent full time on writing, editing, creating the publishing workflow (I wouldn't recommend building the publishing chain yourself), and the marketing site.

While the book's most sales happened in the first days of going public, it continued to sell for now more than two years, both on the site and on the Kindle store.

It helped a lot in getting Travis CI off the ground as a product. It wasn't a lot of money that came in, but for the following twelve months after publishing the book, it brough in up to $1000 per month extra. Quite handy as passive income when you're working on bootstrapping another product.

How can you build something small before building something bigger? Here are a few ideas.

Build an audience with writing

The Riak Handbook started out by way of this very site, if you will. Early on in the craze of NoSQL databases, I started writing about the fun and silliness I had playing with some of them.

That in turn led to the idea of the NoSQL Handbook, which, after more thought, distilled into the Riak Handbook.

I unknowingly built up interest for the technology, just by sharing what I discovered playing with them. The joys of new technologies.

Sell what you learn (and what you know)

A book or even a series of screencasts is a great means to start stacking the bricks. It's a nice next step from building up an audience, and it doesn't even require you to be an expert at something right away.

Rather than dump your entire knowledge into a book, write about what you learn, or learn as you write.

Here's a little secret: the Riak Handbook was my personal Riak learning experience.

Sure, I've had exposure with it before, working for Basho and with their customers, but my deepest exposure with all facets of Riak was writing the book.

It turned out to be a great learning experience for distributed systems and for Riak itself, even picked up some Erlang along the way.

Sell something that doesn't yet exist

Here's a crazy idea, before you actually build something, sell it. Put up a landing page for your product, start marketing it, see if someone bites.

If they do, you have all the more incentive to actually build it.

I'm a big fan of grand ideas myself. But the Riak Handbook, as small as it is, was a convincing exercise that it pays to start small. It pays off slowly, and revenue will start trickling in, but as you add more products, you add more revenue.

Heck, if you enjoy writing and selling books, keep doing it. Build more, sell more of them.

For some more inspiration on starting small and building your way up, I'd highly recommend these books:

Tags: smallbiz

I used to have this beautiful dream that I'd some day open my own coffee shop.

It sounds simple enough. All you need is an espresso machine and you're good to go.

Except you need to rent a shop, buy a giant grinder, or two, buy coffee beans, hire a barista or two, buy cups, take away paper cups, a water filter, and buy a freakishly expensive espresso machine.

Add some interior for the shop, and you're easily in the several tens of thousands to start your business.

Compare that to what you need to start selling products on the internet. You need to spend some time to find an audience, to find your market, and then, all you need is a laptop and an internet connection.

I have to keep reminding myself how little you need to start a business and to actually run it.

Beyond your computer, you don't even have to buy anything. You can rent (even pay by the hour) anything you need to serve your application, and you can utilize other services and products to help build yours. Heck, you can build on a ton of open source tools and libraries as well to help you get the job done.

You don't even need an office. All it takes is a itch you want to scratch. Whether you want to build and sell a product, build a business around it, or you just want to open source something.

I love that about what I do, and it's hard to understate how lucky and privileged we are being able to take something off the ground like that and to tell other people about it.

All it takes is a laptop.

What's keeping you?

Tags: smallbiz

When we set out to build our first product (Scalarium, now better known as Amazon OpsWorks, we started off with a rookie mistake.

Initially, we played with some ideas to test if we can fit them together. This was mostly focussing on orchestration of servers and their provisioning. We tried out a mix of RabbitMQ, Nanite and Chef (early adopters, yay!)

Back then, NoSQL databases just started appearing, and we thought, screw MySQL, we're going to use something new and shiny. We started out using Amazon's SimpleDB, but were soon hindered by its limitations.

We built Scalarium on Rails, so it was only natural that we started writing our own ActiveRecord-like persistence layer. First, we wrote it to work with SimpleDB, and it was aptly called SimplyStored.

Later, after some first exposure to CouchDB, we decided to use it instead. It was gaining some traction, and we had good access to local community support.

After we hit a wall with our first attempt at using a custom storage layer, we rewrote it to support CouchDB. Slightly different semantics made some things harder to rewrite, and some things were quite awkward to handle, in particular when trying to map an ActiveRecord-like query model on top of a database that requires you to define your data queries upfront and store them as JavaScript or Erlang views.

We spent a lot of time on SimplyStored, and for no good reason other than the technical fascination with the idea of not using MySQL, a proven and fast database, which would've been very sufficient for our purposes.

In the end, we still managed to build a good product, but shipping it was extended unnecessary amounts of time by trying to start building our own stack rather than use what's there and what's proven.

It's tempting to use new technologies when you're building something new. After all, you've got a clean slate and can just play around.

But when you build a new product as a new company, getting something up and running, something to throw at users, is even more important.

It's okay to build up some technical debt along the way. Yes, you will spend time later cleaning it up, but at least you can do that knowing that what you've built initially was successful enough.

With a proven product that's bringing in revenue, you have more freedom to gradually remove the technical debt built up in the beginning. Of course you'll be adding new debt along the way, but that's just the circle of software engineering life, isn't it?

At Travis CI, we also made some mistakes of where we focused our attention while building a product. Some things were more focused on building something that's technically sound rather than make sure we get a working product in front of customers quickly.

Early on, Travis CI started out as a test balloon if you will, with a few simple components to prove its technical viability as a continuous integration system. Leaving some challenges aside, we were able to scale it out quite nicely. We're still working on removing the technical debt that we built up, but given that our customer base allows us to do so, that's just fine.

With Scalarium, it took us almost a year to get something in front of customers, an insanely long time. Looking back, the thing I would've done differently is not building our own persistence layer, which has no relation at all to what we were trying to build. It just took away precious time from building our first version that could be used by customers.

When building something new, be careful to not fall into the trap of shiny new technologies. They can be blessing and a burden, but the latter is all the more likely when you step into the unknown.

Using proven technology can be incredibly boring, but they give you the room to make sure that what you're trying to build and sell is sound as a product, rather than a technical masterpiece.

When building something new, simple and proven technology wins. You can always add more bells and whistles later.

With our own company growing, both in terms of our team size and our customer base, I keep finding myself thinking more about what kind of company we want it to be.

This touches on all aspects of the business, relationships with our customers, marketing our product, how we treat our community, both globally and locally, and most importantly, treating and growing our team.

What it boils down to for me is openness on the one hand and fairness on the other. Everywhere a company is active, there are always humans involved. Any issues that come up are best served by being brought out in the open, treated with empathy, the will to solve the problem, and the assumption that people are generall well-intentioned in what they do.

This goes into all directions, because at the very core, empathy is the most fundamental skill, both for the humans working in a company, and for the company itself.

Empathy is sometimes described as a personal trait, but it's a skill, a skill that can be learned, that can be honed, and that can be instilled as a core value of a company.

Empathy means taking your customers' issues seriously, acknowledging their problems, helping them fix any issues they might have, no matter if the issue is on their end or on yours.

Customer loyalty isn't something you can buy, it isn't something you can put a number on. Customer loyalty is something you have to work on every single day.

Empathy means building relationships with your customers rather than look at them as transactions. When they have issues, you have issues, it's simple as that.

It also means that when there's a bigger issue at stake that affects your company and your customers, it's tackled out in the open, head on, rather than swept under the proverbial rug. This includes security issues, operational/production issues, but also issues that affect your company in other ways.

We like to think that a company's brand and image can be controlled. The more we repeat our values, what we stand for, the more our customers will believe it.

That's bollocks. You can spend years trying to make yourself look pretty on the outside, but that facade can be destroyed by that one small thing that you didn't want to make public at the time.

Empathy means being open and honest about anything that affects your company. Does that mean you have to tell the world exactly how much money you're making or losing?

In what detail you make what you do public is up to you. We tend to fear that publishing too much could play into the hands of our competitors, that it could confuse customers, despite there being next to no proof this is actually the case.

I admire Buffer's openness in this regard. They're publishing their team's salaries, the letters they send to their investors, numbers about growth and losses. Can that hurt your company in any way? No one knows, because it just hasn't been done before.

Empathy means that your company is aware of its surroundings. Even in times of companies selling things to a global audience, with a distributed team, companies have a home, where they pay taxes, and a community they're inadvertently a part of.

An ethical business is about giving back to the community it's working in. I found inspiration on this in "The Knack", where the employees can get involved in community work on the company's time, and they get to choose a good cause to give something to at the end of the year.

Amy Hoy is doing something similar, part of their profits go to local charities. I found this very inspirational, and we started doing the same with part of our profits last year.

Beyond that, there's community work, helping kids and schools in need, lots of opportunities to jump in and help out in a company's local surroundings.

Empathy means treating your vendors with the same courtesy as you treat your customers. The same applies to them, you want to build relationships rather than think of vendors as a transactional means for your business.

Vendors are people, just like your customers, the people in your community, the people working in your company.

The people on your team are the most important for any company. Some would argue differently, but I'd say that for an ethical business, how you treat the people working for you is what shapes any interaction your business has with its surroundings, with its customers.

There's a quote in "Small Giants" that stuck with me:

For all the extraordinary service and enlightened hospitality that the small giants offer, what really sets them apart is their belief that the customer comes second.

On first sight, it sounds harsh. Clearly, a business' customers are the most important for its continuing success, no?

It takes a happy and driven team to make for happy customers. Relationships can only be made between humans. While customers can use your software or product, or whatever it is you're selling, whenever they have issues, they expect a human to help them out.

Building healthy relationships between your company and your customers requires all people in the company to have healthy relationships with each other, with the people they work with, the people they work for.

Just like with your customers, you can't buy your team's loyalty. It requires you to build relationships with them. Relationships are based on trust.

I'd argue that you can only earn trust by putting your trust in someone in return. Allowing people to do the right thing, yet still give them room to fail and learn, is the simplest beginning to build trust.

When it comes to the people you work with, trust is reflected on different levels, not just work, but also how your company treats their personal lives.

Trust, in turn, comes down to empathy.

Empathy is the recurring theme in this post, it's the recurring theme in any human interaction. Empathy means you take your time to appreciate, to contemplate what another person is thinking, what they're saying.

Whether it's your customers or one of the people you work with. Listening to their concerns and treating them as if they're yours is the start of building trust. If people learn that you can listen to them, without judgment, and help them figure something out, you're off to a good start.

As Chad Fowler said, empathy is your most important skill.

This is something I'm trying to work on every day, work against my instincts, listen to people first, ask questions, before I pass in my own view of judgment. It's hard work.

For an ethical business, a lot of things come down to "doing the right thing."

The right thing in the global, local or your company's micro scope can have lots of different meanings, and figuring those out will be the hardest. We've spent a lot of time working that out for our little business, and we're still at the very beginning.

Does an ethical company strive for profits? Of course, the question is how they're used. A company needs cash to survive in the long run, but it also needs to take care of its surroundings to function well.

What makes an ethical company then? I believe the core values lie in openness, honesty and, most importantly, empathy. Those are skills that need to be acquired, practiced and honed. We're only at the beginning of this journey for ourselves, and we're working hard to stick to these values.

Tags: smallbiz

There's a prevailing idea when it comes to startups and building and running your own business.

The idea that to be successful, you need to work hard, put in long hours, and push your team to the limit as well.

Keeping up with the competition, trying to make your customers happy, your investors too, and trying everything you can to turn your business venture into a success, however that is defined.

Some companies even go as far as advertising it as normal that you can just take your work everywhere you go, to the park, to your kids' soccer game, maybe even to the pub?

I've fallen into this trap, I've been putting in 10-12 hours per day, working from home, with my family around. The family is understanding, but that doesn't justify these kinds of working hours.

As someone working on a product that's used around the globe and at every hour of the day, I can relate to this idea. When production is broken, it's handy to have something around to respond. When a customer is having troubles, I want to help them. I'm used to taking my computer with me, even during the weekends.

Adding to that, with customers only coming online when it's the end of the business day in Europe, our support usually ramps up in the later hours, where customers come into our live chat and expect someone to help them with their problem.

Helping customers succeed is one of the most important purposes of a business, and we're trying as best as we can to help them out.

But that thought drove me into a habit that's hard to break free from. It's the fear that there could be a new customer support issue every day, that there could be a new customer in the live chat that needs help.

This very habit has driven me to being on the computer from the morning to the evening hours, always waiting for someone to approach us with an issue.

It's a habit that's been having a very destructive effect on my work and my life, and the two are not the same.

A few weeks back, as our team grew more and more, I've come to the realization that working longer hours gives a bad example, not just for myself, but it sets an implicit expectation that others on the team work just as long. It's poison for a team for even one person, in particular a manager, to work longer hours. It gives the impression that it's normal and expected to work longer than what your contract says.

It wears people out, it's worn me out, on multiple occasions.

We recently started doing support rotation, where everyone gets a dedicated day of doing customer support, escalating to others on the team where necessary. That gives the support person the freedom to only focus on customers for the entire day, and it gives the rest of the team the ability to focus on getting other work done.

It's been effective for us, and it's already improved our own tooling, our user interface and our documentation.

But I still can't shake the habit of always wanting to help. You can say that it's a noble habit to have, but its downsides are starting to show.

There's a quote from Small Giants that stuck with me:

For all the extraordinary service and enlightened hospitality that the small giants offer, what really sets them apart is their belief that the customer comes second.

A company's team is what sets it apart. That team needs to be well rested to make for happy customer.

The only way to get them to do that is to discourage long working hours.

In our company, that starts with me.

Success doesn't depend on how much you work, it depends on where you focus your time in the best way possible.

Don't work too hard.

Tags: work, smallbiz

There's a curious assumption out there, and it's time to put that assumption to rest for good.

It's the assumption that things should be free while they're in beta.

That assumption is made on both ends, your customers think it should be free, and you think your product should be free too.

It's bollocks. You're hurting your business by following down this path, and, while they have good intentions, so are your customers.

Free customers don't validate a business, they don't validate a product. Only when customers are willing to open their wallet for your product will you start to have validation that you might be on to something.

Offering a product for free while it's in beta implies the assumption that the product doesn't provide any value while it's in beta. If your product doesn't provide any value while it's in beta, stop what you're working on right now.

You think your product doesn't provide any value while it's in beta, and neither do your customers. At least that's how the assumption goes.

Are you sure that you've verified that there's a market, an audience, for your product that needs this problem solved? Is there more research you can do? Could you talk to one of the folks trying out your product?

If you can be sure that your product provides value, and this is why serving businesses is a much better idea than serving consumers, why are you not charging for it?

Does the label beta keep you from charging money? Remove it.

The sooner you start charging, the sooner two things will happen:

  • You know that your product has value to the customers that are willing to pay you for it.
  • Your business has a much higher likelihood of succeeding. Early validation gives you confidence that it's worth continuing with the product.

When we started out with our product version of Travis CI, we took a few months to develop what we considered to be the minimum features we could ship and throw at potential customers.

We launched our initial private beta in July 2012. We started charging in September 2012. But, and this is where we could've done better, we didn't enforce charging. If people didn't want to sign up, they could continue using the product for free.

Meanwhile, we manually emailed dozens of customers, asking them to sign up for a subscription and for feedback at the same time. This was a long process, and I wish we'd have automated sooner.

But it gave us a chance to see what people liked, what they didn't like. At the end of the manual process we had 100 paying customers. More than enough to validate that we were on to something.

A beta product doesn't make a product, let alone a business, yet.

But when you start charging early, and you find customers paying for it, you have a tiny validation that it's valuable to some. That can be a much more powerful realization and boost than trying to crank out new features to make free users happy.

The best way to validate a product is to get a customer to pay for it, then 10 customers, 100 customers.

Tags: smallbiz

This is the essay version of a talk I gave at Jimdo.

Out of Business

Travis CI started out as a small platform for Ruby projects to run their tests on. Back in 2010 and 2011, there was a distinct lack of hosted continuous integration platforms.

It was launched close to the day, three years ago, with a small announcement.

Some Ruby projects quickly adopted it, Rails started officially moving their tests to Travis CI.

Later, in 2011, more language communities discovered the platform. We added official support for PHP, for languages running on the JVM, for Erlang and for Python.

We now also support Perl, Haskell, and anything you'd possibly want to run on a Linux platform. Plus, you can build projects on OS X and for iOS.

Unfinished Business

Initially, Travis CI only supported open source projects. But people and companies kept asking us to use our platform for their private projects as well.

The idea was floated to found a company and turn this into a business, work on Travis CI full time and get paid to do it.

By the end of 2011, a company was founded, and two more people joined the team. We were five people trying to build a business, four of them developers.

In early 2012, we started a crowd-funding campaign to bootstrap our business and allow some folks on the team to be paid for by the company. It allowed us to keep the open source platform running and to improve our feature set.

One of the features coming out of that was pull request testing, which initially was done by having a bot comment on pull requests, annoying the heck out of some people.

We Mean Business

We started working on our product, and we tried to figure out the hardest part about a product, the pricing.

We started thinking about revenue, all the crazy things you have to do when building and running a business.

We launched our product into private beta in July 2012 and started charging in September 2012.

It was all rather hack-ish, and we didn't yet force everyone to sign up for a paid subscription. All the work involved in getting people to sign up was manual. We picked out a few customers and emailed them, encouraging them to sign up and to give us feedback.

Back in Business

This worked surprisingly well and by the end of 2012, we had more than 100 paying customers, allowing us to pay two on our team some sort of wage. Plus, we could pay for our infrastructure.

While that didn't imply a raging success, the signs looked right.

Whilst trying to build up our business, we had to solve scaling puzzles already on our open source platform. This was both blessing and curse.

We were running 7000 builds per day in 2012, compared to 700 in 2011.

In comparison, by the end of 2013, we were running a total of 65000 builds per day.

Solving these issues upfront on the open source would mean we'd know how to solve them when they'd come up on our commercial platform. On the downside, we'd been distracted by these things, rather than being able to focus on the business.

We were able to break Travis CI early on and see the potential affects of any fixes before they'd become critical to our business.

As a challenge to ourselves, there's one special ticket that was opened in early 2013. When our business was in a stable state, we'll be shaving off Sven's mustache.

Business Never Personal

For developers, though, business is tough. Figuring out how much to charge, how to approach customers, how to do customer support (and to understand how important it is), is something entirely new for most.

It posed a big challenge for us, and it took a while to get everyone behind the idea that customer support is essential to our business. When it comes to code, every customers' project is a unique snowflake.

Every project has its own interesting dependencies that can break in the most curious ways. Complex test suites pose challenges for our platform and for our infrastructure.

Solving these can be a tough challenge, but talking to customers about them upfront is what makes them less painful to them.

We spent some time thinking about how we can make Travis CI, how we can surprise our customers. A friend floated the idea of using coffee as an inspiration.

Initially, we wanted to send thank you notes. But we wanted to add an extra twist. A friend suggested we could send out bags of coffees to our customers, combining our passions, and doing something completely unexpected for our customers.

So far, we only shipped some 300 bags, as we had to take a break to tackle some issues, but we intend to pick this idea up again.

Strictly Business

Rather than do strictly business, we wanted to run an open company.

When we have problems that affect our customers and users, we try to be as open as possible about them. They're annoying, but when explained, people do understand that scaling issues can pose unforeseen challenges that aren't easy to solve.

Open operations an unintended marketing channel, if you will. Based on the openness, people can decide whether they want to buy into the fact that we do have outages, that we do have issues, or not.

Marketing is an interesting topic, as we technically didn't do any. None that is directly measurable or where customer growth can be attributed to. Whether that's a good thing or not, I don't know.

The one business-changing thing we did in 2013 was to finally put up a landing page for our product and to actively let people try out our platform and allow them to pay for it.

That's our secret to strictly business.

If you don't give people the opportunity to try out and pay for your product, how and why would they?

Business as Usual

When we finally solved our bigger technical challenges to scale out the platform, we were faced with new challenges: people.

Something every company experiences at some point in its lifetime is to hire people.

We started hiring a few more people in 2013, people working remotely from the start.

We wanted them to feel like they're a part of the team, like their happiness is what's most important to us.

This is a tough challenge, and we have yet to figure it out. I'd say we're doing pretty okay, but there's always room for improvement.

One thing we're trying out currently is support rotation, with everyone on the team involved, no matter their status. The more everyone on the team knows about the product, the more eyes we have on ideas to improve it. The more everyone is exposed to customer issues, the higher the incentive to fix them.

We give people on our team the freedom to do whatever they like, whenever they like. A happy team with a focus on customer value leads to happy customers and a healthy business.

That's our ideal.

At the beginning of 2014, we have 700 paying customers. That may not sound like a lot, but it's close to infinity when you're starting a business from scratch.

We're running a bootstrapped business, we've turned down VC funding multiple times, and proudly so.

Open source is still at the core of our business and our team.

We believe in the power of building good products with people who are passionate about them.

Also, there was this:

Things that have been on my mind lately:

  • Implement lifecycle emails for our product to get new customers more to work with, using

  • How do I best write the copy for these emails?

  • How can I increase customer retention?

  • How can I reduce customer churn?

  • How to get everyone on the team doing customer support?

  • How can we actively approach customers to get more insight into their problems?

  • What kind of better and more insightful content can I produce for this and our company blog?

  • What blogs can I run guest posts on?

  • How can I funnel more visitors from our blog to our product?

  • How can I make sure that everyone on our team is happy?

  • How can I adopt selling bacon as part of our business model?

These are only a few things that keep my brain busy.

So many things in my head, so little time to do all of them.

Life running a small business is never boring.

I'm a newbie, every single day.

Tags: smallbiz

For a startup or a small biz in its infancy, every opportunity looks like a pot of gold.

Every opportunity that comes across looks like something you can turn into monetary value or use it to grow your product. It's really hard to say no to any of them.

It's your customer suggesting a new feature, it's a company that would like to do a partnership with you, it's a bunch of VCs that are courting you to give you a nice sum of money in return for some shares of your company.

Clearly, this new feature must be relevant to other customers and will allow you to get even more customers because you can advertise it. There are tons of reasons why you'd say yes to a new feature.

The partnership must be good for your business because it'll drive more traffic, it'll get you more customers, and two businesses benefit from it.

The VCs must be loving you, why else would they be courting you? Their offer is generous, and their demands sound reasonable. It's hard to say no, in particular because they tend to keep coming back when you do.

Saying no to any of the above seems like such a harsh thing to do.

You're afraid to lose a customer because you're saying no to them.

You're afraid to miss out on a deal that could help grow your business.

You're afraid of closing the door on future funding, even though you neither want nor need it. The offers are tempting, and VCs are full of nice words for your product.

How can you say no to any of them? How can you say no to a shiny pot of gold? Your gut says it's okay to say yes.

Science has an answer.

If you're a man, it turns out you'll be a lot more likely to take on risk because they may have strategic value. Getting more customers, making customers happy, and growing your product and company sounds pretty great as strategies.

As a woman, you're more likely to consider the empathic side of taking a risk (which all of the above involve). You're more likely to consider the effect a decision has on the people involved.

Note that these differences tend to be more noteable when you're under stress, a common state in early startups and small businesses. Doug Sundheim has a good summary on this topic.

Every decision you're making has a strategic effect, but it also affects people. It affects your employees, your co-founders, your spouse, your entire company.

In "Small Giants", a book on companies that chose to be great instead of big, there were a few examples of this, on both extremes.

One company held off their IPO because it'd mean that suddenly they'd have to answer to shareholders. Another made their decisions amongst a triad of three CEOs that would take days to consider the possible outcomes and effects of a major decision.

Or take Norm Brodsky, who, in the 80s, grew an empire of a bike courier business to big proportions, buying other messenger companies along the way. The last company he bought had much worse numbers than he was originally made aware of. He had to sacrifice his own money, he had to sacrifice his company's war chest to try and make it work.

In the end, he sacrificed his own company, as it filed for Chapter 11.

Norm wrote a great book called "The Knack", full of great advice and stories on how he's running a business, and on how he ran one of his companies into bankruptcy.

When it comes to a business, it's easy to say yes to say something without taking the time to consider the possible outcomes, putting aside the fact that you can't know all of them. There's usually a pressure to do so. VCs want to invest in you, customers want to see this feature they suggested, partnerships need to be signed off yesterday.

There's another side to the coin when you can't say no. You're wasting precious time dwelling on things that in the end may not be relevant to you. Time and attention is your most precious asset, protect it well.

You can start by saying no to things that distract you. It's okay to not listen to your gut for once and to stop letting outside pressures influence your decisions.

Use the little trick that Norm Brodsky started using after he realized that he's been taking more risk than he can chew: take a shower and think things through.

Learning to say no might be your biggest asset in finding focus for your product. Start saying it sooner rather than later.

Tags: smallbiz

For more than a year I've worked (with an awesome team) on taking Travis CI from an continuous integration platform for open source projects into a small business with a profitable product.

While this hasn't been my first venture, it has so far been the one where I focused more on the business side of things than anything else. There was some code, there was infrastructure, there was monitoring.

But the important bits aren't about any of these three. They're about a ton of other things, some of them being a big surprise for developers in particular. They deserve to be talked about, good and bad.

Running a small business is...

All About the Customer

The only thing that matters for a small business (for any business, really) is a happy customer. It helps to be happy yourself, but in the end, it's happy customers who pay the bills, and who continue to pay the bills as long as you can keep them happy.

There are a ton of ways to achieve this, and most importantly, you should have a product that they need, that they're willing to pay for.

Whatever you do during your every day, it needs to have the customer in mind. Which means one thing: you need to talk to your customers.

Even in the age of running businesses online, your biggest and greatest asset is still to be in personal touch with your customers. You need to pull your head away from code, and you need to spend time either visiting them, talking to them on Skype or at least sending them emails.

There are means to automate this, in particular emails over the lifecycle and on-boarding of a customer, but I can promise you that putting in this effort yourself is worth it. If you automate it, for instance by utilizing a platform like, make sure that a reply reaches a human (hey, that's you!)

The great part about talking to customers is that it's the best way to find out what they want, what they'd like to see improved in your product.

Most importantly, it's the only way you'll hear them say how much they love your product. Time spent with your customers is time well spent.

Not About Code

When all you do is interact with the customer, when will you finally get to write all that precious code?

The simple truth is, and this depends on the size of your initial team, writing code is not what makes you money. It sure helps to build a great product, but if you don't put in the time to market and sell it, to hold your customers' hands when they need you the most, no one will buy it.

The fact that you need to pull yourself away from code is one of the harsh realities of running a business, in particular if you're a developer by trade.

But it's the part that constantly pushes you out of your comfort zone. It forces you to talk to people, it encourages you to continuously improve your sales and marketing materials, to write blog posts regularly, to interact with your customers.

Best example is finding your price. You have to move out of your comfort zone from two perspectives. You need to put a value on your own product, and you need to find ways of showing that value to your (potential) customers, in particular when they come to you to heckle on price.

It's worth repeating: Running a small business is about anything but writing code.

It took me a long time to accept this, so it's okay to take your time, but the sooner you come around to the idea, the earlier you can work towards a thriving business.


The dangerous part of running a business is that it's to easy to be excessive about every aspect of it, be it customer support, customer metrics, customer happiness, new features, marketing, blog posts, your product's availability.

It's easy to give in and not let go other than when you go to sleep. Just one more customer support email, just one more tweak on your landing page, just one more code change before you finally drag yourself away from the computer to have dinner.

From the last year's worth of running Travis CI as a business, this has been a dangerous trap for me, for all of us. It's too easy to just put in a few more hours at night instead of doing something entirely different, like reading or spending time with your spouse or your family.

It's too easy to get sucked in to working more on the weekend, neglecting your friends along the way.

This is a dangerous road, and it took me an unfortunately long amount of time to realize it. In hindsight I'm glad that I at least made sure I can spend quality time with my daughter.

Take care of yourself, of your family and of your friends. They're very supportive in what you're doing, so don't neglect them in return.

It's a noble cause to try and provide the best and fastest customer support you possibly can. But sometimes, and this may sound very heretic given all of the above, sometimes it's okay to let the customer wait until tomorrow.

Now go out, stare at clouds, have a drink or dinner with your friends or your family. Personally, I get the best ideas and fresh insight when I'm not in front of your computer, when I'm in the shower, or when I'm spending time with my daughter.


As soon as the first customer hits the "pay" button, everything is starting to pay off. As soon as you get 10 or 20 more customers to pay for using your product, you will be the happiest person in the world.

There's room for a comparison to having kids, but that may be a bit of a stretch. Though sometimes, running your own business and selling a product successfully feels just like that.

Allan Branch compared the relationship to his co-founder to being married, so in that view, your product is your child, a labor of true love.

There are times when it's exhausting, when you struggle to find new customers, when you struggle to fix annoying bugs, when you struggle with customer support. But those times are offset by knowing that people are happily using something you've built, and they're even paying you money for it.

It's exhilarating.

Now keep going, make your product even better, get more customers, write another blog post.

Tags: smallbiz