Some news:

I have changed the way plans are described, to match what was discussed here.

A minor update to the Android app was just published. Google Play should push it to users over the next hours, as caches or whatever update. This doesn't bring many changes for existing users, the only new thing is that when pairing with an account, you can now use one of the Google accounts configured on the device to sign in, without having to type the account's credentials into the webview.

I noticed that the app was installed 18 times, and uninstalled 5 times... I wonder what can be done to make the app/service correspond better to the expectations of new users. 28% of users giving up seems a bit high, but I agree the sample size is very small. Let's see if this update reduces the friction for new users, and if the numbers change over time.

I haven't used it so take this with the smallest grain of salt:

The 1 day of battery history is a giant PITA for the free tier. Why the limitation? Could you maybe make it 5 days? 7? Depending on the granularity of the info, could you average it out? Instead of minute by minute for all 5-7 days, could it be hour by hour after the first day? Only keeping to-the-minute info for 24 hours? Again, that's only if you have that level of detail.

Secondly, this is more of a single use case here, I only have one mobile device. An iPhone. But say that was an Android. Why do I need a battery monitor that works in the cloud for one device? There are already on-device apps that do the same thing and give notifications. Perhaps, allow local notifications for that device only on all tiers. By using historical data over the last 5-7 days, you could create a notification that says "Hey, we suggest you plug your phone in now for 45 minutes so it has enough power to last through the rest of the day." Premium Notifications can be pushed to other devices. Like a laptop getting the notification to charge your phone.

Thirdly, and just a shot in the dark, does it track and log per app usage? I don't have a compatible device to know but this is another big feature and going to assume it doesn't. So, my battery dropped 20% in an hour but your service/app won't tell me which app caused it? Again, one day of history is very limited. Does this happen every day around the same time? Or after I open the offending app? Having that extra few days of historical data could be useful.

I think it's a great start and a beautiful looking app. There's just some catch up that needs to happen.

The tier details, including
a) the amount / type of tiers to offer
b) what's included in the free tier
c) the cost of each tier
are all yet to be planned. I agree that 1 day is a bit too little, but that's also mainly because right now battery history is most of what Clouttery has to offer (aside from the notifications). But as I said, I haven't even thought about this, this isn't a priority, and things may change a lot as new features are developed.
I don't want to think too much about the plans before knowing what's there to offer, and right now things change fast and I don't want to be rethinking the plans all the time. Which is also part of the reason people now get unlimited everything, this way I can understand what they use and I don't have to worry about tiers right now.

Right now notifications are available (for any device including the local one) on all tiers. What's not available for everyone is "advanced notifications", which are those that require some significant amount of computation to issue, as well as enough battery history.

Averaging / decreasing granularity with time has definitely been thought about, but as storage is relatively cheap, in the end it all comes out to what's cheaper: the processing time to go through database records and aggregate data, or to simply pay for the storage of all the data with the original granularity.

The ability to provide "advanced notifications" to one or just a few devices is also on the table, and so the free tier could be something like "maximum of 5 devices and advanced notifications about one of them". Again, this gets into tier specifics territory, which I would prefer not to think about until the service is more mature.
I should also note that independently of the device limit on the account, users will always be able to pair an unlimited number of clients to their account, which can get notifications and device status. They just won't be able to submit information for more than the limit of devices for their plan. People using the Chrome extension may have already noticed that they can pair as many Chrome sessions as they like, without counting towards the device total.

Clouttery does not yet track per-app battery usage. Currently some major changes to the server are currently in development, that will allow for collecting more information about the batteries, including their temperature. After this, clients will be updated to start uploading this data. Not all batteries/drivers/OS will provide all the info, and this is fine: Clouttery collects only what it can and tries to work with that.

I will try to include in this major set of changes some way to also collect more "free-form" information such as per-app usage. All this needs to be handled with care so that users are not scared away due to too much data collection - and on Android, an excessively long permission list.

