It’s hard to argue against instituting a policy of reviewing each line of code your team produces. Yet actually putting such a policy into place is difficult — some coders will even fight back against the mere concept of code review. But Best Kept Secrets of Peer Code Review opens with an indisputable example where a code review policy would have saved the writers’ company $150,000.

This ebook covers the mechanics of making code review a necessary step of your development process, from getting buy in to the process to measuring and improving your code review process. It’s actually a white paper, so the goal of Best Kept Secrets of Peer Code Review is to get you to purchase certain solutions after you read — but the quality of information contained in this particular white paper earns the right to make a pitch at the end.

Development: Designing for Google Glass, part one and part two

Alli Dryer’s team got their hands on the Google Glass hardware and started working with it. Dryer’s response was to bake bread — which has turned out to be an interesting experiment in developing for Glass.

Funding: Auto-canceling subscriptions

Beeminder is taking an interesting approach to managing its subscriptions. If a user hasn’t actually used the service in the past thirty days, Beeminder suppresses the credit card charge. While many startups using a subscription revenue model count on their users to be too lazy to unsubscribe when they no longer use the service, Beeminder doesn’t want to fall into that group.

Operations: In search of the next big thing

The Harvard Business Review has a lengthy interview with Marc Andreessen that includes, among other things, exactly what he looks for in the entrepreneurs he wants to work with. He suggests that one person has to be able to have all the key characteristics — that partnering a founder with a CEO or an innovator with a business expert doesn’t work nearly as well.

Marketing: How to get customers involved in your content marketing

There’s always a benefit to getting your customers onboard in helping you with your marketing pushes, but you have to show them why doing any part of your marketing for you is worth their while. Andy Hayes explains how to show them the value. This article is actually part of a larger series on content marketing that’s worth reading through.

Beyond Tech: My last name is correct, and your DB validation is stupid

Tarah Wheeler Van Vlack’s name trips up some websites — despite not being nearly the most complicated name I’ve seen. She’s justifiably upset that many systems can’t cope with something as simple as dealing with names that are just a little bit different from what one database designer might think of as normal. It’s food for thought when you consider that everything from user experience to marketing efforts may make use of any name data you collect.

Our most popular link this week: Startups & patents: It’s better to know a few things about patents and trolls

I’m also guessing that’s what many of the developers who got involved in the Lodsys episode we’re thinking as well.

There’s a 90% chance that what you are reading here is not going to be of any consequence to you or your startup. But the risk factor within that 10% is huge so it would be better to be equipped than to be ignorant and taken by surprise.

Here’s the thing:

• Patents are super complicated stuff and are usually at the cutting-edge of tech (huge companies with large R&D funding). But that doesn’t mean indie developers are going to be out of the patent thing when it hits the fan.
• Patent trolls are growing in number. Not that you should be worried unless you’re doing some really ground-breaking stuff which builds upon a lot of other technology, interface, design and code. But it’s okay and in fact, very important to have a basic understanding of patents and related stuff.
• And…

I’m particularly pointing at iOS developers (and mobile developers in general) but the effects are far-reaching. Software patents are crazy and complex stuff. They’re often very unclear as to where the patent’s application begins and where it ends. But when you’re starting up, and you’ve built something, and then there’s someone – with deep pockets and deeper intentions – knocking on your door with a letter that’s decidedly threatening to sue you on patent infringement, your world begins to shatter.

This is real, folks. It happens. More often than you’d think.

Why Should I Be Worried?

1. You are developing something which has similar alternatives out there already. The deal is, you think you are building something totally different from the way the other thing works. It in fact is but there are aspects to your product which definitely build upon some features of the the other app/product. If they’ve got them patented, you might be in a little trouble.
2. You build some amazing stuff that’s going to be an overnight success (there’s no such thing as an overnight success but let’s just say that your product becomes a huge success). Eventually, it comes to light that there’s already someone with a product similar to yours and in fact a lot of stuff is similar. They’ve filed for and got their patents! Bam.

