The Rails Rumble Finalist!

The Rails Rumble finalists have been announced.  These 22 applications have been selected by the Rails Rumble organizers and an expert panel from among 159 qualifying and will continue onto the public voting round.  Unfortunately, AffiliApp was not one of the finalist. But that does not mean the end for it.  This is just the beginning!  Read on.

High Quality Apps

The overall performance and quality of Rails Rumble 2009 apps is a leap forward from those in 2008.  2008 say some good apps.  2009 saw a few great apps and I’d say over 100 very well done apps.  Teams were prepared this year like never before.  And that’s great to see.

Calling all Voters!

The Rails Rumble is now onto the Public Voting stage.  This phase of Rails Rumble voting goes on only until 8/29, so please sign up today and take a look through some of this year’s best apps.  Anyone can sign up and vote. The sign up form is here: http://r09.railsrumble.com/login and the list of apps to vote on is here: http://r09.railsrumble.com/entries.

What’s next for AffiliApp?

I have been working this week on continued development of AffiliApp.  Initial response from the community has been more than I could have imagined. Already several folks have contacted me asking to use the product to set up referral programs for their apps.  Discussions with these folks have provided valuable feedback to direct the next steps of development.

Based on requests and feedback from judges and potential customers, I am currently working on the API and a gem.  We will use the API and gem in our own products (including http://playbookiq.com) first to shake them out.  Once I have given them a good real-life work out ourselves, I will document the API and open source the gem.  This development will make it as simple as possible for web app developers to set up an affiliate program to promote traffic to their product.

Spreedly

I simply have to put in another hearty recommendation for Spreedly as a billing platform for web app developers.  Their API is at once powerful and simple.  I used it extensively in the development of AffiliApp as a way to quickly demonstrate that payment transactions would be credited to the correct affiliate.  I also use Spreedly as the billing platform for AffiliApp, the place for my subscribers to pay.  For this, you can either present their white-labeled subscription forms to your subscribers or make Spreedly completely transparent via the API (with the API, of course, you’d be responsible for basic security measures like utilizing SSL and ensuring no sensitive data is logged, etc.).

To follow developments, please subscribe to this blog or follow @smeade and @affiliapp.

AffiliaApp Screencast #3 – Revenue and Commissions

Showing revenue and commission tracking in AffiliApp.com. When you set up your Spreedly API token in AffiliApp, transactions are automatically identified and applied to the referring affiliate. This works even with automated recurring transactions. If you do not use Spreedly, you can still track referrals and subscribers and they too will be associated with the referring affiliate.

http://screenr.com/Content/assets/screenr_0817090731.swf

AffiliApp Screencast #2

Showing referrals and subscription tracking in AffiliApp.com.

http://screenr.com/Content/assets/screenr_0817090731.swf

AffiliApp screencast

AffiliApp introduction video.

http://screenr.com/Content/assets/screenr_0817090731.swf

Rails Rumble

2009 Rails Rumble Reflections

Note: if you are looking for the screen casts, you can find them here: http://screenr.com/user/smeade

That 48 hours went fast!  After producing BidBuildBill.com last year and finishing a respectful #22 on the leaderboard, I aimed this year’s entry at web application developers with AffiliApp, the easiest way to add an affiliate program to your web app.

The Idea

This idea came out my unsuccessful experience looking for a good affiliate program to use in promoting PlaybookIQ.  After finding none that felt right, I decided to design and develop affiliate features myself.  I could have simply added the affiliate management features to my existing app, but with Rails Rumble right around the corner and with the idea that it could be useful to lots of web app owners, I decided to develop affiliate management as a separate project which we now know as AffiliApp, my Rails Rumble 2009 entry.

My Reflections and Impressions of the Rumble

What Went Right
Rails Rumble Organizers and Linode
The organization and planning this year was top notch. The entire Rails Rumble org did a great job. Linodes booted up straight away. The Rumble team was always present on irc and Tender app to answer any questions and clarify rules. They gave plenty of advanced warning on how they see the administrative parts of the Rumble playing out. Much appreciated.

Picked a Good Idea
I was glad to have some idea of what I was going to do ahead of the Rumble. As I discussed in previous blog posts (see links at bottom), the idea I had is something that I am going to use in Real Life. I think it has value for others as well and plan to continue to build it out.

Ensured a Good Development Environment
I was also glad to have done Rails deployments to Linode previously. Though deploying is very easy, I am not a sys-admin. So, I practiced ahead of time with a Linode slice an my GitHub account. This way I knew exactly how to boot and how to configure the linode and ensured my local environment was cap and deprec ready. Recommendation to all contestants: if you have not deployed a Rails app to a VPS before, do so as practice before the competition or have a team member that has. This will help get your local and VPS environment issues out of the way early.

What Could Have Gone Better
Get More Rest
At some point of the weekend, I believe it was SuttoL who said “A tired programmer is a dumb programmer”. So true. Rest up for this, you’ll need it. And take some breaks during the competition as well.

Scope Down
As I mentioned in an earlier blog post, I had already cut my feature list in half, then in half again. I should have cut it in half and half even again. I am very happy with how the app turned out, so it’s not that. It’s just that with a much smaller feature list, I simply would have had less stress and felt less rushed, which would result in little higher touches of quality throughout the app.

Design First
I did not take much time before the Rumble to lay out the application design. Both UI and model designs were started just about when the opening bell rang Friday night. Note for next year: go into it with a clear definition of the app design. Again, I don’t think the app suffered for it. I do think it would have been a more fun experience had I walked into with design ideas in hand.

Will I Do it Again Next Year?
Definately, Yes! But, I think next year it would be fun to get a team together to Rumble. If anyone’s interested in joining a Denver area team for the next one, let me know.  In the meantime, I’ve got 48 hours of email, tweets, and TechCrunch to catch up with.  On second thought, no, I’m going to get away from the keyboard now and hang out with the family instead!

Links:
http://affiliapp.com
http://affiliapp_support.tenderapp.com/
http://screenr.com/user/smeade

Pre-Rumble Blog Posts:
What Rails Rumble and TechStars Have in Common (Besides @andrewhyde)
My App Takes the Sleaze Off (subtitled: Getting Real with Rails Rumble)
Whats the Big Idea
Ready to Rumble

Ready to Rumble

The Kitchen Sink

When you try to build this:

photo credit: avidtile

you too often end up with this:

photo credit: DieselDemon

when this would have been just great:

photo credit: Mr. T in DC

It should be as quick and simple as possible for judges to get to the core of your app.

Stick to the Essentials

I’m continuing my walk through Getting Real, the very unofficial guide to Rails Rumble success.  In previous posts I identified a real problem to solve and picked a fight.  Now, it’s time for me to consider Underdo Your Competition and to design Half, Not Half-Assed.

I took my initial list of over 50 vague feature ideas and chopped that in half.  Then, in half again. For example, it would be great to have app owners be able to put the affiliates through an approval process.  Affiliates would not be able to recommend your product until after you have vetted them and approved of them.  This helps keep the quality of your referrals up and has some potential legal benefits as well.  But, for the Rails Rumble (and perhaps even for first production uses of the app), the approval process is not essential.

In fact, this approval step would only make it more difficult for judges to get to the core purpose and features of the app.  For the Rumble, it should be as quick and simple as possible to get to the core of the app.  Putting an approval process in between affiliate sign up and affiliate dashboard would kill chances for a judge to quickly and easily judge the affiliate experience.

The Lure of the 15-Minute Weblog

Rails Rumble teams sometime do not finish.  They end the weekend without a working app. Short of sickness, power-failure, or energy-drink shortage, it is most often simply because they tried to do too much. Why is sticking to the essentials so difficult a concept? Partly it is the Rails community’s own doing.  It’s too easy to think, “Hey, if we can build an entire weblog in 15-minutes, just think what we can do in 48 hours!  That’s like almost 200x the time!”.  When compared against 15 minutes, 48 hours seems like a lot of time.  It’s not.  Take it from someone that’s been there, it’s not.

Status

I have also come to realize that writing about the Rumble and developing Affiliapp is not the same as doing the Rumble and developing Affiliapp.  So, this is likely my last blog post until after this weekend.  I will occasionally tweet (@smeade) and be on irc #railsrumble.

Good luck all Rails Rumblers, a big “Thanks” to the sponsors, and organizers!

What’s the Big Idea?

I’m continuing the walk through Getting Real, the very unofficial guide to Rails Rumble development. The Rumble is a natural fit for the tenants of chapter 2, The Starting Line, and chapter 3, Stay Lean.  I will Build Less, Fund Myself, Fix Time and Budget while Flexing Scope, and Embrace Constraints.  The rules and structure of the Rumble practically require it.  In the previous post I answered additional Getting Real questions from these chapters.  I identified my problem and came face-to-face with the enemy. To recap:

My Rails Rumble App Idea Takes the Sleaze Off

For this year’s Rails Rumble I decided to give 37signals’ Getting Real approach a try.  It’s a natural fit for the Rumble.  After all, the first dozen essays include ‘Build Less’, ’Fix Time and Budget, Flex Scope’, and ‘Embrace Constraints’.

What Rails Rumble and TechStars Have in Common (besides @andrewhyde)

With Rails Rumble 2009 coming up this weekend, I’ve been thinking about why I like the competition and why it’s so rewarding and productive.  In thinking through the attraction of the Rumble, I realized there is similarity to the recently wrapped Boulder TechStars session and other events in which smart developers participate (like Startup Weekend, etc.).  They are product incubators, just on different scale and with different missions.  Both provide insight into ways of working that work.

Just Set the Right Goals

In his blog today, Derek Sivers pointed to a study called When Intentions Go Public: Does Social Reality Widen the Intention-Behavior Gap? From this and similar studies Derek concluded that “people who talk about their intentions are less likely to make them happen.” Wray Herbert also offered similar advice in his Newsweek Mind Matters column.

This advice may be true for some intentions, but the blanket statement does not tell the whole story.  The message should be to keep talking – but with the right type of goals. More specifically: