Looking for Beta Testers for Android App to compare Mobile Costs

killbiller · 21-05-2014 08:53AM #1

Hey all,

We're making an app for Ireland that uses your phone logs and works out exactly how much each bill option in Ireland would cost you. The application is called "KillBiller". The idea is to make the decision about switching networks in Ireland easy.

We are in need of some people with android phones to test our initial version. We're hoping to release to the public in the coming fortnight or so.

If you are interested - please sign up on www . killbiller . com and we'll give you access to the app. We're aiming for 100 people, but we'll take 5 people too like.

You're best to use your Google Play email address to sign up since that'll need access to the beta etc.

Would welcome any comments / feedback! Unfortunately its Android only for now.

Thanks!

The KillBiller Team
killbiller.com

PS. We are not going to make money off anyone who signs up for testing. The app currently has no advertisements etc!

Kavrocks · 21-05-2014 10:25AM

I'll sign up to beta test but don't want to get spammed with emails so I'm being put off by

SIGN UP TO OUR BETA MAILING LIST

If this works it's a very good idea. If you don't mind me asking, do you have any agreements with Irish networks to support this or are you just scraping their websites?

killbiller · 21-05-2014 11:03AM

Thanks for signing up Kavrocks.

Not plans to go spamming. I think that message is by default added on as we are using MailChimp to manage the email list of beta testers. We'll keep the mails to a minimum and get probably get rid of the lists once we launch. Either way, it'll be easy to remove yourself if necessary.

No agreements with Irish Networks yet. Call costs are taken from the plan descriptions on their sites, a HLR lookup system is used to determine what networks the different phone numbers are on, and we calculate the monthly costs from the call logs on your phone.

Kavrocks · 21-05-2014 11:06AM

killbiller wrote: »

No agreements with Irish Networks yet. Call costs are taken from the plan descriptions on their sites, a HLR lookup system is used to determine what networks the different phone numbers are on, and we calculate the monthly costs from the call logs on your phone.

Do you have anything in place for when networks change their website designs and plans or will it require manual updating of the app?

killbiller · 21-05-2014 11:48AM

There's a certain amount of manual intervention required. Thankfully it wont require updating the application on users phones - all of the plan data is held on our server - so its a matter of updating an excel file with new details.

There'll probably be days where we are a bit behind the trends on plans, but we'd hope to keep these up to date as much as we can.

Kavrocks · 21-05-2014 06:25PM

Bit concerned that you don't need all the permissions you've asked for as well as you having to upload my data to your server, I'd rather your app downloaded the data from your server and did the calculations on my phone. More critically though, your app doesn't work. I've tried several times and each time I get a message saying there is an error connecting to your server.

Also given that results could take up to 25 seconds to be returned do you not think it would be a good idea to have a notification tell you when they are done? I don't know about most people but waiting that length of time in this day and age would annoy me.

Your app looks very well. Clean and minimalist.

killbiller · 21-05-2014 07:19PM

Hey Kavrocks.

First of all yes - There was a bug in the code that we didn't anticipate this morning that has basically ruined all of the results today. I'm pushing changes to the server now that *should* have sorted this. If you can let me know if its working, i would very much appreciate that.

We understand your concern for data transfer / privacy. Firstly, we went for the server processing option due to the complexity of the calculations. implementation using Android (java) programming would have taken a lot longer to develop, and there would have been huge variability between different phone's processing powers. Secondly, keeping the calculations on the server and essentially having "dumb" phone apps allows us to change things (like the bug fix today) without pushing hundreds of updates to everyones phones (which take over 6 hours to propogate through the Play Store).

With regards to data security, we had a similar question on Reddit. We don't give data to anyone and we have no plans to give/share/give access data to anyone else, and we only use it for the purposes as stated on the application. Also, the only data that's uploaded is the user identification - and then numbers (to work out networks), durations, and times of calls/texts. No names / contents of texts etc. Suppose if we find that people are very uncomfortable with that idea, we'll have to work something else out in time.

Thanks for the feedback on the look and feel - and you've only seen the front screen....

I would hope that things are working a bit better now.

mitsuko045 · 21-05-2014 07:56PM

Kavrocks wrote: »

More critically though, your app doesn't work. I've tried several times and each time I get a message saying there is an error connecting to your server.

After a few emails to the developer it seems to be working fully now

Kavrocks wrote: »

Also given that results could take up to 25 seconds to be returned do you not think it would be a good idea to have a notification tell you when they are done.

It takes longer than 25seconds for which is a bit annoying but tbh you put you phone down for a minute, you pick it up and the info is there, notifications annoy me more.

Kavrocks · 21-05-2014 09:39PM

killbiller wrote: »

Hey Kavrocks.

