Your startup's early infrastructure decisions are probably the most painstaking and time-consuming ones you'll have to make, for both the technologists and the businesspeople on your team.

It is hard to know what your company and product will need (and be) 6, 9 or even 12 months down the line - especially today, in the era of the pivot, and the lean startup. Get it wrong, and you're going to spend a lot of money later fixing the problem - just ask Twitter or Facebook.

Craig Knighton is the VP of Engineering and Technical Operations at LiquidSpace, the mobile application that helps anyone find a great space to work right now.
Scale rightfully gets a lot of attention because we're all driving towards that hockey stick moment, with visions of gumdrops, and viral coefficients dancing in our heads.

But it's not merely scale that causes us to wake up in the middle of the night.

For example, if you're doing business in markets with demanding customers, or plan to forge bizdev relationships with big brands, infrastructure is more than just a matter of cost, or convenience - it's a matter of scope and tenor, possibility and ambition.

Y'all know them stakes is high When we talkin' 'bout the (Vibes...vibrations) Stakes is high -De La Soul

Before jumping into anything, we at LiquidSpace spent a lot of time asking our partners and customers what their expectations were, how they were architected, what they were willing to throw resources at, and what they wanted to be purely turnkey.

But, startups weren't always built with this luxury.

At my previous company, there was no such thing as the cloud. We had access to a managed services data center where we had to buy or lease the hardware and actually work with whatever infrastructure provider we had chosen to get it physically mounted into the racks themselves.

Contrast this situation to today - most companies have zero capital expenditure costs when considering infrastructure.

Server capacity can be added in 10 minutes by just clicking a few buttons. Load balancing is automatic. And you hardly ever need to hire staff to manage or monitor anything.

And the big name IaaS (Infrastructure as a Service) and PaaS (Platform as a Service) players have found their own footing in terms of actual market maturity and adoption. This is a very good thing, but it also means that the number of choices we have is exploding.

The best advice I can give you is to, before anything else, ask yourself these 4 questions to help you see the forest for the trees.

Four Questions To Ask Yourself

1. If I were to get locked in, would that be an advantage or disaster in disguise for my business down the line?

It all depends on your goals.

Lock-in effect definitely does exist and is one of the primary concerns of developers looking at different platforms. Technology changes, strategy changes, and you never want to get stuck asking for permission, or twiddling your thumbs.

But it's not always a bad thing, either. Being locked-in can mean you're getting a reduced rate on a number of machines, or receiving other perks and services. Vendors know you have choices, and they reward you for staying with them, because there are ample up-sell and cross-sell opportunities over time. The success of Microsoft Bizspark proves this out (disclosure, Liquidspace is a Bizspark One company, and an Azure shop).

Remember that the issue is not just about what is the best decision today. What can and will grow with you, even outpace you, and open up new possibilities?
Regardless, once you're in with any platform long enough, the cost to switch starts to go up. At some point even if you wanted to switch to another service, it may be too expensive, period.

That is - even if you're not "locked in" - you sure as heck don't want to be bouncing around, either. And when you've settled on something that works, emotional and financial lock-in are more powerful than any vendor incentive or disincentive.

Remember that the issue is not just about what is the best decision today. What can and will grow with you, even outpace you, and open up new possibilities?

2. Does my company need a feature-rich platform, or do more features not necessarily make all the difference?

More or less, you need to decide what features you actually need. Separate whiz-bang from actual utility.

For example: not everyone needs to quickly spin up a new Linux instance or use Elastic Map Reduce on AWS to get an on-demand, preconfigured Hadoop Cluster. Herouku is elegant and simple with so many add-ons, but its fate in the hands of Salesforce is a question mark for some, as is their Ruby-centricity. Azure is an incredible jack of all trades, but .NET can be a deal-breaker, good interoperability notwithstanding. The list goes on.

IT departments are notorious for getting caught up in a tool-level conversation. They choose the one with the most features because there's always that fear of "well, someday we might need that."

The only features that matter are the ones you know you need now, and expect to need in the next year or two.

Similarly, many companies get too dogmatic about languages and frameworks. Resist that instinct - great, leading companies have been built on everything, and with everything. Fit matters most.

And, as the market evolves, the infrastructure and platform lines get blurry. The IaaS guys are adding PaaS capabilities and PaaS guys are busily adding retrofitted VM-type features for the market segments that want it.

How each startup does this calculus is different: what skills do I have and how burdened are they? Is managing my environment strategic? Or does my company's innovation happen at a level above? Do I want my infrastructure vendor to abstract away the maintenance, management and/or patching of my infrastructure?

More services and more abstraction might cost more in terms of our payment to a given vendor, but it could save a bundle in terms of staff time of my most skilled technical employees. That's the decision you're making.

3. So, speaking of support, does my company's location have any effects on who I can hire to do in-house support? How do infrastructure decisions impact recruiting?

A common question, driven by the fallacy that good talent is only in California, and that great engineers like to have their hair blown back by infrastructure ambitions...

They're not, and they don't. It doesn't, and you can.

My company is a really "liquid" company, with no formal office and a cultural norm of distributed, mobile working. We recruit great people no matter where they reside, and we're looking for those who care about the future of work, and want to leave the world a better place than they found it. The rest is gravy.

The best engineers, I've found, are drawn to higher purpose, more than they're drawn to computer science.

And one of the most spot-on predictions for 2011 was that developers would be in hot demand, yet supply would still lag. This is the reality we all live in, no matter who you are, or how much you've raised.

Does my company's location have any effects on who I can hire to do in-house support? A common question, driven by the fallacy that good talent is only in California, and that great engineers like to have their hair blown back by infrastructure ambitions...They're not, and they don't. It doesn't, and you can.
We've recruited heavily outside of Silicon Valley, though not exclusively so. We've optimized our stack for skills we know we can find more readily. We don't think this has made us any less innovative, either. Our team is really competent, cost-effective, and hungry. We drive towards business goals, many of them non-trivial, and in service of our Fortune 500 partners (not novelty, or ego).

For other startups, CS challenges and IP-level innovation on the backend, coupled with a more R&D heavy environment, is a huge recruiting carrot.

Know thyself. Match your available resources to your technology decisions. Don't buy technology that you can't support, or recruit for, and vice versa.

4. And finally, is the price right for the services I'm getting?

This is probably the hardest question of all as it's extremely subjective.

Each of the infrastructure platforms is priced to compete. They do that on purpose. Each differentiates on price in certain areas, but they inevitably make it up in others. What's more important to consider here is the relationship between the level of the cost and the level of services you're getting (and wanting), a "price-to-service" ratio.

Services could include anything from helping to promote your business to giving away free storage space, or access to a person who can help you track down talent.

Some startups want a provider who will take a seat at the table, and who adds value, much the way an investor would - a real partner. Other startups prefer a company that is more hands off, and laser-focused, more of a specialist.

You also need to look at true capability on your end - are you ready to handle all aspects of an IT and networking department? If not, you might not mind paying a little extra for someone else to handle it for you. If you have those capabilities in house, or intend to, you can be more self-reliant. What does your hiring plan look like?

In Conclusion - Be Self-Centered (In a Good Way) and Think Ahead

Ultimately, there is no truly empirical way of knowing whether one option is better than the other when it comes to choosing an infrastructure. There's always a leap of faith involved, so the question becomes: who inspires you to take the plunge?

Try not to project too far. If you must, be prepared to make a lot of changes along the way and ideally, put your money on a partner that's going to be around years from now, and can handle the pivots you'll make.

Overall, whether you're considering MSFT/Azure, Rackspace/Openstack, Amazon, Heroku/ Force.com or any of the many others out there, thinking through these decisions strategically can make all the difference.

These are also questions that investors and partners will be asking and expecting answers to. Make sure you have compelling answers, answers that can be a selling point, even - not just a due diligence check.

The most important thing to remember is that any application, technology or business is only as good as the people who use it, so keep your users and customers at the forefront. They'll never know what you're built on, but they will make or break you, day in and day out.

Photo from Toronto Society of Architects