Okay. What Should I do?

1. Peer review is the best thing in the world. And it’s not just for researchers. Get into networking with other developers. I’ve shot down my friend’s ideas (and have mine shot down) multiple times in a day when some cool feature pops in our heads. It’s surprising to note how many of our “cool ideas” have already been implemented. And some of them, patented.
2. Ask the whole wide world. Say you’ve got a feature in mind and don’t want to share it right now because you think it’s definitely an awesome thing? Build a prototype/MVP and then preview it to folks on sites like HN, Reddit, Quora and other places where a limited set of people view. They’ll tell you if there are other people doing the same stuff already. You can then do the reconnaissance and figure out if you’re safe.
3. Make friends with an attorney who has some experience about these things. Bootstrappist has had attorneys write about patent laws and stuff. Thursday has written on it too. It’s important to be acquainted with someone who knows and understands these things just to be on the safer side. Check out this slide.
4. Follow blogs like these that deal with patent laws and how they (might) affect startups.

As I said, there’s a 90% (or more) you won’t have to bother about all this stuff. But a little knowledge about these very things that are boiling at this moment can help you protect yourself from trolls and possible patent infringement.

Daily Challenges.

Whether or not you’ve played the game doesn’t matter. Quite a lot of games do have this ‘daily challenges’-like feature where you set out to complete a simple “daily” mission. So simple that it takes no longer than a few minutes to complete it and so rewarding that once done, you feel like you’ve conquered the world. Okay, not exactly so but something close to it.

So what I did was I copied this particular thing into my work. I was coding a new website from scratch – nothing huge, but I know I’d have put in a lot of sleepless nights if I had not used the daily challenges hack – and I consciously applied the same thing that the game has. I identified simple “challenges” and finished them every night. Sometimes, I did get carried away but with simple little daily challenges this is the success story: I never missed even one simple daily challenge ever.

This “daily challenges” hack isn’t new and in all probability you’ve heard it before. Where it really strikes is converting this into a really exciting game. And being consistent.

I’ve tried many hacks to get things done faster, better and I’ve failed many times. May be this will stop working after a while but for the moment, the daily challenges thing works like a charm! And although I was skeptical at first, it seems to be quite good!

Especially since this thing worked with coding (and a bit of designing), I wanted to share it with you. Here’s how you can apply the same process to your work:

1. Find out simple little challenges for every day. These should be 10-20 minute challenges. This might be adding a new plugin, writing (a part of) a new library of code, finishing a small chunk of interface, or even extend it to non-coding work: sending a few emails to market your product, working on Twitter/Facebook to interact or build a few followers etc.
2. Work on the challenge and have nothing obstruct your work. Switch off email notifications, don’t log into any IM and most importantly, don’t get buried in a lot of tabs.
3. Never miss a daily challenge. It’s okay if daily challenges take a monstrous all-nighter form but it’s absolutely not okay to miss a daily challenge. Self-discipline helps.
4. Don’t make a weekly list of daily challenges. I don’t know if that really helps or just makes us complacent but what really worked was not making long-term daily challenges. Finish a daily challenge and you’ll know what’s up next. That way, you’ll pick something you’ll like to work on and the next day, you’ll be working on it.

Now all of this sounds like old wine in a new bottle but these are worth exploring frequently.

Bugzilla

One of the first things we needed was a way to organize and track our development efforts. Features we planned to add, enhancements we needed to make and bugs quickly became difficult to manage via e-mail alone. Almost immediately we installed Bugzilla to provide a quite robust issue tracking tool. Like most tools of this nature, it includes reporting, prioritization, notifications and searching. You can download Bugzilla here.