First of all yes - There was a bug in the code that we didn't anticipate this morning that has basically ruined all of the results today. I'm pushing changes to the server now that *should* have sorted this. If you can let me know if its working, i would very much appreciate that.

It appears to work now.

killbiller wrote: »

We understand your concern for data transfer / privacy. Firstly, we went for the server processing option due to the complexity of the calculations. implementation using Android (java) programming would have taken a lot longer to develop, and there would have been huge variability between different phone's processing powers. Secondly, keeping the calculations on the server and essentially having "dumb" phone apps allows us to change things (like the bug fix today) without pushing hundreds of updates to everyones phones (which take over 6 hours to propogate through the Play Store).

Completely take this and understand.

killbiller wrote: »

With regards to data security, we had a similar question on Reddit. We don't give data to anyone and we have no plans to give/share/give access data to anyone else, and we only use it for the purposes as stated on the application. Also, the only data that's uploaded is the user identification - and then numbers (to work out networks), durations, and times of calls/texts. No names / contents of texts etc. Suppose if we find that people are very uncomfortable with that idea, we'll have to work something else out in time.

It was mainly the permissions you ask for. Surely all you need is to read the call and sms logs as well as a data summary (not even sure this is possible without manually tracking it yourself, maybe you could enlighten me as I'd be interested to know for myself) and then being able to connect to the internet. According to Google Play you've requested access to logs (I can see why this may be needed for bug reports and whatnot, however that's not how Google portrays it when they add 'sensitive'), accounts on my phone (only reason I see is possibly to get my number but does that matter?), contacts (really don't see why this is needed), location (is this not only for Ireland?)

killbiller wrote: »

Thanks for the feedback on the look and feel - and you've only seen the front screen....

I would hope that things are working a bit better now.

Works much better now. Does it include Prepay or only Billpay? I ask because I only got Billpay results which aren't quite appealing to me but that's just me.

killbiller · 22-05-2014 03:13PM

Hey Kavrocks. Thanks for the feedback!

It was mainly the permissions you ask for. Surely all you need is to read the call and sms logs as well as a data summary (not even sure this is possible without manually tracking it yourself, maybe you could enlighten me as I'd be interested to know for myself) and then being able to connect to the internet.

Looking into the permissions situation - here's what I've got:
Call and SMS Logs - for calculating the costs
Data summary - for calculating the costs
Logs - This is for the submission of crash reports when things go wrong. We log messages from our code as the app runs.
Accounts on my phone - This is required to generate the email list when the user requests details for a certain plan.
Contacts - Checking this one, but I think this is required when details of the SMS and Calls logs are required.
Location - This one might actually be removable, we will get back to you on this. Although rough location information would be great for market penetration, we don't explicitly use this permission in our code at the moment.

Works much better now. Does it include Prepay or only Billpay? I ask because I only got Billpay results which aren't quite appealing to me but that's just me.

Its purely BillPay plans that are displayed for now. We hope to expand to PrePay if there is enough interest in the app over the next few weeks! Waiting to see what the response is when we go public.

Glad that it's working for you!

If you know anyone else that would be interested in testing it out, please do point them our way - we're trying to get the application on as many phones as possible with feedback to avoid a massive fail when we let it loose.

Atomic Pineapple · 22-05-2014 03:41PM

You can limit the release of your application when you put it up on Google Play now if you want, so might be best doing that initially and monitoring your logging for crashes. Would be easier and more efficient way of beta testing than asking people on forums.

I'll have a look at your app if I get a chance but currently pretty busy between work and personal projects.

The Corinthian · 22-05-2014 06:08PM

killbiller wrote: »

Logs - This is for the submission of crash reports when things go wrong. We log messages from our code as the app runs.

Hmmm... users get the option to send a crash log whenever the app crashes or ANRs, which will give all the necessary log information to deal with such scenarios. Also I'd have to question how you send such logs; after all, the app has crashed?

I'd be weary of granting this permission, TBH, as the low-level logs it has access to can contain the user's private information.

Accounts on my phone - This is required to generate the email list when the user requests details for a certain plan.

Is there a reason you can't just ask for an email address from the user? From a marketing point of view, I'd be careful about using this one as it's been found to be a serious cock-blocker in the installs stakes.

Contacts - Checking this one, but I think this is required when details of the SMS and Calls logs are required.

No it's not - you already get that from the Call and SMS Logs permission. It's only required if you want to know who they are.

Good luck with the app though, I've worked on two solutions (one Web and one mobile with a Web back-end) of this kind and being able to model the data accurately is a nightmare at the best of times. Opcos don't want others to be able to do so and so intentionally price their offers in wildly different and complex fashions - I expect that will be your biggest problem, not only in terms of maintenance, but also being able to model new plans that may not 'fit' in your system.

Crack that though and there's a lucrative market for selling that data to third parties. One crowd in Germany I dealt with charge about 5,000€ p.m. for online access to their data.

killbiller · 22-05-2014 09:54PM

Atomic Pineapple wrote: »

You can limit the release of your application when you put it up on Google Play now if you want, so might be best doing that initially and monitoring your logging for crashes. Would be easier and more efficient way of beta testing than asking people on forums.

I'll have a look at your app if I get a chance but currently pretty busy between work and personal projects.

Hey yeah, we were having a look at this - but decided to keep the group even smaller for the original tests - I'm fairly sure we'll run into more problems when we try to scale. But at least at this point we can contact our users and keep them up to date with goings on / fixes.

At this point too, we reduce the risk of getting a tonne of low ratings since the app isn't public!

Thanks for having a look!

killbiller · 22-05-2014 10:00PM

Hmmm... users get the option to send a crash log whenever the app crashes or ANRs, which will give all the necessary log information to deal with such scenarios. Also I'd have to question how you send such logs; after all, the app has crashed?

We're using a plugin to catch the error logs before the app fully shuts down and submit them to our server just before the app quits. Really handy since we dont think users will report all of those sorts of crashes...

Will check out the story about the other permissions, but I think i remember having a discussion with the guys about reluctantly adding them out of necessity.

The Corinthian wrote: »

Good luck with the app though, I've worked on two solutions (one Web and one mobile with a Web back-end) of this kind and being able to model the data accurately is a nightmare at the best of times. Opcos don't want others to be able to do so and so intentionally price their offers in wildly different and complex fashions - I expect that will be your biggest problem, not only in terms of maintenance, but also being able to model new plans that may not 'fit' in your system.

Crack that though and there's a lucrative market for selling that data to third parties. One crowd in Germany I dealt with charge about 5,000€ p.m. for online access to their data.

Thanks! Sounds like you have a bit of experience with the issue. You dont happen to remember the name of the guys in Germany?

I'd actually be keen to have a chat if you have 15 minutes one of the days for a phone call. We've built our system thus far as flexible as posslbe and can cater for 80-90% of the bill pay plans. The prepay stuff is 60% there, though i think we can crack that with a bit more work! PM me sure if you have a chance.

Cheers for the feedback and discussion too.

teddyr · 22-05-2014 10:06PM

Hi, another KillBiller here,

Thanks all for helping out with the testing!

I think we can get away without the READ_LOGS and READ_CONTACTS permissions. These were added during development & testing on our internal phones but now look to be unnecessary.

For the accounts on the phone - really we just want to make the app as easy to use as possible. With the e-mail list, we can allow somebody to get the information with 2 taps (select e-mail address and tap 'send') rather than the 10+ that it will take to type in the address and then tap send - not to mention potential typos.

When you say that the accounts permission are a blocker for installs, do you have any figures for this or is it based on experience? It would be great to understand how big a drop off we can expect as it would allow us to make a trade off.

The Corinthian · 23-05-2014 07:19AM

killbiller wrote: »

You dont happen to remember the name of the guys in Germany?

No. This was back in 2010, so I did a quick search through my emails, for ".de" this morning to see if I could find their URL in one of them - got back way too many hits, so I'll have to do another search when I have more time. If I find it, I'll post it here.

I'd actually be keen to have a chat if you have 15 minutes one of the days for a phone call. We've built our system thus far as flexible as posslbe and can cater for 80-90% of the bill pay plans. The prepay stuff is 60% there, though i think we can crack that with a bit more work! PM me sure if you have a chance.

Not sure what I could add, TBH. The pure Web-based solution never got beyond basic prototypes and the mobile-based one I cannot discuss contractually for about another year on pain of up to 1,000,000 CHF penalty.

All I can possibly add is that when you mentioned Excel it rang a bell, because this is how the principles in both cases began their modelling. With the former, the solution found was to effectively create the same functionality as one gets in a spreadsheet - in effect you write your own custom formulas for each plan. It makes for the most flexible solution without need to return to a developer every time some plan appears that doesn't quite 'fit'. The downside, of course, is that it's not the most efficient in terms of speed and server resources, which will become an issue if you get popular.

With regards to using a phone to collect data, I think you've probably got that covered. Back in 2010 getting the data logs was an issue if you wanted to cover pre-Froyo devices, but other than that the only major issue was related to number portibility, and you seem to have that covered with your HLR lookup.

If you still want to talk to me though, let me know by PM.

teddyr wrote: »

I think we can get away without the READ_LOGS and READ_CONTACTS permissions. These were added during development & testing on our internal phones but now look to be unnecessary.

I wouldn't worry too much about READ_LOGS, as unless you know exactly what it implies, it's not going to fire off any warning bells for your average user. READ_CONTACTS is another matter and it does frighten off users, especially when it's pretty obvious that you don't really have a legitimate reason to need it, even to the untrained eye.

When you say that the accounts permission are a blocker for installs, do you have any figures for this or is it based on experience? It would be great to understand how big a drop off we can expect as it would allow us to make a trade off.

Experience, but not my own - my knowledge of the dark arts of app marketing is limited, I'm afraid.

Kavrocks · 24-05-2014 10:27AM

Your app doesn't seem to track (or extract) mobile data usage correctly.

The more I've played around with your app the less I like it. No Prepay option is a rather major deterrent for me. Having to recheck my results every time I open the app is rather annoying due to the long wait time (which seems to have improved slightly). Having to receive an email to get the plan details instead of them being in the app is a turnoff to me too. Having to click the tabs instead of being able to swipe is annoying too. Having red lines under some operators names is poor. The UI for results isn't very clean and the multitude of colours make it quite distracting as well as not playing well together. That's all on top of the unnecessary permissions I've already mentioned.

teddyr · 25-05-2014 11:36AM

Wow, tough crowd :-)

Seriously though, thanks for the frank feedback. This is *exactly* why we went out to sites like this, to get the kind of feedback that friends and people you show the app to face to face don't give.

In general, most of the things you said are things that we have considered or are considering. We came to the realisation that we could spend the next few months endlessly polishing up the app, but decided that getting it out there to see if there is interest in it first would be better. If there is interest, then we would plan on implementing most of the things you mentioned.

While I agree with some of the UI related issues, I don't believe any of them should result in somebody not achieving the aim of the app, which is to take away the considerably complexity in understanding the cost of mobile phone plans, and delivering a tailored cost for the user.

As mentioned elsewhere, prepay is in the works. Also, regarding the wait times - obviously we'd like to reduce them as much as possible, but there are trade-offs to doing this (more servers etc). We aim to keep the times to be less than 20 seconds or so, but we cannot get away from the fact that mobile plans are complex and therefore require processing. We will take it on board though that wait times are a pain and see if UI improvements can, if not reduce the wait time, at least make it more fun. Maybe we will install the killbiller joke-o-meter we have also been working on to tell some jokes!

cormee · 26-05-2014 09:41AM

I've signed up, you should probably mention on your site that it includes data too, I don't see any mention of it, and with the likes of WhatsApp being so popular, more and more people are switching to data consumption.

Also, I got my second email, after I confirmed, there was no mention of what happens next. Might be an idea to include some details.

Johnny Jukebox · 27-05-2014 12:48PM

Firstly, congratulations on your app - its a great consumer service.

I've a background in mobile opco billing - they spent a lot of time and money differentiating and obfuscating their offers from the competition so you will have a huge challenge in digesting and understanding the different aspects of the plans and maintaining them. Also, I suspect that not all plan details are on the website - you may be directed to English languages T&Cs for the finer details.

I'm curious about the HLR look-up you are doing for each number in the log - that's usually a commercial service charged per transaction so won't it cost you (or somebody) a fortune ?

killbiller · 01-06-2014 10:25AM

cormee wrote: »

I've signed up, you should probably mention on your site that it includes data too, I don't see any mention of it, and with the likes of WhatsApp being so popular, more and more people are switching to data consumption.

Also, I got my second email, after I confirmed, there was no mention of what happens next. Might be an idea to include some details.

Hey, thanks for the feedback. We are updating the site this weekend and will be adding these details. Along with more information about how KillBiller actually calculates the output.

We've also improved the tester onboarding process!

killbiller · 01-06-2014 10:28AM

Johnny Jukebox wrote: »

Firstly, congratulations on your app - its a great consumer service.

I've a background in mobile opco billing - they spent a lot of time and money differentiating and obfuscating their offers from the competition so you will have a huge challenge in digesting and understanding the different aspects of the plans and maintaining them. Also, I suspect that not all plan details are on the website - you may be directed to English languages T&Cs for the finer details.

I'm curious about the HLR look-up you are doing for each number in the log - that's usually a commercial service charged per transaction so won't it cost you (or somebody) a fortune ?

Hey Johnny, thanks for the comments.

You're right, the calculations of costs is quite complex. However, we've come up with a decent system that allows us to put the plan allowances and costs in a spreadsheet, and a python backend system uses this spreadsheet to workout costs accordingly. This works fine as long as the plans broadly fit within a "standardish" bill pay template - limits and costs for landlines, same-network calls, etc.

The HLR system in the background only uses lookups enough to cover over 70% of the outgoing call and text messages. We find that this is generally enough to give an accurate estimate, while keeping costs reasonable. We're working on a solution to monotise the app when we have it up and running to make it at least self-sustaining.

Looking for Beta Testers for Android App to compare Mobile Costs

Comments