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.