Work Progress

Technical Work

I’ve spent the last few days cleaning up some of the authentication flows and bug squashing on both the client and server.

On the client, I had a bug that would result in Firebase overwriting the entire user preferences data blob, during a page update.

The way the client is built, I provide an authentication context on the root DOM node but the element wasn’t set up to subscribe to changes in the preferences context. I’ve got a fix staged but I’ll need a few hours to test things out.

The server is in good shape, meaning I probably won’t be tinkering too much with the code, aside from putting in some safeguards to prevent a user from repeatedly deploying infrastructure through my service. Those safeguards are really there so I don’t end up with some monstrous AWS bill every month.

The next big item will be beginning working on getting both client and server deployed to AWS. My original prototype utilized Elastic Beanstalk and S3 to achieve this, so I’m hoping I can re-use some of that knowledge.

On the non-technical side, I’ve been planning out my pricing model for the application.

Pricing Strategy

Pricing is probably one of the most complex topics to work through for this application. There are a handful of similar products already on the marketplace, however pricing based off competition is not a sound approach.

Before outlining payment models, it’s good to outline the requirements and reasoning behind collecting payment.

I want my users to be invested in the product and have a sense of ownership of their information and experience. By remitting payment, they should feel empowered to voice their opinion of the product and their user experience.

In today’s world, we’re extremely accustomed to “free” software – Google, Facebook, and YouTube etc… These companies have economies of scale to sell advertisements (and customers’ information) as additional revenue streams. This model, as we’ve all found, limits our ability to advocate for change in an effective manner. We have a choice to go to other platforms but it’s inherently difficult. Those platforms don’t have the revenue, economies of scale, or features to be true competitors to these “free” products.

I want my customers to know they have a choice and they should freely vote with their voices and dollars.

The other facet of payment (versus totally free or even open source) is that it takes time, energy, and money to build and maintain an application. Ideally this project will provide enough revenue to be self-sustaining, with lots of happy customers.

My mini-goal for payment can be summed up by this statement: Can I get one user, to pay me that first dollar (or first month’s fee)?

Collecting payment is not only a business concern – it’s also a technical concern. Being a sole developer, I have to balance the needs of getting payment and the complexity of building a service that interfaces with my payment / billing model.

With that context out of the way, let’s go over the payment models:

Option 1: Freemium

Similar to Spotify’s subscription model, in which users can use a free set of features for an indefinite amount of time. While I won’t be serving interstitial advertisements on the site, users will be able to subscribe to payment to obtain additional features.

Option 2: Free Trial

With this option, users would receive free access to the entire application and all its features, for an initial period of time. Once that period of time has elapsed, users would be responsible for an on-going subscription fee.

Option 3: No Free Trial – Instant Subscription

In this option, users would be obligated to pay immediately upon sign up. Upon sign up (and on-going payment) users receive full access to the application.

Option 4: Piecemeal / Hybrid

In this more complex model, users would be able to piece together the services they desire, à la carte. Based on the services or features desired, payment would be calculated additively, with some nominal base fee being collected each month.

Option 5: Combination of Option 1 and Option 2

In this model, users would get a free trial, with access to a full feature set. After a certain amount of time has elapsed, the users would be responsible for remitting payment to receive advanced features, or remain at a free tier with a smaller feature set.

Payment Paradox

I’m going to let these options simmer for a bit – I’ll follow up with another post detailing which option I chose, the “why”, and then the “how.

Thanks for following along!

• Jonathan