Stock Alerts Features

In my previous post I revealed my new side project, Stock Alerts, and my intention to build a .NET Core product on the Azure stack, posting regular updates about my work as I go. Before I get down into the weeds in future posts, I thought it might be good to first talk at a higher level about the MVP features I’ll be implementing and the infrastructure that will be needed.

Features

Stocks Alerts will consist of a mobile app with a small number of key features. Of course there will be backend services to support the mobile app functionality, but we’ll talk about the features from the user’s perspective as he/she interacts with the app.

There will also be a web app eventually, but for now we’ll just focus on the mobile app.

Alert Definition Management

Push notificationStock Alerts users will be able to view, create, edit, and delete alert definitions that define the criteria for a stock alert. In the course of creating an alert definition, the user will search for and select a stock, name the alert, and define the criteria that will trigger the alert.

Initially, the set of stocks available to create alert definitions will be limited, due to daily API call limits set by my data provider (which I’ll talk in a future post). I’ve considered either supporting only stocks in the S&P 500 at first or allowing the initial users to essentially define the initial universe of stocks by the alert definitions that they create. Still thinking on this one…

For the alert criteria, the API will support allowing the user to choose from multiple rule types (like various price alerts, technical alerts, and fundamental alerts), as well as combining multiple rules into a boolean logic tree, but for MVP the mobile app will only expose the ability to enter 1..n price alerts combined by an AND or OR.

Alert Notifications

Azure FunctionsThe Stock Alerts backend will evaluate all active alert definitions as it receives new stock data and notify users of triggered alerts via one or more of three methods: push notification, e-mail, and/or SMS message.

The processing of active alert definitions and the sending of notifications via the three channels will be handled by Azure Functions in conjunction with Azure Service Bus queues. Azure Functions are well-suited for these types of tasks – I pay for the compute that I use and they can scale out under load (for example, when AAPL makes a large move and triggers a large number of alerts).

User Registration & Login

The Stock Alerts mobile app will allow new users to register with the app and existing users to login. To register, a user just needs to provide their e-mail address, a unique username, and their password. After login, web requests will be authenticated via token-based authentication

User Preferences Management

Users will be able to set their notification preferences in the Stock Alerts app, including the channels that they will be notified on (push notification, e-mail, or SMS), as well as their e-mail address and SMS phone number, if applicable.

Payment/Subscription Management

Stripe logoThough users will be able to register and set up a limited number of alert definitions for free, I’ll charge users who have more than a few active alert definitions. Stripe is the standard for managing subscriptions and taking online payments, and their API is well-designed. We’ll integrate with Stripe to manage user subscriptions and payments for premium users.

Cross-Platform

Xamarin FormsThe mobile app will target both Android and iOS (and eventually web), and we’ll use Xamarin.Forms to accomplish this. I’m an Android user, so Android will be the first platform I focus on. I can get idea validation and feedback by launching on a single platform, and if there is traction after launch and I want to expand to iOS, I’ll be well-positioned to do so having build the app with Xamarin.Forms.

A web app will probably be post-MVP as well.

Is That All?

The feature set that I’m targeting for MVP is extremely limited by design. There’s enough here to provide value, prove out the idea, and demonstrate interactions throughout the full stack while being small enough to complete within a couple of months at 5-10 hours per week (though writing about it will slow me down some). There will also be plenty of opportunities for enhancements and additional features post-MVP, if I’m so inclined.

When choosing a side project, it’s important to me that it be very small and limited in scope for a few reasons. First, I want something that I can build quickly while I’m motivated and energized about the new idea and lessen the risk of losing interest or becoming bored with it halfway through. I also want to launch as soon as possible to begin the feedback loop and start learning from my users: What do they like/not like? How do they use the product? Will they pay for it? Etc… Finally, by limiting the initial feature set, I focus on just the core features of the product and I don’t waste time building features that my users may not even care about.

So now that we know what features we’ll be building, we’re ready to talk about the infrastructure needed to support those features!

… but that’s a topic for my next post. Thanks for reading.

-Jon


If you’d like to receive new posts via e-mail, consider joining the newsletter.

Open Shippers in Limited Preview

For the past few months I’ve been working on Open Shippers (openshippers.io), a place for solo makers to build and ship projects in the open, publicly sharing their progress as they take their products from conception to launch and beyond. Makers will post daily standups, log decisions made, and provide general commentary about their projects in real-time while receiving support, feedback, and accountability from the community.

Open Shippers home page.

Yesterday I launched a limited preview of Open Shippers with a post on Indie Hackers:

Open Shippers post on Indie Hackers.

My goal for the next couple of weeks is to gain a handful of beta users on Open Shippers to provide feedback and validate (or invalidate) the idea.

The Story So Far

The Open Shippers story starts last summer…

I’d started getting up early in the morning to devote the first couple of hours before the workday starts to personal pursuits and side project work at the suggestion of a buddy and colleague of mine who was doing the same. Think of the financial aphorism “Pay yourself first,” except applied to time in a day.

Every weekday morning shortly after 5:00 AM I’d join him in a Slack channel. After the obligatory “good morning,” we’d each give our daily standup for our respective projects: what I did yesterday, what I plan to do today, and what’s getting in my way.

I found that this daily routine of sharing my standup with a like-minded individual yielded several benefits:

  • I felt accountable to someone else to ship. Every. Day.
  • I received valuable feedback on the features I was building.
  • I focused more on the things that mattered for MVP and less on those that didn’t.
  • I had a sounding board for things I was considering and decisions I was making.
  • My productivity increased.

Sometime around the beginning of November, it occurred to me that there might be value in a dedicated place for solo makers to post their daily standups and journal their project progress. There already exists a fantastic ecosystem of maker communities online, and, while I benefit from many of them, I hadn’t found a project-focused place to journal my day-to-day progress.

So I got to work.

From the point I first started working on Open Shippers I recorded my daily standups in a file (in addition to sharing them with my buddy on Slack). It was my intention to start using the application as soon as possible as I’m building it, eat my own dog food. Once the database was up I’d seed it with the prior standups from my file.

November turned into December, and my colleague got busy with work trips and other life priorities that prevented him from joining me in the mornings for a few weeks. I continued my routine of posting my daily standups, and I found that the practice was valuable despite his absence.

Fast-forward to today – I’ve finished the functionality needed to support more users than just myself. Open Shippers is in limited preview.

Next Steps

There are many features on the Open Shippers roadmap, which I’ll publish soon. I’ll continue to develop new features in the open, with daily standups and updates.

I’d welcome any feedback that my readers might have on the site, and, if you’re so inclined, I invite you to join me on Open Shippers in the limited preview to use and hopefully get value from posting your daily standups and interacting with other shippers.

Thanks for reading! What will you ship today?

-Jon


If you’d like to receive new posts via e-mail, consider joining the newsletter.