We use Bugzilla for three functions; bug tracking, creating our product road map and customer issue/question resolution. Bug tracking is the obvious thing that Bugzilla is traditionally used for and entering and assigning bugs is extremely easy. After we installed Bugzilla we added general product categories and assigned either me or my partner as the maintainer (he’s the frontend guy, I’m the backend guy) with the other as a CC. Either one of us can add bugs and an email is sent with the description. All of the features you would expect in an issue tracking package are available in Bugzilla – all free of charge.

After our first release the roadmap for the product started to take shape. Bugzilla allows you to create “milestones” that essentially partition your feature or enhancement requests by release. We created 5 buckets for releases we called Shamrock (March), Blue Ocean (April), Tangerine Trees (May) and Mist (Who knows?). We can move items from release to release and create reports specific to each. When it’s time to do a release we can run a report of what we’ve fixed and added for this release and put this in a “What’s New” section of our web site (scheduled for Blue Ocean).

One of the more interesting things we’ve done is use the APIs of Bugzilla to send information requests and customer inquiries from our Contact Us page to Bugzilla. We didn’t want to write yet another customer inquiry tracking system (hardly core to our product) or just have our web application send an email that would end up in the black hole of one of our inboxes, so we cooked up a way to use Bugzilla for this purpose.

Our web application collects the user information, their browser specs, their question, issue or comment and puts a message on Amazon’s messaging system queue. A daemon on our backend server is listening for messages on the queue and when it sees a “Bugzilla” message we unload the message contents and call one of Bugzilla’s methods they expose in their remote API to insert the issue into the tracking system. Based on the the user’s selection of the issue type, the bug is routed to either our CPAs, or the technical group (that’s me and my partner). This allows us to make sure that all customer inquiries are followed up on and we have a record of their resolutions. Voila! Issue tracking – free of charge.

LibreOffice

As you might expect from an accounting system, our product produces a lot of reports. Our report generation methodology is to create an Excel spreadsheet using some Perl scripts and the Perl Spreadsheet::WriteExcel class. We then (optionally) convert the spreadsheet to a PDF and deliver that to the user’s browser, their briefcase (Amazon S3 storage) or send it as an email attachment.

We run LibreOffice in “headless” mode as a daemon and use its ability to convert an Excel file to PDF. A PDF converter – yep, free of charge.

Other Freebies

jQuery – Like a lot of web applications, we leverage jQuery. The javascript library allows us to create our UI for all browsers and provide features it would have taken months and months to create in a fraction of the time.

Google Voice – Give us a call! (315) 313-4TBC. Until we’re more established and have a staff of more than bootstrappers, our telephone presence is just an answering service. Using Google Voice I setup a free telephone number, created a friendly message and encouraged folks to “leave a message and we’ll get back to you right away”. Google Voice converts the messages to text, and sends me an email, seconds after they hang up. The transcriptions are surprisingly good and the email with the message text also includes their telephone number. You can also have your calls forwarded to another number or text you when you receive a call. Google has stated that Google Voice will remain free for 2013. It may opt to charge for this in the future, but it is a fantastic service, especially for startups.

Finally, we’ve used Doodle to schedule team meetings, Survey Monkey to survey our beta users and AnyMeeting to hold webinars. All free.

I was raised by parents with a strong work ethic and taught there is no free lunch in life. Apparently though there are free services and free software! Enjoy!

This post is Part IV of the series: 5 Ways to Jump Start your Startup by Rob Lauer. Read Part III of this series here.

#9: Land 20 Paying Subscribers.

Startups often aim for the first 50, 100, 1000, 2000 users. Sometimes, startups that are focused on “social” try to acquire more customers, faster. It usually runs into thousands. But 20 is a magic number. If you are bootstrapping with finite resources and time and if you’re building something that you want to last long – real long – this is the number you should target too.

The usual thinking goes like this: more customers, more revenue. So the focus is on acquiring more customers (early on). The faster, the better. So startup developers create their marketing strategies based on this philosophy.

It’s not wrong but if you are bootstrapping, it’s going to be a Herculean task and you might be totally “de-motivated” if it fails. Forget 100, it’s hard to get 50 paying customers unless you’re giving away iPad Minis with every subscription. Now, that isn’t a great revenue model or a marketing gimmick anyway.

So why 20?

The key idea I want to drive home is the feeling of cult. A cult of passionate users.

Case in Point: Facebook.

Facebook wasn’t built to acquire a thousand, hundred thousand, million or a billion users. It was designed to keep a few friends in the loop of things. Pet project. And the users were kind of a cult because they were passionate in using the service – leading to the cult following. The number of users was small to begin with but because they were using it religiously, a cult formed. And like every other cult, it grew. Outrageously.

There are thousands of such stories but I’ll skip them all for brevity.

Keep the idea of cult in mind and then read this:

1. Finding 20 Paying Customers Is “Easier”

“Easier” because I’m comparing that to 100 and 1000. Finding 20 paying customers isn’t easy per se but it’s easier than doing what’s written on a post-it note that says, “Get 100 Users!” The key benefits of going with this magic number is: a) shorter time, b) lesser marketing expenses and c) easier to manage 20 users if you’re running into support issues and re-fund problems!

2. Validation Is Faster, Smoother and Easier

One key component of startup success is to figure out if your product will fly. Put 20 users into the lab and you’ve got patterns: How many are coming back? How many are trying to reach you with feature requests? How many are total strangers who’re trying your app/product? What’s their reaction? Feedback? Expectations? 50 can be a hard number to reach in the first place so if you’re looking for validation results from 50 or 100, that’s going to be hard. 20? That’s the magic number.

3. Refining Your App/Product with 20 Users Is Smarter

Lest we forget, no product became successful at one go. Refinements, tweaks and changes based on user-feedback has helped a lot of software become popular. So, if you focus on reaching #20 first, you get a chance to refine your app faster before hitting the higher numbers. In fact, it is with the suggestions and test-results and analytics of this batch of 20-users that your product’s future is decided.

4. Engaging 20 Users to Create the Cult Is Easier

Most importantly, for all the above to happen, you’ve got to engage with these 20 users. Sometimes, you can engage directly: via forums, polls, email etc. Sometimes, you can do it directly through your app/product. Whatever it is, if you’ve got a 100 people knocking on your door, it’s a bit scary and tough to handle. If you’ve got 20, you get more personal and the engagement is kickass. Not only that, but you can engage to turn these 20 users into passionate users (by lining your app to meet their needs, by providing kickass support, by creating value-additions etc.)

You can drive analytics easily and read the data even more easily. With 20 paying users, you can refine your product and get brownie points with word-of-mouth marketing from these 20 cult users. Engagement is key. That’s how you can create a cult.

If you can create a cult of 20 users who stick to your product/service passionately, you’ve got a winner.

So remember two things: the number 20 and a cult-following.

Image by hatalmas

Big Omaha is an amazing conference on innovation and entrepreneurship, smack dab in the middle of the country. Today’s the last day. Even if you weren’t able to attend, however, go through Silicon Prairie’s coverage of the three day event. There are videos of some of the talks and summaries of others. It’s not quite the same as being there, but you’ll still get a ton of information.

