Shipping a product in 2 weeks

When you get an idea for a new application, it’s an amazing feeling. You start thinking about all of the cool features it can have, how it’s going to look and feel, and, ultimately, how successful it is going to be. Hands down, without a doubt, its one of the best parts of being a software developer.

However, once you come down from that high, the businessman in you begins to emerge. You start to think about the work you’ve got ahead of you, how you’re going to get the app in front of people, how much you’re going to charge for it… the list goes on.

For this article, I’d like to give you a behind the scenes look at the creation of Completable, a product that Floyd and I created in just over 2 weeks, from concept to deploying a working prototype.

Getting Started: Idea Conception

Between Floyd and myself, we’ve done a great deal on contract work outside of AbleBots. One thing we’ve noticed time and time again, is that the process of getting your work approved by your clients always seems to break down. There is so much back-and-forth between your client(s), over different medium like email and phone, that it doesn’t take long before you are overwhelmed and unsure of where the project stands. We’ve tried different approaches, but the results always remained the same. After brainstorming the problem, Floyd and I realized the problem has to do, mainly, with the way your clients submit their feedback and how we try to organize it. Our goal with Completable was to make an efficient process for not only the collection of feedback, but the analysis afterwards.

Survey your potential customers

At AbleBots, we are in the business of building great software and getting it in the hands of customers. However, we will only do the former if we are sure the later is possible. Now, we come up with app ideas all the time. If we built them all, some might succeed, but all would take time and resources to build, successful or not. In a small business like ours, it’s important that we use or resources wisely. That’s why, before we break ground on any product, we do our homework. We get our idea in front of potential customers and see what they think of the idea. In our case, our potentials were web designers, developers, and project managers. Here is a quick list of questions we asked them (generalized so you can re-use them):

  • Has this been a problem for you?
  • Could you see our solution solving that problem?
  • Can you see yourself using our solution?
  • How much would you be comfortable paying for our solution?

The feedback we received was pretty convincing: almost everyone we asked were experiencing the exact same problems and found that Completable would be a great tool to solve it, that they would pay to use. Floyd and I soon realized, this is something we need to pursue.


Building your prototype

So here we are, day one of the build out. Up until this point, we’ve conceptualized some rough ideas on how we see the app working, and we’ve got it in front of enough people where we think the app would be worth taking on.

An important goal that Floyd and I always keep in mind, at this stage, is that we are simply building out a prototype: it’s not going to be perfect, it’s not going to do everything we could ever want it to do. Just enough to see if people will take to it. There will be plenty of room for growth and improvement if and when we get customers using it, because they will provide plenty of feedback… customers are good like that. While working, our goal is always:

“Finish a barebones proof-of-concept as quickly as possible.”

  1. Wireframing: Day 1-2

    It’s no secret we love Balsamiq for documenting our features. You should too; the wire-framing process is all about brainstorming functionality, seeing how it will all play out, and identifying potential gotchas in logic. Floyd and I spend no more than 2 days wireframing: one to layout some functionality, and the second to sleep on it and see what a fresh set of eyes reveal. We make it a priority to only include the leanest functionality for seeing out the initial goal of the app.

 

  1. Design in the browser: Day 3*

    In 2009, I attended An Event Apart in Chicago, and Andy Clarke gave a talk about “designing in the browser.” I remember thinking, “That works for basic web sites, but not rich web applications.” That’s crap – it applies even more to web apps. There is way more interactivity in web apps, which means more things Photoshop can’t do for you. You’ll understand the feel of your app quicker when you build it in the browser. I spent about a half a day building out the core layout for the app, using Twitter’s Bootstrap to help throw up the scaffolding and aesthetics.

    I said the design took a day, with an asterisk, because the design is a moving target. Since we did not spend time mocking out formal layouts, you stay agile as the app grows, but have to budget a little time here and there re-working elements of the layout for the greater good of the app.

  2. Build-out: Day 4-10

    The next week, we work straight through the weekend and well into the wee-hours of the morning. It’s actually quite easy to do because, at this point, we are riding a pretty big wave of adrenaline.

    While I was laying the foundation over the past couple of days, Floyd was mapping out some of the back-end architecture to power Completable. We used Rails as our backend framework, so Floyd was building out models and began testing the basics like transitioning the status of a Goal, and building the review teams. Now that I’ve laid the foundation, Floyd began setting up simple front-end hooks to his functionality, and it’s my responsibility to go in and set them in place the best I can. For instance, Floyd will build a barebones form for creating a project, and I will follow behind him laying the elements out nicely and adding little bits of JavaScript to help the interaction along. This system works quite well for us, and we’ve become quite good at working this way. We use Code Spaces to organize the work items. Floyd will assign his items to me when it is ready for me to sand and polish while he moves on to the next item.

  3. Quality Control: 11-12 Days

    By now, we have a working prototype of Completable, and we will spend the next couple of days switching gears and taking on the customer’s role. We hammer on the app, finding bugs and patching them with tests along the way. We take a look at areas that may be confusing, and jot down notes on what we can do to improve them.

    Pro Tip

    Ask someone like your significant other, family member or roommate to test drive the app. Watch what they find easy, and what they find confusing. Make it a goal to improve areas that cause them grief. We do this all the time.

  4. Public-facing Design: Day 13

    At this point, we are 12 days into building Completable: we’ve got a working prototype, and some notes on things that can be tightened up. Floyd and I spent the morning discussing which items we wanted to address for the prototype and which ones we wanted to hold off for phase two, and we organized them in Code Spaces.

    We agreed that Floyd will jump back into the app and address the pre-launch items, while I would build out a simple public-facing website for new visitors. The same rules apply here: just build a front-end good enough to give the app a professional look and enable visitors to sign up. We will build a better site after launch, but since we will be driving most of the traffic to the site with direct contact, we know visitors will have enough context once they are at the site. For this front end, we just wanted to make it as easy as possible for people to start using your new prototype. That meant putting the signup for right on the homepage. We also removed some extra fields that you can set once you’re in the app, like your timezone and language.

  5. Deployment – Day 14*

    When you are finished building your prototype, deploy it. Many times when working on the first release of a really big project, you get this anxiety about “the launch.” You want it to go well, you want everything to work perfectly, you don’t want your app to crash. We’ll, since we stuck to our objective about just building a simple prototype, we can almost certainly guarantee all of that is going to happen – after all, we built it in 2 weeks. We aren’t trying to launch perfection; we’re trying to get people’s feedback, to hear if people like it, to hear what they don’t like, and what they’d like to see added or improved.

    Again, the asterisk. While we are deploying on day 14, we’ve actually started this process during the end of our development sprint. We set up an EC2 instance, set up our deployment scripts and we pushing builds to make sure all of the tools the app requires were ready to go for launch.

    Throughout our deployment day, we will pop in and out of using the app to make sure everything is working as planned. We make sure all of our monitoring metrics are set properly and ensure the box is running efficiently. We’ll also let some trusted users in just to kick the tires.

    If all goes well, we’ll give the app another walk-through and ensure all the tests are passing. With that, we were able to sit back and reflect on the fruits of our labor: we are able to start getting Completable in front of people first thing in the morning.


Prologue: What now?

After the launch, we do our best to promote Completable. Before we broke ground, we’ve taken some time to think about our potential market. It is now time to get the product in front of them – and there are many ways to do that besides paid advertisements. Some things we like to do are:

  • Directly contact people we know that may be interested in this product: give a call or email to friends or colleagues. The one major benefit we have with them that we won’t have with others: brand recognition. They know us, and therefore, they will have trust in our product.
  • Post on social networks and forums where people who we think are in our market frequent.
  • Leverage our own networks like Facebook and Twitter: put out posts about Completable, spread some knowledge around.
  • We write blog posts about our experience building Completable. That one is apparently working, isn’t it? :)

The beauty about this two week process is that there wasn’t a huge up-front investment: no upfront costs, some late nights, but that’s it. The side effect is that it would easy to walk away from the project, and that’s something you need to be very realistic about.

Sometimes products just don’t take to the market. It doesn’t mean it’s a bad product, it doesn’t mean you didn’t do a good job marketing it, and it doesn’t mean that someone else might make the same app and it could be a huge success. That’s the beauty of a down-and-dirty prototype. If you would have invested 6 months or more on a product that you feel you have crafted meticulously, just to have a less than stellar response, it’d be hard to walk away. You’ve invested way too much into it.

To sum it up, if you have a great idea, you should definitely jump on it and ride that wave of emotion out. However, remember your objective: finish a barebones proof-of-concept as quickly as possible. Completable should be proof that you can very realistically build out a prototype for your ideas in a very little amount of time.

Leave a Reply

*