We’ve built a few apps in our time, and we’d like to help you build yours. Before we begin, let’s go over a few basics.
First and foremost, does your app solve a genuine problem for its intended users? We love digging into tough problems and inventing creative solutions. But if the problem isn’t there in the first place, no amount of fancy design and engineering is going to make this app useful or successful.
Do you have a way to acquire users? In other words, do you have a marketing strategy, plan, and budget? Users won’t magically show up at your doorstep with their credit cards in hand.
Next, does the math work? Assuming you’ve attracted lots of users to your app, do the math, and make sure you can fund it and stick with it. Hint: you will need a lot more money to get to profitability than you think you do. Your budget should assume lots more marketing and advertising than you expect, a maintenance budget, and budget for all the features your users will clamor for once you launch.
Finally, are you in it for the long haul? No, are you really? Success is a long and winding path. You will take many wrong turns along the way. If you stick with it, you might — just might — get there.
Great, you’re not deterred yet? We’re glad you’re still with us. Now, let’s get down to business.
Here’s what we believe:
- Architecture is more important than any given technology or programming language. “Architecture” refers to the way in which the components of your software are put together. Or, in tech speak, what set of tradeoffs do we make? Do we prioritize performance, future expansion, maintainability, administrative control — or do we just let the developers go nuts and make everything ridiculously complex?
- Pick the right tool. The question of “Windows or Linux?” is so yesterday. It’s irrelevant in today’s cloud-based world, where you can spin up a server in seconds with the click of a button. With a solid architecture and understanding of what we’re going to build, we can pick the right tool for the job. Ever try to hammer in a nail with a wrench? It’s dumb, right? Software is pretty much the same way. Don’t try to make an Ajax interface with ASP.NET Web Forms and Flash.
- Planning is hard work. It saves time. It saves money. So, do it. Our fearless leader, Ben, likes to say that “one hour of planning saves 8 hours of banging your head against the wall.” Technical requirements, wireframes, user interaction diagrams, sequence diagrams, etc.
- Make decisions at the last responsible moment. Every project consists of thousands of decisions, large and small. What code structure should we use here? What library should we use for this popup? What database design should we use? We don’t hesitate to wait as long as possible when making the big decisions — as long as is responsible — holding out for as much information as possible. Sound reckless? It is. But it’s also led to some of the best decisions we’ve ever made, that have literally meant the difference between success and failure on major projects.
- Launch quickly. You may have heard of MVP (minimally viable product) before. It’s easy to say, it’s easy to understand, but it’s hard to actually do it. We will push you to launch as early as possible, though you likely will seek perfection. We believe that it’s more important to start getting real-world feedback and testing assumptions as early as possible, and then adjust as needed.
- Failure is not an option. The sad fact is that many (if not most) large software projects fail, as our federal government learned recently with the botched roll-out of the healthcare website. We can tell you all the reasons we don’t fail at projects, detail our exceptional process, or point out all of our success stories, but the simple fact is this: the viability of our business depends on the success of the projects we work on, and we’ve never turned away a complicated project, large or small. In fact, we don’t just survive — we thrive on challenges. Not so for some of competitors: several well-known firms frequently refer clients to us because their projects are too hard for them. (Well, to their credit, at least they know what they can’t do and are honest enough to admit it.)
- Don’t over-engineer or over-complicate. Keep it simple. Think you can manage a bunch of crazy smart engineers yourself? Sure, go ahead and try. Let them create elaborate, unmaintainable, insanely complex — yet staggeringly beautiful — code. Let them miss their deadlines by months and blow your budget out of the water. Let’s just see if that leads to a successful, maintainable, and scalable platform.
- Test like there is no tomorrow. Ben likes to say that he can break anything. This is exactly the kind of person you want working on your software. Make sure that Ben has broken everything before your users get a crack at it. Seriously, though, we know how to create the right types of tests for different types of software, from automated unit tests to performance tests. We sometimes write software just to test our software — that’s how crazy we are about testing.
- Proactively monitor. Did we mention that there will be bugs, no matter what? Well, there will be. Don’t wait for your users to tell you the software is slow and buggy. You should know before they are bothered enough by it to tell you. And, by the time they contact you, you should already be working on the fix. We use tools to monitor applications at all levels to quickly diagnose and find bugs and improve performance.
- Plan for scalability. Our hosting vendor, Rackspace, likes to say that hardware is less expensive than software developers. We can’t argue with that, but we’d like to point out to them that it’s pretty hard to throw hardware at a problem when there is a bottleneck. We make sure to identify those ahead of time so that you can, indeed, “throw hardware at it” when you’re ready to scale.