Start with Tony Conrad’s talk on [starting movements, rather than companies](http://www.siliconprairienews.com/2013/05/conrad-encourages-entrepreneurs-to-start-movements-not-companies). He challenges entrepreneurs to think big, which in turn can spark more significant successes.

Development: This 17-year-old coder is saving Twitter from TV spoilers (Spoiler: she’s a girl)

Jennie Lamere participated in the TVnext Hack event, beating out eighty other competitors, including professionals from companies like ESPN and Klout for best of show. Her idea? Blocking spoilers on Twitter, in just 150 lines of code.

Funding: How to pick the right revenue model for your app

This in-depth article from Andrew Cohen lays out the different factors that can determine what revenue model will actually work for an app. Cohen learned about revenue the hard way; his company built Brainscape, but put off figuring out revenue until after they’d gotten some traction.

Operations: Why does your startup sound like a startup?

There’s a type of copy, a sense of website design and a type of product idea that has the startup feeling. Patrick Woods explores what makes a startup seem like a startup and makes some interesting arguments for how you should handle your branding as a result.

Marketing: Do you want to spam your LinkedIn contacts and be humiliated? Try FounderDating

FounderDating may prove to be the case study of how not to market your startup. It’s provided a definite anti-pattern with the way it has spammed the LinkedIn contacts of users. The approach was meant to spread the site virally, but has gotten some bad press instead.

Beyond Tech: Caesars Palace deals Google Glass out of its game

Caesars Palace has announced that people wearing Google Glass won’t be allowed in its casino. As wearable computing becomes ubiquitous, look for more places that expressly insist that such technology won’t be allowed in. Developers considering building apps for these platforms need to be sure that users will actually be able to have technology with them at the right times.

Our most popular link this week: Can you help a fellow bootstrapper? PixelPress is kickstarting

Most friends who dream up a startup do well despite the hard times. But sometimes, it leaves a bad taste. Sometimes you are down and out and feel like the other person doesn’t understand you at all. Sometimes the whole startup thing seems to be falling apart. And in most cases, it’s just a passing phase.

Co-founding startups is fun and a rewarding experience. Sure, there are the bad times when things go wrong, when there’s a trust-deficit or when paths seem to diverge oppositely, but if you can keep these rules in mind, you might as well enjoy the whole thing rather than fret about it.

1. This Too Shall Pass

One of the first things you should remember is that a debate heating up is usually forgotten one week later. So no matter how disillusioned you feel right this moment when you’re having disagreements with your co-founding partner, no matter how opposite your PoVs are, don’t let that put a dent in your opinions and goals. As they say, this too shall pass. Debates are good, heated arguments show the level of passion you’ve both got in making the project better. Never take these discussions personally.

2. The Talisman

There must be one goal towards which you both are working. Whenever you feel that you’re on a head-on collision course with your partner, make sure you don’t let this talisman fall: is this discussion going to help you achieve that one particular goal for which you’re working? By goal, I’m referring to the goal of your startup. It’s a no-brainer: if you’re debating about a feature that’s not going to be in the v1.0, you’re wasting your time and energy.

3. Set Aside Ego; But Be Truthful In Critique

Ego has no place in a startup consisting of two/three people. If you’re hurt when someone shoots down your idea/theory or if you take it personally, it’s time to rethink your role in the startup. Similarly, if you think your partner is taking things personally, try to talk to him/her about this.

However, this doesn’t mean you should sugar-coat or refrain from speaking the truth when it is required. Feel that your partner’s hypothesis is wrong or unacceptable? Shoot it down, if possible with facts and data.

If both of you have this ability to cast away personal reactions and act directly for the sake of the product you’re building, things will be very smooth even amidst the hottest arguments you have.

4. Go Beyond Self-Responsibility

A startup is not a place to find faults with your founder not doing their part. First off, you have the right to push them to do it for the sake of the company. After all, the product has been conceived by both/all of you. Secondly, there’s no jurisdiction of responsibility unless it’s technical where you can’t get it done.

Things like marketing, analytics, costumer acquisition, PR: if both of you can do it, and if for some reason your partner isn’t doing his/her part, don’t let that stop you from doing more than what you can do. Don’t set limits of responsibility: that can kill your product.

5. Always, always: A Good Time

Focus and make sure you have a good time irrespective of all the hardships and bad times. Beyond the 18-hour workdays and 72-hour launch days and numerous sleepless nights, startups are fun. You should’ve had a good time building the product and an even better time doing it together. When you look back, you must be able to feel completely happy that you did it. It’s not something that you can’t control. What you think, feel and do today has the ability to let you have that feeling in the future. Focus on having a good time. Take timeouts, reset memories, work on things you’ve found common grounds with, and then get back to the debatable parts with a clear mind. Argue but with a higher intention.

Image by Revol Web

—-

PixelPress is unlike most apps we’ve heard of. It is aimed at helping everyone create their own video games by sketching it out on paper. That’s it: no code to write, no stuff to design, no debugging. You draw the video game on printed paper and the app takes care of the rest.

Behind PixelPress is Robin Rath and the coolest thing is he has bootstrapped the prototype of the app and is now set to crowdsource the funding via Kickstarter. This will help him move from the prototype to a full-fledged iOS app ready for use by kids, students and everyone who wants to try a hand at creating cool side-scrolling video games like Super Mario.

We got talking with Rob and he’s been juggling PixelPress with other projects/work and putting in a lot of hours to get the prototype floating. He is very much your fellow bootstrapper. I’m sure there will be plenty of important lessons that Rob will share with us but before that, we want you to take a look at PixelPress.

PixelPress will be funded by people like you and me. Right now, it has crossed the prototype-stage and according to Rob, the app has tested well with 12-year-old kids (and adults too!). It looks like even today’s kids draw their own video games after hours of fun with Mario. Well, there’s some solid market validation.

Robin launched his Kickstarter campaign to raise $100,000 to fund the development of PixelPress as a complete iOS app with future prospects of adding a ton of features. Right now, PixelPress is going to be a multi-level side-scrolling game – much like Super Mario – but in future, it could also turn out into other formats.

Go check out PixelPress on Kickstarter. If you’re interested, your funding will go a long way in helping Robin get an amazing app out into the market soon. And don’t forget to share PixelPress’s Kickstarter campaign amongst your friends. Help us spread the word about Rob’s new app!

Bootstrapping your startup means making do sometimes. My bet is that your late night tinkering on your own computer led you to an idea and a prototype. Now you need to share it with the world – but you don’t want to spend an arm a leg yet. That might mean finding an appropriate hosting service, a development server or platform – on the cheap – after all we’re bootstrapping right?

For our first development environment we used a VPS service that served us well ($15.95/month). We knew, however that we were going to need more than one server and we were not comfortable with “on-the-cheap” hosting services for a production environment. While we continued coding our butts off, I simultaneously began researching our target production environment.

As the title of this blogs suggests, it’s a jungle out there. There are a lot of good hosting services competing for your business, but how do you decide which one to go with? First, I wanted true cloud services, not just a managed hosting environment. We have enough sys admin experience to set up our own infrastructure and environment so I wanted to be able to spin up and shut down servers easily to experiment with various configurations. I did a cursory comparison of various providers of cloud services (Rackspace, Amazon, and ToggleBox) by reading reviews, blogs, and other forums that described the performance and pricing of the different options. Amazon has a ridiculously easy way to get start called their “Free Tier” (1 year free use of a micro EC2 (Elastic Compute Cloud) instance and some free S3 storage). If you have high CPU demands, the micro instance may be unsuitable, however it worked well for our purposes. I highly recommend that anyone looking for hosting or cloud services take advantage of Amazon’s free tier if for no other reason than to become familiar with cloud computing.

I dished out about $50 to explore ToggleBox – a similar cloud hosting service that allows you to start up and spin down server instances quickly. Their dashboard and interface were a little clunky compared to Amazon’s and their performance was no better than Amazon’s using a similarly configured server.

Rackspace primarily offered only hosting services and did not have the flexibility or services I was looking for at the time. Since then Rackspace has fully integrated OpenStack and is catching up to Amazon in providing the tools and services you need to create your own platforms quickly. It might be a good option today, but was not as fleshed out 18 months ago.

It was quickly evident to me that Amazon’s Web Services provided everything we needed and at reasonable prices. I actually went so far as to create spreadsheets that showed the hosting costs at various configurations and success levels. I wanted to be sure that if we needed to add storage or add CPU the costs would not eat into the profits too severely. After all, the point in creating a SaaS like ours was to create a massively scalable (from a revenue perspective) product. To do so we needed a massively scalable architecture as well.

My original cost calculations have been way off. Amazon, as well as all of the other cloud providers keep dropping their prices. In fact, Amazon has had 22 price drops since the inception of their services. My original calculations that showed we need not be afraid of success are now obsolete. I don’t even bother keeping the spreadsheet up to date anymore.

After 12 months of development we moved all of our development to the Amazon cloud and finalized our platform. Here’s what our platform looks like today:

Credibility with our customers was a big concern. We wanted to assure our customer base that they can rely on our infrastructure to provide a highly available environment that protects their data. We even programmatically encrypt all of our customer’s documents (although Amazon’s S3 storage can be configured to encrypt data automatically). Amazon’s Cloud gave us instant credibility with executives and officials of the organizations we’ve spoken with. There’s something to be said for an infrastructure that can be distributed across all of the world’s tectonic regions.

While we could have easily managed our own MySQL instance on our main web server, we opted for a managed database service (fully backed up and maintained by Amazon) that would allow us to distribute the load. We’ve offloaded the backup and database maintenance for just a few more dollars a month and by purchasing reserved instances we further reduced our expenses. Our final bill for 2013 is expected to be somewhere between $500 and $600 for our entire infrastructure. Our sushi lunches for 2013 will undoubtedly be higher.

Most importantly, we can scale any part of our platform up to increase performance as we add customers. To increase our web performance we can add servers or we can use Amazon’s load balancing service ( Amazon Elastic Load Balancing). Although, our current load is very small having just launched in February we felt we needed to build scalability and fault tolerance in from the beginning. I’m big on visualizing success in order to create success (but also frugal) so there’s no better way than imagining the viral spread of Treasurer’s Briefcase and making sure we can handle the load by spinning up 3 or 4 more web servers or adding another terabyte of storage! Now all we need are customers. Bring ‘em on!

These are few questions that startup developers keep asking themselves. Some don’t “start up” because they don’t have concrete answers to these questions. Some stop the development mid-way because validation isn’t happening.

In the wake of Moot‘s phenomenal success, I was thinking about market validation. That’s a process almost every creator faces. But come to think of it, the most successful products didn’t have validation as a separate entity. And most notably, questions of market fit never bothered these successful founders and developers.

At the base of all these successful products, there was something simple: a personal need for the product.

The startup pyramid didn’t really matter. (Read what Marc Andreesen says)

If you’re worrying (a lot) about market fit/validation, you are doing something wrong or you’ve gone out of the limits of “bootstrapping.”

1. The “market fit” problem is something large companies face. Sure, startups face it too but only when they put all their investments in line and survival of the startup relies on the success of the product being created. Then, it makes sense to think really seriously about market fit.
2. You’re thinking a lot (more than necessary/optimal) about validation if you are really not sure about the product you’re building. That means you won’t be using that product yourself (not much at least) and you can’t explain the purpose of the product (or justify its existence) in simple terms.

This is so cliche but I am ready to repeat it: scratch your own itch if you really want to build a startup that you’ll enjoy building and that means not worrying about market fit. At least, not as much as many startup founders do.

Obsessing over validation can lead to stuttered development. In many cases, this has stalled projects, killed startups prematurely and made 9-5 employees out of talented bootstrap-entrepreneurs.

Bootstrapping is about building fast, being lean and learning / tweaking. Almost every product that’s successful today has undergone a lot of changes and tweaks. They didn’t start out the way they are today. Take Facebook or Twitter for example. If you looked at their initial days, you’d probably not even want to sign-up. But they are the exemplars of lean startups that have mushroomed into successful companies.

Bottomline: build a product you’ll use passionately; solve your problem; don’t obsess over validation and most importantly, don’t let questions about market-fit decide the fate of your startup. Build something and then you can tweak it out in the real world. Out in the real world, you can tailor it to fit the market based on user feedback.

Image by Andrew Plumb