Building a startup is hard. If you spend any time around newtech meetups or startup groups you’re constantly running into people who all seem to have the same problem, they’re a business person with this great idea, if only they could find a developer to build it. Seems like if you’re a developer and have a startup idea you’ve got it made, right? Wrong.
Developers have the skills to make their own vision a reality. That’s a huge advantage, but it’s also a problem. Because developers are really good at building things with code, the first thing they usually do is…write code. That’s the absolute wrong place to start, and that’s why most developers wind up producing something that nobody wants, with no users, and no idea where to go from there.
The key to not being “that developer” is to start with the business side. Don’t start writing code right away. Instead start thinking through your app, start talking to potential customers, start doing things like collecting emails that measure the interest in your idea. Now I’ve done this wrong a couple of times, but I like to think that I can be taught, and this post lists the 5 simple steps that I’ve learned for making a successful startup.
1. Mock
Buy a copy of Balsamiq mockups and mock your app. Not just the landing page, all of it. Every screen. This will force you to focus on the user experience side of your app (which is the only part the user cares about) and work through a lot of the logical problems, application flow problems, stuff like that. It will also give you something you can show to other people when describing your idea, which leads us to....
2. Talk
Take your mocks and show them to as many people as you can who are potential users. That part's important. You want to talk to people who are in your target market. Talk through the idea, talk through the app. Listen. Listen most to the people who love your idea and the people who hate your idea. Those are the people who care. Figure out what the key values that your product provides are from your customer's perspective. Also, as you get feedback, you should be updating the mockups incorporating the things that you'
This is the step that most developers will want to skip. Don’t. Talking to potential customers is the most important thing you can do as a Founder. It’s uncomfortable, it’s tough, you’ll find yourself fumbling for words and talking in circles trying to figure out how to describe your product. You’ll feel like an idiot for the first 10 or 20 conversations, but then something will start to happen. Just by sheer force of repetition you’ll find that you’re starting to figure out how to describe your product clearly, and you’ll find that you’re saying a lot fewer words while doing it. You’ll also develop a picture of what the benefits your product brings that seem to interest people the most. This is what you’re after. This whole process is necessary to teach you what your product really is and what your key value propositions are. It’s not easy but it’s absolutely necessary. If you’re not willing to do it then go work for somebody else, you’re not an entrepreneur.
3. Announce
Now that you have mocks, and you know what your key value props are (because you talked about it with many potential customers) it's time to put up the "coming soon" page. I would recommend doing a single page that describes the key value props and includes a screenshot. The screenshot isn't a real screenshot of your app. You don’t have an app yet. You can hire a designer to dummy it up from one of your mocks. I would recommend spending a few hundred dollars on 99designs. You can get every thing done at once, a good looking design for your "coming soon" page, a dummy screenshot, and a nice text treatment (no icon needed at this point) for the logo. Get this page up and start collecting emails of potential users.
If you're really ambitious and have something to say, you may also want to start a blog at this point. But don't blog about building a startup, blog about the problem space that your product is for. Blog about things that show your expertise in that area, and write things that your target customer will want to read because it's relevant to the problem that you solve. If you're building small business accounting software, then blog about small business accounting issues. Remember, the purpose of the blog is to attract and reach potential users, not other startup founders or the hackernews crowd.
4. Bizspark
If you’re building on the .Net stack you absolutely need to join Bizspark. Microsoft will give you free licenses to basically every product they make, including SQL Server, and a free MSDN gold subscription, for 3 years. They figure 3 years is long enough for you to get going so after that they want you to pay for new licenses, but here's the great part, they let you keep the licenses you're already using. So you don't wind up in a situation where you're just scraping by, then 3 years is up and you have a big Microsoft bill to pay. It’s great. Microsoft has basically taken the cost factor completely out of the equation for new startups, and it ‘s a perfect program for a .Net developer who’s building their first startup.
It may seem odd that I didn’t start with Bizspark as step 1. There’s a reason. You’re not ready to join Bizspark until you reach this point. Keep in mind that Microsoft doesn’t just accept everyone who applies to Bizspark. You actually are required to have a company, a website, and a sponsor. Your sponsor can be a company that has some kind of partner relationship with Microsoft, like Rackspace, or it can be a person employed by Microsoft, like Aaron Stannard who is the startup evangelist for Microsoft (aaronst@microsoft.com). So you’ll need be ready to describe your app and you’ll need to have a website up, not a completed product, just some type of website for your company. The “coming soon” site is fine for this requirement.
5. Build
Now that all that other stuff is done, now you start building the first version of your app. Note that you should continue to talk to potential users, you may even want to establish a small group of users who you show your app to as it's being built. The key point is that step 1 is not finding a developer, step 1 is not start building. Building the app doesn't happen until step 4.
While building, do not follow the common advice "don't worry be crappy". Nothing you produce should ever be crap. Instead I would recommend taking the 37Signals approach "Build half a product, not a half-assed product". In other words, your MVP should have half the features you want it to have, but what you do build should be awesome.
To give some technical specifics, I highly recommend building on MVC, not WebForms, and I recommend using a virtual server like an OrcsWeb cloud server or a Rackspace cloud server, not Azure. The reason is that for an early stage startup speed and flexibility are paramount. You’re going to be making major changes to your app on a regular basis for the first few years. MVC is a framework that embraces change and makes those changes faster and easier than Webforms.
The same principle applies in reverse for Azure. Azure solves the problem of scale, but scale isn’t your problem. My experience, and the experience of a couple of other startups I have first hand experience with, is that Azure slows down development. I think it makes your development slower and less flexible. Debugging is a pain, setting up your environment is a pain, deployment is a pain, the DAL becomes something you actually have to spend time and effort on, plus… what if you decide you need to run Redis or MongoDb or some other open source thing? Microsoft will probably make it possible so they can check off that box on the feature list and claim that it works, but odds are it will be a whole lot harder than just installing that software on a regular server. What if you end up needing to have 10 different services running? Is each of those going to be a separate Azure instance, and thus an additional bill? You don’t want to spend time worrying about stuff like that in the early days when your app can change massively every 2 weeks.
At the beginning, I think you’re much better off just buying a single cloud server. It runs just like a real windows server, it provides a familiar environment, it’s going to be a solid single platform that you can load up with whatever open source code and services you need (without paying extra), and you can scale it up if you you need to. Later, when you know what all the pieces of your app are and you have customers pushing the limits of your cloud server, that is the right time to look at Azure.
