Invariably one of the most critical decisions a non-technical founder can make is who should be their Chief Technology Officer. This role is huge because it encompasses not only making the decision for what platform/s (e.g. Java, PHP, Objective-C, etc.) to use, but also how it gets implemented – and on what timeframe. Simply put, for startups in the tech industry, you can generally gauge the chance of success by who is in this position and who is CEO. That’s it. No other information is needed – not even the actual idea.

The Impossible Man/Woman

The core competency of this co-founder role really should be: creative visionary, solid understanding of technology, decent programming skills, understanding of UX/UI, knowledge of how to architect applications, knowledge on how to setup a cloud or hosting environment, able to mediate between business, customer and technology concerns, someone who is always willing to say “yes” (not throwing up technical obstacles) and the ability to manage a team. Of course, this will also have to be someone who can work for less than the going rate in exchange for equity and be willing to give up large swaths of her life. Oh, and lest we forget – this person needs to get and love your idea and be someone you can not only tolerate, but enjoy spending massive amounts of time with.

But here is the problem: can you actually find someone who is all this? The usual answer is probably not. So now what?

Workarounds

In the tech world, invariably we come across some obstacle or another. You can’t do X in the browser. Mobile devices don’t support X. And when we do, we find a way to make our app seem like it’s doing that thing without really doing that thing. We call this The Workaround.

There is no reason not to have a workaround for your CTO Co-Founder. Here are a few ideas:

The Consultant Workaround

Consultants aren’t just for Fortune 1000s anymore. There are a lot of consultants that actually prefer working with startups. (I do.) With a consultant, you can have someone who will help you make platform decisions, prepare your technology plan (to include with your deck or biz plan for pitching) and maybe even help you get a prototype up and running. It will be significantly easier to find a consultant to work on your startup who has the experience and skillsets that are up to the job, and making a part-time commitment to your company is a risk they can take, whereas being a full-time CTO is not.

Don’t forget: a consultant now may be a CTO in the future. Many of us in the consultant world were once CTOs (or other CxOs) and are happy to jump into that role again for a company we believe in. There is no better way for us to believe in your company than to work with you.

You might find that a consultant will be willing to do this on the cheap in exchange for equity.  If that’s the case, make sure to guarantee a commitment of their time on an on-going basis – you don’t want someone to put in a few hours, give you only a modicum of support, but then reap potentially great benefits (and possibly be burden) down the road. One good option is to put them on the Board of Advisors or even Board of Directors if they are willing to do so.

The downside: this person isn’t a staffer. He/she may not be there when a crucial decision has to be made on the snap – and they certainly will bring a different viewpoint if they are. The flipside to this is that you will still have flexibility to get a CTO or (see the next section) Chief Architect.

Some pointers in working with a consultant:

1. Don’t rely entirely on a consultant. You will still want someone on your core team responsible for the technology. Either your own CTO or at the very least a Chief Architect.
2. Choose wisely. A good consultant can have connections to investors – or at least have experience in this regard. A good consultant can ensure your platform is scalable and not a throwaway. A good consultant will not require you to raise a bajillion dollars to work with them.
3. Be clear on directives. Sit down with your consultant and map out where you want his/her help to lead you. If you are starting from scratch, this will start with a technology roadmap and generally end with assistance in finding your real CTO.
4. If it feels weird, it probably is. There are scammers out there – even legitimate CTOs of the past can take advantages of startups, essentially signing on to do almost nothing until you raise money and then take some of it and continuing to do almost nothing. Don’t pay for a name. Pay for value.

The Chief Architect Workaround

The key not in this strategy is chillax, man. Sometimes you don’t need to have the all-around impossible man/woman out of the gate. Sometimes you just need a good coder. The key to this methodology is expectations. Too often, startups set out looking for a CTO, then end up hiring a rockstar HTML/Ruby (or whatever) guy, who builds a kickass app, but falls flat in providing the higher level management and planning skills. The only problem in this scenario is expectations – a Chief Architect knows they are there to build a kickass app, a CTO things he’s there to do more. And what this leads to is usually an unemployed and pissed off Chief Architect and a startup company with a gaping hole in their technology team.

