Planning your Startup

John McCaffrey

How important is the Programming Language I choose?

I get inquiries about helping out as a Tech Lead, or Part-Time CTO for early stage companies, and a frequent question I keep getting is "Which language/framework should I choose?", and while I love Ruby and Rails, it usually isn't my first answer.

Here's a recent conversation I thought I'd share:

Dear Mr. John McCaffrey,
 Question: If one would want to start building a web based SaaS product (real estate portfolio management tool), that would eventually connect to mobile devices too (for agents), what programming language would be most appropriate with which database backend (SQL vs. noSQL?) to keep data (payments, utilities, invoices, scanned documents?) 

Where would one start? 

Here's where I would start: 

1. Market analysis.
  Are there many apps in this space already? If so, you should use a few, and read through the user forums/complaints to verify that what you want to do would be a valued addition to the space. (I'm often surprised when someone approaches me with a business idea they want to pursue, but they haven't used the products of their competitors exhaustively yet). What is the fastest/best way you can prove your idea has any legs?

2. Programming language
Unless you're already familiar with providing a service to this user base, most of your discovery will be in understanding what customers need, and how your approach is different/better than what's out there, so its important to have a flexible architecture, and be able to find the resources you need to keep moving it forward. Ruby/Rails is great, and you can build apps very quickly with it. There are a lot of great tools/libraries for getting things done quickly, and great options for hosting your app. The main problem with Rails is that the developers are very much in demand, so experienced ones will be expensive, and while a junior dev will cost you less per hour, they might take much longer to do tasks, or build the app in a way that decreases its flexibility. PHP is also great, and much easier to find senior developers at a reasonable rate. As far as Mobile development goes, I usually recommend that people create their website first, enhance it to work well on a mobile device, and then look to building a native mobile app once they have proven there is enough demand.

3. Establish your budget and goals upfront
How do you quantitatively measure success, and how much are you willing to spend to reach each milestone? I've seen too many business owners use up their entire budget on the first release, and not leave enough for enhancements, new features or general maintenance. I've also seen too many projects where the features were not directly tied to a business goal, and new features keep getting thrown in which eat up the budget without increasing revenue or improving the app. List out the features that you think are critical for the application to have, and how much they are worth to you.

4. Plan your feature releases. 
As a guideline, I like to organize the development plan into a rough schedule of 2 weeks of development followed by 1 week of testing/fixing/deploying and planning/designing for the next release. Once you list out your features and plan in 2wk blocks, it makes it much easier to track your overall timeline and make sure that the budget is reasonable. It can also help highlight dependencies between features, and features that need to be scaled back.

Assuming 2 developers at $50hr each working roughly 30hrs a week = $50 x 30hr x 4wks x 2(devs) = $12,000 for every 4 weeks of work, and you'd most likely have 2-3 months of work, so a rough budget of $36,000 would cover the first 2-3 months of building the app followed by some smaller amount to host and maintain it. ($50hr is actually on the low end, so adjust for rate and hrs/wk as needed)

Given a common IT ROI timeline of 3 years, and these sample numbers, you might want to target building an app that can generate $12k of revenue per year, or $1k per month. If you charge a monthly fee of $5, you'd need 200 users to hit $1k in gross revenue, and after 3+ years, you'd have your investment back, and could be very close to profitability!

This is just a rough guideline to give you a starting point for your planning. You could take different approaches to get to market faster, charge less but target a bigger market, or focus on a smaller but higher end market.

A few questions to ponder:
1. How do I verify that there is enough of a market here?
2. How could I build this app for less?
3. How could I get more than 200 users at $5?
4. What features would get them to pay more than $5?
5. How can I get additional funding to accelerate the timeline?
6. What can I do to stay ahead of the competition?

So while your technology choices are an important factor in all of this, they are clearly not the most important factor. They will have an impact on your initial development timeline, your hosting costs, how easy it will be to modify and add new features, and to manage your staffing needs.

