OK, How to Start!

As a quick follow-up to the “How to Start Up” post, here is a pragmatic list of tools, tried and true via 2 recent projects of mine, and at least one more upcoming (which will also succeed ;)). The question I’m answering, of course, is: “what tools to use to bootstrap development on the cheap, and get yourself something launched with minimal headache and maximal features and reliability?” This is by no means a recipe for success or a religious treatise on how things must be done. It is a (hopefully) practical guide to what has worked for me in the context of real world “How to Start Up.” None of it substitutes for good engineering and smart entrepreneur-ing.

  • Linux: goes without saying. Oops, I’ve said it! I like deploying and developing on the same Linux distro, and for now that’s Ubuntu server. I find Aptitude to be the fastest, easiest package management system around. It does what it needs to and stays out of my way.
  • Rails: Yay, Ruby on Rails! Everyone loves it, right? It must be the shit! Well, feel free to join the pile-on. For a rapid, well-organized Web framework, it’s my choice right now, and I am a relative newcomer, still learning. I do love Ruby to get things done quickly and flexibly, and Rails is a natural extension.
  • Ruby: despite performance limitations, and single-threadedness for now, Ruby is the perfect “glue” code. If you need a server prototype or something asynchronous for your Web app, it’s a fine choice to start. For scripting and automating tasks, Ruby is right on. After all, that’s really what it was intended for.
  • Java: For any sort of real server heavy-lifting, Java and it’s infinite world of libraries and components are the obvious choice. All the complexity that you don’t need or want for rapid development of a Web app is much more palatable in this context because the benefits of performance, type-safety, threading, and dogmatic separation of concerns are well worth it. Lucene and Hadoop are great examples of very active projects with a lot of momentum, wide applicability, and lots and lots of good old Java. A requirement in my toolbelt.
  • Netbeans: I’ve done battle with IDE’s over the years. Even pitted one against the other. I’m fickle, easily distracted, and never satisfied when it comes to IDE’s. Right now I find Netbeans to be a clear choice for having struck the near-perfect balance between responsiveness, sophisticated editing, plugin-friendliness, and applicability for Ruby, Rails, and Java work. It generally stays out of the way but there is always something useful still to learn, and a zillion timesavers built by folks who understand what frustrates me!
  • Postgres: Another natural choice, given the Prototype Trap, and assuming you need a realtional DB. It’s very likely that you do, but not a given. PostgreSQL is proven to scale and cluster. Databases are quirky by definition, so putting your time into learning one that offers a lot of mileage is the name of the game. And, when you’ve got your funding you will have a relatively easy time finding a PostgreSQL DBA to hire for your team. Oh yes, and I love PGAdminIII, despite its unfortunately uninspired name.
  • Amazon EC2: I’m new to EC2, but pretty solidly behind it. At Digital Railroad I had the opportunity to speak with the EC2 folks and a number of competitors in varyinig degrees of depth. Remote virtualization is very clearly the way to deploy in the early stages, and depending on the application and resource needs may be right for the long haul. In the case of a current project, I was able to very quickly find a suitable base Ubuntu Server image, bring it up, and customize it appropriately. I’m a sucker for slick tools, and I must say this sucked me in further: ElasticFox.
  • 16bugs: Even if there are only 2 of you on the project, paper and todo.txt files will get old (and useless) quickly. Task and bug tracking are a must, and both are decently done and free at 16bugs.com. Don’t expect Bugzilla or JIRA-level workflow. Simplicity and just enough to do the job is what 16bugs is for, and it’s working well for our tiny team.
  • Yammer: This one is growing on me. While I don’t think Yammer is an essential tool, it does accomplish some things for small, geographically distributed teams. Things that aren’t obviated by project tools, IM, and email. My advice is to try it on a real project. As they say, your mileage may vary.

So there you have it. Not an exhaustive list, by any measure, but perhaps the means to get started on a lean, mean trajectory. It’s working for me.

iPhone Sync with GCal

iPhoners: if you aren’t using Nuevasync, you should check it out. The lack of over-the-air sync to Google calendar has always been a near deal-killer for me, but Nuevasync works. It’s still beta, and they’ll happily send you your password in plaintext (ouch!) but it’s a clever hack using Apples iPhone OS Exchange ActiveSync support that solves a big problem. Enjoy: http://nuevasync.com

How to Start Up

With the endless proclamations of the startup funding apocalypse inundating all our channels, it might be useful to consider how to start up a software thing and do it well on the cheap. I’m not talking about using the “cloud” or how you ought to look at open source… there’s plenty written about those and they pretty much fall into the “duh” category.

This is as good as any characterization of what we are facing. It’s not good. But there really is a lot of potential opportunity, heightened by the dearth of folks who can comfortably funnel some personal money into a project. Innovation marches on, and the gaps to fill with smart products, quickly developed, are accumulating at just about the normal rate. A project spun up with truly minimal cash and a real market, not a speculative one, will succeed if anything can in the next 12 to 24 months.