Done correctly, you can have your Chief Architect work to build something and even help to find you a CTO who shares your culture, technology set and overall vision. Chief Architects are quite often simply future CTOs, but their inexperience gives them a nice lack of pretense. As such, they speak the language of the CTO (though perhaps not as well yet – but better than you) and they can help get the right person – and identify when they will be needed.

In my experience, this is probably the number one technology founder related issue that happens in young startups. Giving too much title too soon. However, it is a crucial advantage to have a techno-literate person in the core team.

The downside of this approach, however, is you won’t have the exact skllset you want out of the gate. Of course you won’t be paying as much for this position in dollars and/or in equity.

Some key success factors in this workaround:

1. Start out looking for a Chief Architect. Look for those skills – programming, setting up a hosting/cloud environment, architecting an application, etc. If an applicant provides other, more business-leaning skills, then offer that particular applicant a CTO position if you think it’s right. In other words, hire up, not down.
2. Give your architect responsibilities and a stake in the game. Don’t just make them the code monkey, make him or her a core team member. Let them make decisions. You don’t need to give them as much as you would a CTO (until, if it happens, they become CTO), but make them a part of your core team.
3. Look into having a Consultant or Mentor in the lurch to validate their decisions. But let them manage those relationships. Nothing will deflate an ego like having someone watching over your shoulder. That isn’t to say you can’t call the mentor or consultant to ask questions, just allow the architect to feel in control of the situation – they are on your team, at the end of the day, the consultant/mentor is still an outsider.

The Accelerator/Mentoring Workaround

This particular workaround generally requires that you have someone in the tech co-founder position. But what it doesn’t require is that they have the entire skillset(s) I mentioned earlier – the idea is that the accelerator will help you -  with advice, with office space and oftentimes with a development team. They will of course, in exchange for this help, take a chunk of your company. But it can be worthwhile – generally accelerators (or Incubators) are made up of individuals with considerable experience and contacts to help you get  your startup to the next level. They also may assign mentors to help you learn key skills and negotiate hurdles.

In order to be accepted into an accelerator or incubator, you will have to have your idea down pretty well – in essence they are giving you a seed round of funding, not in dollars, but in services. So be prepared. They will look heavily into your team and into how well thought out your idea is. You will need a good elevator pitch and some backup materials – a good deck and maybe even a prototype will help.

The downside to this approach is that you are essentially raising a seed round – but not getting the money, only help. This may be welcomed, or it may be annoying – you may want to have money to spend on marketing or things that won’t be included in the services package. This can be a great solution, however, for young startups with less experienced management teams, as you will have mentoring and resources to help you through sticky situations.

Some ideas for making this approach work for you:

1. Pick an accelerator/incubator that has helped companies like yours achieve success.
2. Do some due diligence – make sure to call other companies that have worked or are currently working with that accelerator/incubator and hear what they have to say. This is a critical juncture for your young company – give it the weight and time it deserves.
3. Maximize it. If/when you sign on, be sure to understand all the services and people that are at your disposal and maximize it. While it is in their interested for you to succeed, they are working with their other companies as well – you are ultimately still responsible for doing everything you need

It’s Not So Impossible

The key is that while the CTO/Technical Co-Founder position is a tricky one, there are a number of options for you to make it happen. These three are great options to help you on your path to success.

Questions? We are always open to helping – it doesn’t hurt to ask. Contact us anytime.

OK, so I’m not really going to go all X vs. Y – I’ll leave that to you. However, I have written a course on the most popular model-view-controller frameworks for PHP: Codeigniter, CakePHP, Symfony and Zend. In my course, I will discuss the advantages of using frameworks and then introduce you to developing in each of these frameworks by building essentially the same application.

Here is an introductory video to get you started:

P.S. – I Can Hook You Up

If you aren’t currently a member, I can offer you a 7-day trial – enough to take this course, and enough to see if you’re interested in more. If you are a member or want to see more of the free movies, here is a link to all of my courses – including this one -  in the Lynda.com Online Training Library.

Back in the days of pure web development (seems like so long ago now), when you needed to authenticate to the server, you authenticated in your app. When you needed to get some products (or whatevs) from the database, you got products from the database.

Not in mobile.

If you need to do that in your app, you need to create some kind of API – generally RESTful – that will expose any of this server-side functionality you need. Sure, you can save data to the phone, and that’s certainly what can be done in a lot of cases. But oftentimes we want to deliver something from a unified server – or from the cloud. And until recently, this meant building out your own. From scratch. In some other language.

Enter the new breed of Mobile Cloud PaaS (Platform as a Service) providers. There are three key ones that I’ve found to be the most noteworthy: Parse, Usergrid (recently purchased by Apigee), Sencha.io and Cocoafish (recently purchased by Titanium), and probably even more by the time I publish this. All of these give you a cloud-based app utility to ease (or eliminate) the need for server-side development. All of these tools will allow you to create a server-side backend for your mobile app with little or no development.

Are you listening?! You don’t have to build another #$^%@# API in Java/PHP/whatever! PIck a platform (I will explain to you the differences) and simply have your app talk to it. And then you’re done. That’s right. Back to your app again. These platforms will handle authorizing your app (using OAuth, generally) and storing user information and generally provide the ability for other services like notifications, social and in some instances custom functionality. And they all have some kind of web interface you can use to, at the minimum, see and interact with your data, but sometimes more (like analytics, etc). A brief overview:

Cocoafish

Cocoafish may be getting the most press lately due to their recent buyout by Appcelerator, the makers of Titanium.  Cocoafish is the most comprehensive in terms of out of the box functionality. Cocoafish is really, at it’s core a social media platform, containing it’s own APIs for status updates, friends (and core user/auth database), messages, places/checkins (with geolocation, obviously), events, posts, chats, likes/ratings/reviews and integration with other social media sites. That’s a lot to have in your toolbox. Then add the ability to have push notifications (iOS only for now), custom objects and queries and key/value storage to enable a data model for whatever you need.

When developing with Cocoafish, you can develop in virtually any platform, from Native iOS/Android to Ruby or PHP on the server (yes, you can use this for web sites as well) by interacting directly with their REST API. There are also SDKs available for iOS, Android, Javascript and Actionscript.

Currently in private beta. Currently free.

Parse

Parse is a more rudimentary backend that has an SDK for both Android and iOS. Built in are the core features any app needs: user management, push notifications (both iOS and Android), geolocation services, social integration and an open data storage mechanism. Parse is more aligned to the idea that they don’t provide additional services you don’t need, just an abstracted methodology to store and retrieve data for users that relates to your app.

The way it works: you create an object and give it a name. You set values, then you can use the commands (like save) which will call the API. Done and Done. Using this, you can store data offline, use relational data and the usual update/delete/edit. In the same basic fashion, you can work with image files, work with user data (including twitter/facebook auth and interaction) and more.

All in all, Parse is a simple and straightforward library with native APIs for Objective-C and Java for interaction. Currently in beta. Currently free, as in beer. (Note: as of March 26, Parse has announced they are out of Beta and live – you can still use it for free, but it will depend on the number of API calls you have.)

Usergrid

Usergrid is another cloud Paas that focuses on handling core data. Usergrid slightly differs as it is an open source stack that you can host on your own…or trust in Apigee to host it for you. Usergrid features the ability to manage users, devices and handle multiple applications. You can utilize activity streams and message queues for real-time data and save (and search) your data via a JSON-based data model.

Usergrid, like Parse, offers a REST API that you can interact with. there are a number of default data types including users, groups, activities, messages, assets, folders and events that you can save and add properties to, or you can create your own custom entities. What’s cool about Usergrid is that you really just need to save the JSON data to the database – it will handle parsing out the properties and storing it for you. Think NoSQL (actually it’s a MongoDB wrapper). If you want, you can access real-time analytics.

Also in beta. Also free.

Sencha.io

Sencha,io is yet another cloud-based PaaS, this one by the I-see-them-everywhere-now Sencha company. The idea is essentially the same as the Parse and Usergrid – provide a core API for users, messaging, data and deployment via the cloud. The key differentiator is that Sencha is a Javascript API. So we’re talking about HTML5 apps only. But the same general things apply – you can create and save custom objects, send items to the messaging queue (chat, collaboration, etc) and use the built in auth tools.

Yup, you guessed it. Beta. Free. For now.

Conclusion

It remains to be seen which of these platforms will pull out from the pack, but the mobile cloud Platform-as-a-service is most certainly something we are likely to hear more about in the future – thankfully. This was a key missing element in the mobile application development space and we eagerly await them to come out of beta – even if we do have to pay.

Reason #1: The right design

Depending on the size, digital agencies have at least one designer on staff. In the larger agency, they will have a creative director and a few designers. Whichever the case, there is oftentimes a definitive look that will come out in all Web sites and mobile apps they work on. And, worse, they may lack a stylistic approach and give you something sub-par.

Reason #2: The right technology

Agencies also generally have a very specific methodology for writing their applications. On the server, they may use a specific PHP framework, Ruby on Rails or a Java framework such as Grails. On the client it may be native development or they may use a cross-platform tool like Corona SDK, PhoneGap and Appcelerator Titanium. Whatever it is they use, that will also be what you use – no matter if it’s right for your project or not.

I can tell you from experience that this is not always the right choice. While at times this can be somewhat arbitrary, building in the wrong technology at the wrong time can cost you money down the road – or lead to a failure. Think Twitter’s original development in Ruby on Rails – it caused tons of problems and fail whales as they were reaching their tipping point. They eventually abandoned it for their core services. In addition, you can get caught in dying technologies (ahem…Adobe Flex and ColdFusion) where you can’t find developers in the future or stuck in massive licensing issues – or even worse open source licensing issues with copyleft license products that will force you to open source your system if you want to sell it.

The bottom line: you should use the right technology for you application, not just the technology that your agency prefers.

Reason #3: The right cost

While it varies from agencies to agencies, they generally will shoot for a 50% profit margin. In other words, for every $2 you spend, they will spend $1. This might even take into account their RETAIL rates for internal developers. The gist is that you are paying hand-over-fist. They always have a higher expense because they will need larger offices, employee benefits, assurance of income in down times and other expenses – these will all come out in the form of your bill.

The Falkon Productions Way

Falkon Productions is not a digital agency – we are an agile, ad hoc project facilitation and management company, which makes us more flexible and, we think, better able to get your project done in the right way, for the right place and the right budget.

Design: At Falkon Productions, we use the right designer for your project – if your project is heavy on interface, we will bring in User Experience experts to insure the usability of your app. If you have a specific design approach for your print or other media, we will make sure we find a designer with a compatible style. Want photo-real gaming interface? No problem. Want an invisible app experience. Check. We can even work with your designer.

Technology: We don’t have a favorite technology. We will find the right developer or development group for your company. For mobile, we can use HTML5, native or any of the proprietary cross-platform tools. On the server, we have worked with Java, PHP, Ruby on Rails and others. We work in the right technology for your application, not the right technology for our company.

Cost: We can do what you want in concordance with what you can afford. We can find local developers to facilitate better communication or we can help coordinate with outsource companies in places (all of which we have worked with successfully) in India, Russia or the Ukraine. Even Moldova.