Rapid Application Development of a Timely Two-Sided Marketplace. RAD in more ways than one.

Yes, we’re rad in a Ninja Turtles kinda way, but in this blog post we’re talking about RAD as in Rapid Application Development.

TL;DR – The lowdown

In just two days, we developed PayItFurloughed.com — a two-sided marketplace designed to help furloughed federal workers get a (much needed) free beer. People all over the country donated to a beer fund, and local breweries tapped that kitty to pay for the pints handed out.

For the devs out there, here’s the stack:

• Carrd: The simple CMS-driven website with pre-built and custom widgets.
• Stripe: For safe and simple credit-card donor payment processing.
• Zapier: For connecting Stripe to our Spreadsheet for tracking real-time transactions.
• Twilio: For beer-redemption SMS and the serverless function returning balances.
• Google Sheets: For our serving datastore, and for reporting/accounting.
• Slack: For notifications of each purchase, feeling the heartbeat of the site.

Here’s how it went down

On the 21st day of the government shutdown, we were contacted by food and travel author Nevin Martell and his partner, Al Goldberg from Mess Hall (DC’s renowned food incubator). They’d had enough. Furloughed workers weren’t getting paid, and local businesses were suffering. Something had to be done. They wanted some “sunshine in a shitstorm.”

The inspiration for this particular brand of “sunshine” came from the awesome Pizza to the Polls website. Folks had donated food to voters, so maybe they’d buy a beer for their furloughed friends. Nevin Martell and Al Goldberg wanted a website that would allow people to donate beer money to a fund and would allow bartenders at two of DC’s top breweries to dole out beer from that fund. The brewery gets paid and the furloughed workers get a free beer. Nevin and Al also wanted a real-time beer counter, a few donation options, a way to add more locations, and a way to determine where each beer was redeemed so Al could pay each brewery correctly.

That was Thursday afternoon. By Saturday morning, our team launched PayItFurlouged.com. Not with crazed, Redbull-fueled all-nighters, but with strategic and intentional rapid application development. Let us tell you a little bit about how we did it.

Planning

The first step in our planning process was to figure out all of the people who would be using the website. We identified the following user types:

• Joe – the regular Joe or Jane who loves the idea and spreads the word.
• Donor – the fine folks who wanna buy someone a beer.
• Fed – the frustrated federal workers who need some liquid relief.
• Bartender – the gal or guy who actually pulls pints for the Feds.
• Hero – In our case, this was just one person: Al Goldberg, the guy who’s making sure everyone gets paid.

And with these user types, we created some stories:

1. As a Joe, I must be able to learn about the project so I can tell my friends.
2. As a Donor, I must be able to donate a beer so that I can do some good.
3. As a Fed, I must know how many beers are available and where I can enjoy that beer.
4. As a Bartender, I must be able to redeem a beer without messing with my groove.
5. As the Hero, I must be able to track all donations and redemptions in real-time so I can distribute payments to each brewery.

Halfway through, we were asked for more:

• As a Donor with deeper pockets, I would like to be able to donate more than other donors, so I can feel extra special.
• As a Fed or Bartender outside DC, I want this movement extended to my city, because we’re hurting too.

Implementation

Here is how we went about realizing these user stories. We didn’t estimate story points like we normally do because, to be honest, we were afraid of seeing some large numbers.

Story 1: Joe’s gotta know

We got tipped off on this one by Chris Lawson of Current. “Use Carrd!” he said. “Simple setup,” he said, “and the Stripe widget is just a button-click.” (Chris always says things like this, but this time, he was right! Thanks dude.) Carrd offers “simple, free, fully responsive one-page sites for pretty much anything.” We figured this project could be a one-page site, so why not? Didn’t take us long to pay $50 for Carrd’s “pro” subscription for unlocking that Stripe widget and a year’s worth of button-clicks.

With draft content added, and the illusion of a larger, multi-page site (in fact, structurally it’s all still on one page, but with hidden sections), now any of us — even Al — could make changes to the site. But we didn’t let him. Nevin’s the writer after all.

Story 2: Donors gotta pay

We set up a Stripe account to handle payments. For us, Stripe is the first choice, and usually the last. We used to deal with Authorize.net back in the day. Then two true Irish geniuses (not 3Advance’s Darren and Paul, I assure you) changed the game. They made it super simple to start selling online, and they taught us developers how to document an API. Cheers lads.

The Stripe Checkout Button Widget allowed us to process payments with Stripe. It was as simple as creating 3 buttons with the relevant beer denominations (1, 2, and 6), supplying the cost of each beer ($7.50), and providing our Stripe developer keys. Next.

Story 3: Feds just wanna be loved

So it’s time for that ticker. Ugh, we have to actually write code now? Alas, yes. Unfortunately, Carrd had no widget for connecting to our Stripe backend, summing all payments, dividing that amount by $7.50 (the cost of each beer), and displaying the number. But we submitted a feature request, so maybe someday :-).

