Concluding the 14 Day App Challenge and 3 of My Biggest Mistakes

My 14 day app challenge ended almost 14 days ago, and I’m just getting around to blogging about the journey, sorry :(. I promise, I haven’t made any structural changes in over 14 days, but I have done some user testing which led to some copy and minor design changes on the splash page. In this post I will try to summarize some of the web apps features, but even more importantly I will try outline the biggest mistakes I made during this challenge.

Here’s what I got:

The name of the app is Cheerful. Cheerful, simply put, is a responsive web application that allows non-profit organizations to accept and track donations both online and offline.

The Problem I’m Attempting to Solve:

Something as simple as e-giving for non-profits, in 2013 is still relegated to a few very expensive applications and PayPal. The expensive applications are bloated, have a terrible end user experience and are in most cases very difficult to setup (some even requiring setup fees). PayPal, which by far still seems to be the market leader in this industry, requires you to maintain a separate bank account, has limited reporting features, doesn’t allow categorized donations, and has a very disjointed user experience.

The Solution

Non-profit organizations come to cheerfulapp.com,  create an account and instantly start collecting donations by linking to or embedding code into their website. Simple right? Donors can opt into reoccurring donations and will be sent an email receipt after every successful and non-successful transaction.
Donations are reported using cool graphs showing overall total giving for a seven day period. Organizations can see a specific donor’s giving report, and donors can be grouped together and tracked as well. Cheerful also tracks offline giving. This allows organizations to manually record and track the who, when, and how much for all donations made. There’s other features like SSL encryption, emailed reports, and a bunch of stuff that I don’t want to waste this blog discussing, instead I want to walk you through three of the biggest mistakes I made when building Cheerful.

1. Too Many Features
One of the biggest hopes when building this application under the constraints of the 14 day app challenge was that it would limit feature creep. Boy was I wrong! Instead the 14 day app challenge quickly became more about my coding prowess and less about filling a need and creating a great product.

I started building with 10 prioritized features in mind. My though was that I would start with a prioritized wish list of features, push as hard as I can to build each one, and see where I landed. The problem with that was that: 1) it makes the assumption that I know which features are the most important and 2) it  increases the amount of features I would have to support out of the gate, 3) I doesn’t allow me time to really  polish the most important feature. Instead, I should have started with one main feature, allowing users to donate online, and a splash page outlining that one feature (no pricing).

2. Wasted Time on Pricing and Signup Page
I spent way too much time trying outline my core features and even more time trying to figure out how to charge for them. This was a complete waste of time. First off, I’m not sure which features are the most important, so there’s really no way for me to associate a value for each. Instead, my focus should have been on building out that one feature, and giving it away to a few organizations (no more than you can truly support). I should have leverage these users to  answer those most critical questions about features, design, and usage via emails and user testing.

3. Should Have Blogged While Building
Looking back I should have been blogging while I built this application. My biggest mistakes became the most evident when I started putting this post together. Writing as you build your application would have done three very important things: 1)allowed me to verbalize each feature, hopefully allowing me to draw the conclusion that I was biting off too much. 2) it would have allowed me to post this as soon as I completed the challenge instead of letting life get in the way  3) I could have leveraged the small but intelligent and engaged community I’ve built here to help me find the right organization to help me flesh out this application, and hopefully answer some of these questions.

Next Steps
Taking what I’ve learned during the past few weeks, I will be spending the next few days honing in on what I believe is the sites most important features, and creating a simple landing page that outlines them (no pricing). I will then to find a few (I’m thinking 2) organizations to beta test the application for me. And I promise to blog through my progress.

How I use Trello to Stay Organized

The hardest thing to do when building a product in 14 days is staying organized. This is especially difficult when you lack organization skills, and suffer from product ADD. So to help me stay on task I’ve chosen Trello. Trello is an online “board” that simply allows you to drag and drop tasks into the columns you specify. I use it as a very simplified version of a Kanban board. Sure there’s hundreds of agile development tools that are more robust and feature rich: Pivotal Tracker, Assembla, Basecamp, just to name a few, but I’ve found that the simplicity of Trello is just enough to keep me on task while not distracting me with yet another tool.

How I use Trello:

I don’t do a whole lot of planning prior to coding. This is especially tough when you’ve given yourself a 14 day deadline. But luckily, over time, I’ve learned what components and parts are needed for building a sites. Trello is a great tool for planning sprints, but in this case (and in most cases) I only use it to remind myself of the priorities and help me remember where I left off. So here’s I how I have my Trello Board broken up.

Commit App Roadmap | Trello

My board is broken up into 4 lists. To Do, Doing, Done, Bugs.

  • To do – Includes the cards that I haven’t done yet. They’re normally sorted in priority order with the highest priority cards at the top.
  • Doing – Includes the card that I’m currently working. You can only work on one task at a time so, in my case there’s only one card in my todo list as any given time. I sometimes switch between tasks before they’re completed, but I’m never working on two or more task at the same time, so what I try to do is is use Trello’s labeling feature to color cards (usually yellow) that I’m currently working on but haven’t yet completed.
  • Done – Includes the cards that have been completed.
  • Bugs – Includes that cards of bugs found.

Seasoned developers are probably asking where’s your QA/Testing column? To which I would say, shut up and mind your business (just kindling). I’m continually testing as I develop, but as one person / one resource development arm you have to do your best to be as thorough as possible, and be nimble enough to quickly respond and fix bugs as the sprout up. Thus the bug column.

How I create cards:

Some development shops spend days sometime weeks, planning. This time is usually spent building user stories or use cases with acceptance criterion, wire frames based on these user stories, visual designs based on the wireframes and then tasks based on everything. But like I mentioned before, “ain’t nobody got time for that”. So what I do is the abridge version. I jump right into creating a list of task and prioritizing them. This usually takes about 30 – 40 minutes depending on the complexity of the of the project, and the process usually looks like me with a Latte and my feet on my desk asking myself what are the most important features needed for launch? Once I have the key features in mind, I create the supporting cards. My cards are usually structure just like my controllers and look a little like this.

Card Examples:

CRUD Members:

Attributes

  • Email
  • First Name
  • Last name
  • Password
  • Rights

CRUD Organization

Attributes

  • Organization Name
  • EIN
  • Subdomain

*CRUD = Create, Read (View), Update, and Delete
*Attributes = the fields I need to capture.

I told you my cards were really broad but this helps me keep my focus on the feature and not on the task. It also helps me from spending too much time moving cards around in Trello.

Hope this was helpful. Feel free to share your thoughts and how you plan.

 


 

The Web App Challenge: Launch in 14 Days

The last three  years has been a world-wind adventure both personally and professionally. I quit my stable safe job, started consulting, had my first child, landed some amazing clients, help create some amazing products, and now lead an amazing team of developers at Interactive One (in that order). Needless to say, I’ve had a crash course in time life management, product design, development, and marketing. Now, for the first time in about 3 years I finally feel like I’ve got my bearings. I’ve done a really good job balancing my personal and professional responsibilities, while still finding time to volunteer. With that said, its high time for me to get outside of my box and push myself to the limit, and that’s where The Web App Challenge comes in.

I guess I could slowly develop a product with no pressure, over the next few months, but one of the most important lessons I’ve learned over the past 3 years is there’s no better motivation to execute than a tight deadline. So, I’m taking a page from Nathan Barry’s Web App Challenge, and a little motivation/inspiration from Drew Wilson, and Josh Long’s book Execute, and declaring to the world that I’m launching something in 14 days.

Here are the restrictions of the challenge:

  • Back-end code 100% developed by me 🙂
  • $100 launch budget (for advertising, design, 3rd party APIs, and server costs – Amazon AWS)
  • Can only work on the project during the weekend and after work (7:00PM).
  • Needs to be launch ready with at least one client in 14 days!

Sounds impossible…. right? Well, here’s what I have working in my favor, that  I think will make things a little easier :

  • I already have a fully fleshed out idea. My thoughts are to build a product for something I know well. 
  • I’ve already got a name, so that should take some of the pressure off.
  • I’m using the same stack that I’ve been using for the past 7 years (PHP, Code Igniter, MYSQL).
  • I’m allowed to recycle old  libraries. (For user registration,  authentication, and caching).
  • Allowed to leverage APIs where possible.

I will be completely transparent, chronicling the process, here on my blog, with special bonus materials coming to the wonderful people subscribed to my newsletter.

Wish me luck and lets get it!!