Yeah, cost was the issue. This is a free service, but just getting a text short code costs thousands of dollars and runs in the hundreds of dollars per month (at least) to maintain the service. Then the text service only works for US-based users.
There are other shortcode SMS -> web app services out there, but they require really obscure codes, where you'd have to memorize/store 50 bizarre characters.
Instead of having a dedicated text receiver, why not just rely on email? Any phone should be able to fire off an email instead of a text message. Any time I send a text message to an email address, it does get converted from a `text` message to an email message.
In order for the server to figure out who the mail came from, the end user will have to setup their Fuelly account to accept the phone number thats sending the message out (IE: email@example.com).
Then its up to the server to figure out what the user wants to put into their database.
Spam won't be an issue either, as the senders email address has to exist on the Fuelly server. If the message senders email address doesn't exist, the message is just dropped to /dev/null.
If it passes, then its a matter of looking for keywords, like a series of numbers, and a `unit` Fuelly understands. To be considered `valid` prior to being incorporated to the database, each fill up has to be done on a single line, and at least 2 criteria have to exist (Just as the existing web page). Anything else is discarded.
Even at THAT point, to maintain validity of the data, the user has to come online to the Fuelly web page (Think advertising) to actually accept the data sent. The web site would say "I received this text message from you on this day, and this is how I interpret the data. Is this all correct?". If the user says YES, then it gets inserted.
If a user requires help while on the road, sending an email to something like firstname.lastname@example.org would fire off an email to the recipients cell phone containing the formats, units, and options per fill up.