While I held my breath on that feature set, we played around with Carrd and found what we needed. As Carrd-carrying members (yes, I went there), our 50 bucks allowed us to embed a code block. A simple API call would retrieve the relevant information and calculate the number of beers. Stripe has a backend API from which we could get all payments and then sum the number of beers donated. But we weren’t about to expose our secret Stripe key to the world, so some server-side coding was needed.

At first, we went straight for the jugular — loading payments from Stripe. With a paging limit of 100 records, this was not going to scale well. We needed some sort of datastore, but we were reluctant to take on the burden of building and interfacing with a database. Our solution? Google Sheets.

So how would we get that Stripe charge data into Google Sheets? Enter Zapier, the hackers dream tool. We created a Zap that triggered on a new charge, creating a row in our Google Sheet with the following fields: Stripe Charge ID, Amount, Date, Description, and Customer email.

For the dopamine hit, we also used Zapier to fire off a message to a Slack every time a new order came in. We’re gonna have a hard time weaning Paul off this wonderdrug.

We then updated our code (in our node js server-balance endpoint) to read the information from this Google Sheet, including the sum of all the payments and the number of donated beers. Now that we had a data store, we added a row for a beer redemption that would simply post a row with a negative dollar amount to Google Sheets — keeping our balance and the number of beers current.

We were running this endpoint on a local machine and needed to deploy it. A serverless deployment was a natural fit for this lightweight, low-code function. But where? We use Firebase, AWS, and Azure already, but Twilio serverless functions jumped to the front of the queue because they had another feature we wanted (see Story 5). We created a Twilio account for this project, and in a matter of minutes we had our balance endpoint deployed and connected to Carrd (with a little CORS fun in the middle)

Story 4: Bartender’s Cha-Ching!

One thing we’re proud of at 3Advance is our user experience expertise. We knew an app wasn’t the right path, not with multiple platforms, approval processes, slow deployments, and a steep learning curve. This needed done fast, with as few obstacles as possible. Someday Alexa or Siri will be the answer, but not today, that’s for sure. We do have SMS though. It’s easy and it’s cheap. Most importantly, it’s an experience that is familiar to bartenders. It had to be painless if it was gonna work, and we didn’t have time to get this wrong.

We had two locations, so we bought two local numbers, each for $1 a month. By using a unique number for each location, we could identify the brewery no matter which bartender shoots off that text.

For each phone number we bought, we associated a Twilio serverless function to handle incoming SMS. This function did the following:

• Listened for keywords balance (scope-creep!) and redeem.
  • If balance, we queried our Google Sheet and returned a message — Balance: x beers remaining. (We eventually just cut this and allowed anything but redeem to return the balance.)
  • If redeem, we again queried our Google Sheet for the balance.
    • If greater than 0, we appended a new row to the sheet deplenishing one beer and returned the message “1 BEER REDEEMED! (New Balance: X beers remaining).”
    • If 0, we returned the message “REJECTED (No more beers remaining).”

This has worked flawlessly. It all has worked flawlessly. As a developer, that is a pretty good feeling.

Story 5: Yawn … Accounting

An important component of all of this is that these breweries get paid. Anyway, back to work …

As noted above, we used a unique Twilio number for each location, which unlocked this part of the puzzle. We created a second spreadsheet called “locations” and used that to store relevant metadata (Location Name, Phone Number). We busted out some spreadsheet chops and a few lookups later we were tracking redemptions via location. All on a Google Spreadsheet. Using tools that everyone understands means minimal training and a greatly reduced failure rate.

Story 6: Mo’ money, fewer problems

So, the urban legend (or is it actual research?) states that if presented three price options, 10% of customers will choose the most expensive. Our top donation option was $45 (enough for 6 beers) and 20% of donors choose that top option, we began to wonder what we were missing out on. So without confusing matters, we simply added links below those buttons: corporate sponsors, email us; bigger donors, see more options. This was trivial. That was nice.

Story 7: Mo’ locations, more problems

In order to keep things simple, we advised against multiple buckets (beer kitties). Keeping the site to just two locations minimized our potential failure points and kept the messaging under control. Ultimately, this story never happened because everything else was working (the site brought in $25K in five days), so it wasn’t worth muddying the waters.

Conclusion

It’s a great time to be an entrepreneur. It’s easier than ever to prototype your ideas and beyond with such a great array of tools at your disposal. All it takes is a little creative thinking and know-how.

For this project, that creativity meant we created a severless (Twilio) and basically database-less (Google Sheets) web application (caard) in a matter of hours that raised over 35K (4,671 beers) from 2,000 donations over a period of 12 days.

3Advance is an app development company in Washington DC that helps startups, non-profits, and other businesses turn great ideas into beautiful, simple mobile and desktop apps. If you’d like to learn more about how we can help you create a better way forward for your company, drop us a line. We’d love to hear from you.