I’ve spent around 2 months building SignalLeaf, so far. It’s all after-hours and weekends, but I got the job done … well… I got a minimum viable product done. I at least solved some pain that I had been seeing in the land of podcasting. Along the way, I focused almost exclusively on the features that users would be working with to create podcasts, add episodes, setup RSS feeds and get a very basic amount of traffic information for an episode. This is all great from the user’s perspective. It’s things that podcasters need in order to get their job done. But along the way, I have purposely neglected the back-end system – the code and feature sets that *I* need in order to understand how my app is shaping up and manage it. But I realized something today: if I’m looking for the minimum deliverable and I’m looking at creating a service for the users first and for myself second, I really don’t need to spend a lot of time building a fancy set of pages that I can see from the web site directly. In fact, I don’t need much of any code to start with, for the back-end. After all, I have code that I can run from my machine and grab data from the production database, so why not do that? Why not create a minimum viable report to show me the information I need?
Minimum Viable Report
The first thing I want to know is how many customer accounts and podcasts I have in SignalLeaf. This will give me some idea of how well I’m doing w/ marketing effort, feature advertisement, pricing, etc. It’s not going to give me much, but it’s a start and it at least feeds my vanity metic of having customers. Rather than spend a lot of time building out an administrative back-end for my app, though, I decided to just hack together a quick script that gives me the information I need. I really just wanted to see without having to go through MongoDB’s command line tools directly.
So I built this little script:
And that’s it. It’s just an import of my system’s basic modules, a database connection, a query to get some information and then aggregating that information in to a simple console.log output. To run my report, I just run “node customers.js” and it will connect to my local database. If I want to run it against production, I only need to set “NODE_ENV=production” prior to running the script and BAM! I have a report of my production app:
(Yes, I know this is a meagerly pathetic # of accounts and podcasts. But that’s not the point.)
Iterating, Scaling, Improving
One of the things that I like the most about this, is being able to hack together any script I want and get information I want, quickly. I don’t have to worry about designing a proper report format. I don’t have to worry about creating a bunch of HTML, route handlers, and other things involved in getting a real report setup on the site. I can hack a script, iterate, fix it, run it as needed and move on.
Of course, this type of reporting doesn’t scale to more than just administrative people with direct access to the code and database – which is really just me, anyways. But it does get me down the path of being able to see the information I need, when I need it, and moving on to the next feature that my customers need.
From here, I’ll be able to tweak the core of the reports to get the information I really do need. Then once I have some of the basics done and ready to roll, I’ll be able to work on the UI side of things and already have the data available.