Tracking per-app usage would also involve collecting much more info than we do now (even just the names of the top 5 battery-consuming apps polled in intervals of 15 minutes would mean a size increase of over 200% compared to what's collected now). This means that perhaps this feature would need to be limited to paid plans / limited to one or two devices only on the free plan.

Based on what I've seen so far, even without going into collection of information about anything but the battery itself, it's possible to extract a lot of information. For example, it's quite obvious to everyone that when talking on the phone or playing heavy games, batteries discharge much faster. This is easily seen in the battery history graphs, Clouttery just doesn't detect it yet. Obviously, the more data we collect, the more possibilities there are, and hopefully the better the accuracy gets.

To address your last point about one day of battery history being too limited to perform that kind of "does this happen every day / what app causes this" analysis, I'd just like to mention that just because Clouttery will only display one day (or two, three, 50, whatever days) of battery history, that doesn't mean that's all it is storing... it could store more (eventually with less granularity) for "internal purposes" in order to generate e.g. reports about power-hungry apps, times of the day that tend to be peaks of energy consumption, etc.

Apple devices are a hard platform to support at this point, especially their mobile devices. Developer tools that will only legally run on certain hardware, recurrent and very high fees to access the app store. And in the end there's always the possibility that the app will be rejected, or that there are not enough APIs to collect the necessary battery info. Clouttery will probably have to do without a client for iOS until it has reached enough critical mass and paying clients to justify the investment of time but especially money to develop a client for iDevices. Let's hope those users on platforms with less than 20% of global market share don't hurt Clouttery's growth - which at the same time makes things quite harder, as statistics say people on those platforms are the most likely to pay for something like this product...

I'm just a guy on the internet but I think this should absolutely be a priority. You're losing 28% of potential members for some reason. I firmly believe it's because of your two tiers. You have a very limited free option and a monthly premium plan. I concede that it is an attractive offer for the current rate. Not going to list prices as those may change and this post won't be updated to reflect that.

I also think the naming could be better? I ended that in a question because, well, I'm not sure. Basic just sounds... limited. Perhaps consider changing it to a "Standard" Plan. All new users get the Standard Plan then they can upgrade if they desire. But, if a user sees that they are on a plan called "Basic" then they may be inclined to upgrade just so they don't have that title to their account; no ones wants the basics -- but they'll take a standard.

That may not make sense. Maybe an analogy will help:

When looking at cars, the dealers call the models without options, the standard model. Then you can upgrade or purchase options to make the car more attractive to you. Now, if a salesman were to tell you they have a basic car what exactly would you imagine? Would it be a car with the standard features or something less? I, personally, think it would be something less. All most all cars these days come with climate control, heated seats, remote un/locking, etc. That's standard. In my mind, a basic car wouldn't have that. And, yes. I've looked at cars that lacked those features where other models did by default. I went with the car that had those features because I didn't want a basic car, I wanted to look at my car in 4 years and smile. Not groan at all the things I wish it had.

What about the options? I could have gotten a sunroof, rear view camera, navigation display, lights in the footwells, lights than illuminate the ground when the door is open. I've never really used a sunroof, I mostly just pop them up because I want to look cool. Back up camera I ended up installing myself, as well as a navigation display.

Evernote has a Basic plan, however. It can go both ways, I just wouldn't name it that. But, you also have the backend to deal with to. I recognize that you need to get the backend ready to support the tiers you want to offer so I understand why announcing new tiers aren't a high priority right now. It looks like you're working towards that direction though!



Very nice!

Regarding iOS, I know it's a long ways out. Apple is pretty tight about those sorts of APIs I imagine. Maybe, however, look into a Jailbreak app? It may be a good middle ground to see if it going official is worth it.

I am relatively sure that is more likely to be due to the reproducible crashes that were affecting the previous version of the Android app, which I fixed yesterday (and an update was published, latest version is 0.9.2), than to be about the hypotetical plan names. Here's why:

I'm not sure you understood: right now anyone who signs up goes directly onto the Unlimited plan, and gets a 100% off lifetime coupon. I don't understand why people would care what plans are there or what they are called, in fact, they won't even see any mention to account plans unless they dive into the settings on the clients or on the web dashboard. The fact that people are on an unlimited plan with all the features and have a lifetime coupon that gives them Clouttery for free, forever, should be enough reason for them not to care about plans. People need to explicitly downgrade to the "Basic" plan, through the website, to be annoyed at the name... which raises the question, why did they downgrade in the first place?

And to reiterate a bit on what I said on my last post, the things that are there about plans are placeholders; the fact that there are any plans on the website at all is so beta-testers can see how things will look like (in terms of user interface, not in terms of how things are called or what plans are there, or what they are about) and so the plan upgrade/downgrade flow can be tested, among other things.
But users who are signing up now don't even need to touch the plan/billing system, to get all the features.

Over the last week, I worked on completely redesigning how the Clouttery server stores data.

It was using a simple key-value store (Bolt). I slowly came to the realization that some of the features I have planned would be kind of hard to implement using Bolt; that the nested buckets structure used with Bolt was too limiting, by forcing a hierarchy (or interpretation, if you wish) on the data. The databases course I took last semester forced me to get my hands very dirty with SQL, and after seeing the benefits, I decided to move to a relational database.

Another reason for moving was that Bolt can't scale (no replication, it's meant for use by a single app, like SQLite), and while the server software is not yet ready to be clustered, moving away from Bolt (and, in general, uncoupling the server from the database) is a giant step towards that goal. I had known for long that I had to use something other than Bolt if I wanted to make the server distributed, I just wasn't sure whether to move to a relational database, another barebones key-value store, or some amalgamation of solutions involving specialized time series databases or what-have-you.

The database can now be accessed transparently by multiple applications, which means that, for example, in case I want to do some complex analysis on the battery histories, I no longer have to stuff that code into the server. I can even use a language other than the one the server is written in (Go), like Python, which I really don't like but has many libraries for data analysis.

Clouttery is now powered by a traditional PostgreSQL database.

The changes were pushed to production less than a hour ago - after extensive testing on the staging environment, which unfortunately didn't catch all the bugs.
A few hotfixes later, everything appears to be working fine.

It would be great if over the next few days users could pay a bit more attention to the behavior of Clouttery, namely making sure that battery histories are updating as they should, and that notifications are generated when they should, according to their settings.

I'm available to answer questions about the database design (both the new one and the previous one), the reasons for the switch, or really anything. I'm a bit too much proud of this (until I find out more horrible bugs...) so I really want to talk about it but I don't know where to start

I just pushed an update for Clouttery for Windows that was preventing the client from working in certain time zones (in fact, about half of the world!).

The only reason I found out about this was because this night lots of European countries including mine entered daylight saving time.

This is all the more embarrassing because an extremely similar problem had already been detected when we exited DST. I'm pretty sure that at the time I tested the fix with multiple timezones, and the problem didn't occur. Now, and for future reference, I did the same, for time zones ranging from UTC-12 to UTC+12. If things go south again next October, I think I'll lose my mind.

It's the fourth post done by me in a row, and there doesn't seem to be much interest in Clouttery around here, and the truth is, I lost interest as well.
I'll keep running the server, but the way this project is managed will be different from now on.

I posted a long post on the subject at my blog. If you have ten minutes to spare, read it.

I always told people that if I were to stop working on Clouttery, I would release the source code. That's exactly what I'm going to do. Over the next few weeks, I'll work to turn Clouttery into an open source project. I don't promise it will be easy to contribute to it, since that would require writing detailed documentation on how to get the server to run, how to modify the clients to talk to a different server, and so on. However, the simple fact that the code will be out for everyone to see is already a much better situation that leaving this project to rot in private repos forever.

I know I said "Over the next few weeks, I'll work to turn Clouttery into an open source project." But months have passed, and it didn't happen yet... but I'm happy to announce that today, I finally found some time and motivation to work on Clouttery again.

The work I've done today puts the last remaining big obstacle towards open sourcing Clouttery out of the way. I rewrote the dotAccount authentication code so that it no longer relied on a mess of PHP code and instead used a proper library, in the same language as the Clouttery server and built into it. I did not want to release the source of Clouttery as long as the PHP bridge was used, because it relied on quite a lot of security through obscurity. Now that the server uses something proper, I'm closer than ever to being able to open source Clouttery - both the server and the clients. However, I'm still not entirely sure I want to do it.

The reason is simple: I had the opportunity to talk about Clouttery (or in entrepreneur lingo, "pitch Clouttery") to a few people who have relevant experience in the area of bootstrapping projects like these and turning them into real businesses. Most of these people found the idea to be great and agreed that it's realistically possible to make the subscription model work and have people pay monthly for something like this, especially if the service is extended to support most of the features I initially planned and which are yet to be implemented. In this sense, I might not want to open source the code. I'll see, over the following months, if I feel like working on this ever again or not, and decide whether to open-source it or not.

I should note that the reason why I basically have no time to work on this is because all of my free time over the past months has been spent working on UnderLX. UnderLX is an unofficial app for the Lisbon subway. It began as a silly project, but over time it has turned into something much bigger than I expected, developed by me and another guy, plus a quite small but active community of "power users". In November we were featured in national media for the first time. Since then, we have been featured in over ten online news sites, from tech news sites to "mainstream news" sites, and we were interviewed four times - and I'm talking about full-length interviews here. Here are some of them (in Portuguese): 1, 2, 3.
The UnderLX Android application now has over 3500 active users and it doesn't seem like it will ever stop growing. I honestly never expected so much exposure and success from a silly app for public transit. Hopefully this lets you understand why Clouttery has been basically dead for almost a year, and also why I'm not ever going back to developing software for calculators - at least, not as a hobby.