I hope this gives you a good sense of how you might go about planning for you application. Feel free to reach out to me if you have more questions.

-John McCaffrey

** The $50hr dev rate, and ROI calculations are provided as simple numbers and baseline for discussion/comparison. Feel free to plug in your own numbers, or give feedback for what ROI schedule you use in your IT projects.

I've had this conversation with a few people now, and wanted to share my thoughts and get feedback from others.  I would welcome any additional feedback as to what advice you have for navigating the early stages of building a Web application/startup, with regards to making your technical decisions, building your tech team, and managing your budget.

This post originally appeared on
Image courtesy of Dave Dugdale at LearningDslrVideo from his flickr photostream


Post a comment

or to post comments


Andre Taylor
Great post. One thing I seen alot was non-technical founders choose a platform without thinking about the long term stability of their website in terms of membership growth, developing an app, adding new features, etc. This post gives great tips one should think about before choosing their platform or have a strong tech team that can educated them
Jeffery Smith
Great post. I think people obsess a little bit too much on the question of development platform. Typically there are a couple of questions you can ask regarding your product in order to get an idea of what NOT to use. Then from there your decision is usually most heavily influenced by the skill set that is available to you. If your technical co-founder is a Django guy, unless you rule it out for some reason, Django is your platform. I spent an embarrasing amount of time trying to decide between MySQL and PostgresSQL. In the end, my customers don't care what DB platform we use. The technical elite will bicker about which is better or stronger, but both platforms will present their own set of problems. Chances are you won't even be able to predict what problems you'll have as your startup goes through multiple pivots. Flickr emerged as a pivot from a web based massively multi-player online game. I'm sure they faced challenges as they move through ideas. You'll inevitably find that a technical decision you made wasn't the right one. Look at it as a right of passage.
John McCaffrey
Totally, and as you mention, being in a position to reflect and pivot, and having the flexibility to implement and roll out new changes is key. The challenge is finding the right balance to get the most out of your budget, so you have enough runway to be able to pivot, and enough flexibility to do it. I would hate to see someone blow their entire budget on a 'great' app stack, and not leave enough for new features and maintenance. This is also why I'm a huge fan of leveraging low cost hosting and management solutions, to help stretch the budget out. Gone are the days of kicking off a project and then having everyone wait while we "get all the servers set up", and then have those massive servers sitting idle for the first 3 months.
John McCaffrey
Tomas & Chris, I think the right amount of 'pushback' is definitely a critical component of being a solid developer. Knowing when to ask "is there an easier/faster way to get there?" and "what business goal does this feature relate to" can save tons of time, and help you reach your targets faster. Its about the right balance of value to effort, and applies to technical decisions and where to focus business efforts. DHH said it better in his post (a great read, which I picked up from @edavis10) "The best developers aren't the ones who can write the most code in the shortest amount of time or out-reason anyone on the internets. They are the ones that only write the code that's most valuable to execute and only enter the debates of high substance."
Zak Boswell
Great read...
Chris Courtney
One thing I would say is that building something to learn and building something to take to market are two different things, Tomas. When building to learn, I really think that having a firm grasp of what the expected outcome of a project is key—thus building Twitter clones or airline websites are perfectly fine in that context.
Tom Ordonez
This is a great posting. I often see that non technical cofounders and new developers want to jump right into building an app without doing any market research or customer development. From a new developer point of view it is fun to build an app. But you also have to ask yourself if the app is just for fun or to make money. If you are depending on the app to make money I think you should stop developing and jump into lean startup mode.
Chris Courtney
nailed it.

Oh no!

You're fresh out of job post slots.

Upgrade your planmanage current jobs

Create an account

Let startups find you

Create a profile and upload your resume today.

Explore the local startup scene, find your
dream job and hang with fellow techies.

No sales pitches, just awesome original content.

Oh no!

You're fresh out of job post slots.