Everyone knows bootstrapping means doing more with less--but sometimes bootstrapping means offering less so you can actually do more.

The following is a guest post from Joel Gascoigne, founder and CEO of Buffer, a social media management tool that lets users schedule, automate, and analyze social media updates using browsers, mobile devices, and news reader apps. (Although it didn't start out as quite such a robust tool--as you'll see below.)

Here's Joel on five "essential" things he launched Buffer without:

It's been a long time but I still remember it very well. When I first went about creating the Minimum Viable Product (MVP) for Buffer, there was one thing I kept very clear in my mind.

When I came across Eric Ries and his work on the Lean Startup while working on my previous start-up, I tried to read almost everything he had written and watch every presentation he had given. I found his presentation on the Minimum Viable Product and remember this answer to one of the audience questions:

Most entrepreneurs' instincts for what is the minimum viable product are like 10 times off. So, maybe you're one of those rare entrepreneurs who has that gut instinct for creating an MVP, but just in case, just check out whether it's possible that you could accomplish your strategy and learn something interesting with half the features, and maybe if you want to be really bold with half again, and just imagine: what would that look like for customers?

As a result, when I was putting together the first version of Buffer I kept thinking: How can I go even more minimal? In fact, as we have grown, we have also incorporated this into our culture, often asking ourselves the question, "What can we do right now?"

I'll admit that even with all this knowledge, and even though I kept asking myself, "Do I really need this?" I was still on a sure path to launching with far too many features. Fortunately I had committed to the "November Startup Sprint" concept on Hacker News where a group of people all committed to build and launch something by the end of that November, and I did manage to launch Buffer MVP on November 30, 2010 (with no remaining days in the November Startup Sprint).

All these factors combined helped me to launch a very minimal version of Buffer, gain early validation for the idea, get feedback to guide our direction, and determine how to prioritize which bugs to fix and features add.

Here are the five things we launched Buffer without, even though many entrepreneurs might see them as essential:

1. A paid feature on the pricing page.

This one was interesting. While it might also have been laziness, with my deadline approaching it took some discipline to decide, "I can launch without this feature."

Bit.ly was an advertised feature for the paid plan, yet without launching I had no idea if anyone would pay for Buffer, so it made a lot of sense not to build the feature: I had little validation for it! We landed the first paying customer after three days but they didn't ask me about the bit.ly feature, so I still didn't build it.

When the second customer started paying for Buffer, he emailed to ask about the text box for his bit.ly details that "did nothing" when he filled it out. So, I quickly fixed that and emailed him back to say, "Try it now."

In hindsight this was a great way to validate before building.

2. Automatic upgrade and immediate access to paid plan features after paying.

An auto-upgrade process is one of those things that would be easy to think is essential when you're paying for a product. What an awful experience if customers had to wait until I manually upgraded them, right? However, that is exactly what happened with the first handful of Buffer customers.

I was using PayPal and as you might know, their Instant Payment Notification (IPN) system is not the easiest to code if you want to offer auto-upgrade for paying customers. I had no idea whether it would be three days, three weeks or three years before I had the first paying customer... so why spend time creating a smooth process for people who upgrade? I instead chose to spend time on work that might help me get that first paying customer.

When someone upgraded, I received the standard "someone sent you money" email from PayPal and then rushed to the database to manually upgrade the customer. Sometimes I got there fast enough, sometimes I didn't. Here's an email I received which was typical of the first few paying Buffer customers:

Hi Joel,

I upgraded, but I've still got a free account. How do I get the account to upgrade?

This could be seen as an awful customer experience, one that damaged our brand. The crazy thing is, the result was quite the opposite. This "issue" actually triggered an interaction between me and the users, and made them super loyal. People love to chat with the founder--and it opened up a line of communication between me and the people who count most: our customers.

3. Change email, forgotten password, and delete account buttons.

Perhaps these kinds of features are much easier to build and have in place from day one with the frameworks available now. However, I think these are features that do very little to help you learn and validate whether people have a need for your product.

If they could add any delay at all to your launch, do without them!

4. Editing tweets you've added to your queue to be posted.

In the first MVP of Buffer, if you added a Tweet to your queue you couldn't edit it. If you wanted to edit it, you'd need to delete and add it again.

Tiny typo and want to correct it? Tough luck.

This is one of those features that seems small... but I can assure you they all add up.

I honestly recommend being ruthless about avoiding these kinds of features so that you can ship your product and learn from what happens after you've launched.

5. Static pages, including the About page, terms of use, and privacy policy.

You know when you need to get on with some work and you decide to tidy your room instead?

These are those kinds of tasks you can easily drift into when you're working on your not-yet-launched start-up. It is so tempting to have everything looking nice and tidy for the launch, but these pages are standard and won't help you validate whether anyone will use your product.

Showing that there is a human behind the product can be a benefit, but I advise you add a link to your Twitter profile in the footer instead of building fancy pages.

Remember: The goal is to learn.

That's a key thing to keep in mind, one that is so easy to forget. You can build something pretty or make the code super clean if you want, but that will be just an exercise at this point.

What will help you to validate the idea and see whether you should continue along the same path is to get the product in front of users and talk with them and observe what they do. Do they understand it? If they understand it, is it useful for them?

Stay laser focused on those questions.

One of the key lessons I've learned along my journey is that a lean start-up seems obvious--almost common sense--but it is much harder to do in practice. If you feel yourself drifting off track, repeat after me:

When in doubt, do without.