The Story of an Application

This application’s tale begins before a single line of code is written. It is based on the true story of a dog walker and his developer friend. It begins with a dog walker with a job to be done, a dog walker who wants to give flexibility to his clients. He lets his clients book dog walks when they need and tracks those walks in his Google Calendar. But to gain this flexibility he must spend hours at the end of each month going through his calendar to invoice each client. And those are hours he isn’t doing what he’s paid to do: walk dogs!

And so enters our humble hero the application developer, who can save him from these hours of tedious labor every month. Our hero starts building the application, but first needs to allow the dog walker to connect his Google calendar account to the application. Suddenly she is faced with a number of challenges: how does Google’s authentication flow work? She needs a server to handle the OAuth callback. Where does this server live? How does she set up routing to this server? Where does she store the access token and how does she store it securely? She must address all these issues before she can access any of the data and explore the core logic in the application. She almost throws in the towel because this app isn’t for her job, and it suddenly seems too painful to pursue. The length of time to get to the fun, interesting part of the app looks impossibly long.

But she perseveres, sets up a server, and connects it to the Google calendar. Once it is connected, she must learn the nuances of the API and schema, wire up logic to paginate through the calendar results, all so that she can eventually get to the core business logic of computing the invoices. Once that is complete, she realizes she wants the app to deliver these invoices to the client. Again she faces a number of hurdles. Where does she store the mapping between the clients and their email addresses? How does she connect to an API like SendGrid (an email delivery service) to send an email?

Each new feature brings more data and more complexity. Dog owners love seeing pictures of their own dogs, and a photo attachment would make her dog walker’s clients excited to open an invoice. For this feature, she’d have to store more mappings and learn yet another API. Complexity piles up not only with new features but also with concerns about rate limiting, performance, and scale.

This application’s story is about a simple dog walking app, but the development challenges are similar to those of many applications, from the hobbyist to the enterprise developer. Modern applications are mashups of many different data repositories; the business logic (e.g. computing the invoice given a set of dog walks) is rapidly dwarfed by the complexities surrounding building an application. Many applications that would provide value to businesses don’t get built because the cost of building these apps is too high. It shouldn’t have to be this way for personal projects, and it shouldn’t have to be this way for business-critical applications; Transposit is coming to the rescue.