In the past couple of months, I have had the opportunity to advise and look at a number of Web/software technology ventures that meet these criteria, but are crippled, or doomed, because they just don’t know how to get started efficiently and set the stage for great things.  Here is some the advice I have given and thoughts that have come to mind of late.

  1. The Prototype Trap
    Beware of building a throwaway prototype, something that appears to work but really is nothing more than carefully propped-up demoware. In the good old days, such a diorama might have raised funds, but building it cost entrepreneurs money and served as nothing more than a starting point for spec’ing the real product. Don’t build a prototype; build an alpha, and define “alpha” in terms that accomplish your goals.  It’s infinitely better to choose platform(s), language(s), deployment environment, and base features than to build garbage demoware. The inital results won’t be as pretty as the polished garbage, but when you see something working, it’s really working. You’re team has identified real risks and pitfalls rather than emptily theorizing about real costs and unknowns.
  2. Hire/Partner with a Leader
    If you aren’t technical, or aren’t technical enough, hire someone who is. If you are human like me and need an invested collaborator, find that person as one of your primary efforts. Don’t accept that you tech lead has to be part of your outsourcer’s organization or that you, the most accomplished well-connected business professional that you are, can manage the risk yourself. Find a technical collaborator who grooves with your vision and working style. Offer equity for participation, hire a consultant who has a real interest in what you are doing and who will come aboard, or best of all spend on this full time hire, offer equity, and build a real partnership for execution. Spend more than 50% of you start-up time and energy identifying and exchanging ideas with this person. It is an obvious and critical investment that will yield staggeringly good returns.
  3. Start Microscopic
    Don’t bite off more than you can code! Sounds obvious, but it’s such a common mistake. If you start by identifying the bare minimum functional requirements to demonstrate your mission with real, working code you are comfortable handing over to alpha users and potential investors, and potential partners and staff and build nothing more… well, that’s really the start up app holy grail. Few achieve it, believe me. I think the tendency is to fail to find the perfect mix of focus and flexibility. If a project takes in the neighborhood of a month to implement, chances are very high that during that time the team will learn substantially more about the problem, the market, potential users, and competition that changes will happen. I’ve got some rules of thumb for this, and I will share them in a follow-up post. I know; you’d think this is common sense but I can assure you that very smart, savvy people with excellent ideas fall into all of the traps I’m writing about.
  4. Interest Alignment
    Regardless of who is building the alpha, make sure your respective interests are well-aligned. Your technical leader will push on topics such as framework choices, development environment, source control, and implementation time. Equally important is User Experience and performance, which will float or sink the idea in an instant on the monitor of your first alpha user! I like to set milestones that are small and very well-understood, and use them as checkpoints for Interest Alignment. Are the tools and framework choices holding up? What hackery has taken place to build this iteration, and is it something I want to inherit and support in beta and beyond? What code or approach was “borrowed” from another project? Are the resources still the best possible and invested, or are we slipping to the back burner? What User Ex compromises have taken place or are about to take place? These questions and more are relevant when implementation is done by outsourcees, contractors, and even new employees. And, one immutable fact is that if you are outsourcing, your outsourced team has fundamentally different interests than your own. The closest those interests align is in the goal of having your business survive. But, you need to do much more to lead the market and innovate, and they need you to survive and continue providing a steady flow of income.
  5. Alpha Wise and Beta Foolish
    Go into it assuming you are going to succeed, where success here is defined as moving from Alpha to Beta and eventual launch with real users and enough funding to do it all justice while not starving. Getting apps to market, and a large component of the art of development, is compromise. Finding the optimal trade-offs as goals change and timelines compress is not scientific, despite what a lot of books, brochures, and coursework purport! You often have much more wiggle room with the alpha time line than with subsequent ones. I always try to use this to advantage, insisting on building enough of a foundation to support what we imagine will subsequently sit atop it all. It’s very important not to shortchange your initial implementation and have the confidence to build solidly. There will be compromise, but don’t rush these decisions; a quicker-to-build, shaky alpha will always cost more to revisit as you are sprinting toward beta and launch than the cost of building solid and letting the foundation have some settle time in alpha.
  6. Outsourcing: The Glass is Half Full and Evaporation
    Assume the worst when you are outsourcing. There are many, many strategies for managing outsourced engagements, but the best is to assume, at the outset, a pessimistic disposition. If things fail in some way, you will be prepared to minimize and deal with the consequences. Competent outsourcing managers and teams expect this, and it has little to do with your confidence in them, or their ability to earn your trust. Since Interest Alignment is implicitly handicapped when outsourcing, both parties must make the most of it. Excuse this analogy, but you are a client, and they are the server. Code defensively! Extending the glass analogy, I like the term ‘Evaporation’ to describe what happens when that half-full glass sits around exposed to natural factors. Essentially, if you don’t put effort into ensuring a quality product via testing, frequent contact and brainstorming, and code inspection done in-house, you face Evaporation. Over time, that half-full glass get emptier, and emptier.
  7. Outsourcing: It’s Your Source Code
    Always have access to your source code and documentation. Ensure that code builds and works on your hardware and subject it to your high standards. Know the dependencies yourself, and ensure that dependency bloat doesn’t occur on your watch.  The unthinkable extreme case of source code kidnapping happens more often than most people realize.  But death by a thousand cuts can occur when your team is not vigilant about quality.  Your app will bleed to death from a zillion cut corners. Keep an eye on updates every day.  After all, this is why you hired or partnered up with a rockstar technical leader.
  8. Live with It!
    Well before real users assail your system, make sure you and your team understand all of the implications of running it. How many machines or could slices do you really need? Does the code recover from failure? Does it care? What registers as a catastrophic crap-out and waking someone up at 3 am, and who exactly gets that call? Rock sold stability is not expected in alpha, after all that’s why it’s alpha. But if you aim for better and achieve it, you will stand out. Live with the system you are deploying for a week before unleashing it. It will probably result in some work and living with an improved system for another week, but the time burned is another kind of important investment you will not possibly regret.

Starting things up isn’t easy or straightforward. But it ought to be fun, predictable, and inexpensive.