We were inspired by the story of a lifelong smoker and civil rights activist who made a "devil's bargain" with herself, said that if she ever smoked again she would give $500 to the KKK, and then quit cold turkey after decades of failed attempts.

It's an extreme example, sure. Yet we felt it was a provocation for a system that not only increased peoples' awareness of events around them, but went one step further and encouraged them to really commit to going to that event by making a bargain with their future selves and put a tiny bit of money down!

What it does

A user can log in to Komit, and declare an interest, hobby, or goal. With that interest specified, Komit uses Active Access's Activity Search API to find events in that user's area, combining it with weather forecasts from DarkSky.

Presented with this list, the user can then choose to commit to an event, and is presented with a miniature agreement to actually go to the event. These agreements are stored in DynamoDB, with the intention that (future features incoming) ...

  • The user puts a small amount of money down in the mini-agreement to say "Yes, I'm going",
  • If they don't go, that money goes back to the event organizer, a charity of the user's choice, some other option we haven't brainstormed yet.
  • If they do go, then they get that money back as a gift from their past self, along with the good vibes of knowing that they did it!

How we built it

We more or less divided and conquered between building the iOS front-end (Ravin), writing the event and weather API calls for AWS lambda to execute (Ross/William), and setting up all of the AWS architecture so that our front end and serverless backend could talk to each other (William).

Challenges we ran into

Short Version: Haven't we all wished APIs were documented a bit better?

More specifically on the front-end, we hit some roadblocks trying to use DocuSign APIs to support the "commit to this event" flow within our app. We got really close to implementing it before deadline, but it didn't make it in the final cut. In retrospect, we were probably a little bit too driven by "let's use this particular tech to meet this need" rather than starting with the actual user need.

More specifically the backend, it took a bit of configuration for us to craft a request for the Activity API that matched the use case we wanted to demo: somebody wanting to get outdoors and be more active. The query we got returns actual results, but is definitely a bit brittle. There's a lot more optimization for be done to make sure that when we get events and weather we're making as few API calls as possible.

Accomplishments that we're proud of

Quite honestly, hooking up this entire system so that our front-end and back-end were talking to each other and returning actual data (rather than stubbed out stuff) was pretty cool to see. Getting as quickly as you can to craft a coherent story and being able to walk through parts of it live was cool.

What we learned

This was our first experience using AWS Lambda, Dynamo DB, and Mobile Hub to quickly connect all the pieces of our app. It's definitely a suite of solutions we'd look to in the future for relatively quick prototyping.

We also learned the value of going with the easiest thing first. We could have used the Meetup API, but that would have required building an OAuth2 flow into our app/changing a lot on the front end mid-stream. Charging forward with the Activity API let us make progress and see real results quicker, while giving us ideas about how to optimize over the longer term.

What's next for Komit

There's definitely more work to be done to hammer out some of the agreement flows in the app right now, along with more though that needs to happen into some of the real user stories around that moment (What language do we use?, How do we actually verify that people did/did not show up? How do we handle transactions?). Those questions are definitely important, just outside the scope of a 24 hours.

As someone who worked on the back-end, there's also more optimizations that we can make to our API as it stands to:

  • allow users to declare different types of interests and submit that as a query param
  • make our service more responsive (minimizing redundant calls to our weather API, only doing it at a level of time and geography that's absolutely necessary).

Built With

Share this project: