Countism is a mobile app idea that I have been working on and thinking about for a long time. Even though I have been thinking of the idea for a while and even did some initial work, I did not plan to actually build and release the app – that was always a question that was up in air. My initial work was really just experimental to see if it was something I could build easily enough to make it worth the effort, and to see if my idea would be viable in app form.
Well, the rest of the year, anyways. Better late than never, right?
Inspired by Justin Jackson and his Build and Launch podcast, I have decided to commit to launching at least 4 new projects this year. It’s not nearly the quickening pace of Justin’s one product per week on his podcast, but I figure it’s a good starting point. Continue reading
I just re-launched SoundingBoard as a new blog to help non-technical people learn how to evaluate their app ideas.
During my time running Brightbit (a web development studio), I met with a lot of people about their app ideas. Some were bad and crazy, but most of the ideas I heard were good ideas that just lacked the critical thinking steps necessary to determine basic viability or technical feasibility. Continue reading
In this increasingly inter-connected world, APIs are becoming more and more important as time goes on. This is especially true if you have a business that requires integration of some sort, like metrics, notifications, integrated access to other systems (like telephony), payments, etc.
Beyond Just Having An API
Just having an API is the obvious requirement for basic integrations. Going further than that, however, is the thought that your API can actually be a key point of differentiation from your competitors. Using this strategy (creating a robust, easy-to-use API) can be especially effective when you are going up against entrenched competitors, or when you are trying to make something that is traditionally very hard, easy.
Stripe And The Payments Industry
Ask any developer about online payment gateways, and they are likely to mention Stripe. Why? Because it was clear from the start that they really cared about devleopers, and put high priority in their API. Not only just creating an API – because every online payment system has an API – but in creating a very good API that is robust, simple, well-documented, and easy to use.
In contrast, many of Stripe’s competitors are using SOAP APIs or an emulation of the Authorize.net API. The API documentation typically exists only in PDF form, and it’s something that is mailed to you by the sales department. You’re lucky if you can find it on the website. Sales first and developers second is pretty much the exact opposite approach that Stripe took by focusing on developers and integrations first.
Here an example from the Stripe documentation – it’s just a simple cURL call to charge a card, and returns a simple JSON response:
curl https://api.stripe.com/v1/charges \ -u sk_test_BQokikJOvBiI2HlWgH4olfQ2: \ -d amount=400 \ -d currency=usd \ -d card=tok_14i9vP2eZvKYlo2Cdr4h0oHs \ -d "description=Charge for firstname.lastname@example.org"
Stripe did several things right here:
- Provide a simple API with good documentation
- Provide a fast on-boarding process with no red tape (rare for credit card processors)
- Support subscription charges with no additional fees (also rare)
- Target and market to developers
- Good design and nice, clean merchant interface
Stripe’s success is a combination of the above reasons as well as many other factors, but without a doubt their core product and main competitive advantage is their API. It shows in their overall developer experience, and has played a large role in their success in stealing market share from entrenched competitors like Authorize.net.
Amazon and the Public Cloud
For many, Amazon is synonymous with cloud computing. Many web hosts selling vitrualized servers came and went before Amazon got into the game, but no one besides maybe DigitalOcean has had a similar level of success doing so.
From the start of Amazon Web Services, Amazon made it clear that they were a platform for developers to build on top of, and provided an API from day one. So while many other virtual hosting providers existed, Amazon EC2 was one of the only ones that developers could use to provision whole new servers with automated scripts and zero manual intervention. The availability of APIs to provision servers lead to the creation of businesses built on top of Amazon’s infrastructure, like Heroku – who probably wouldn’t exist without Amazon’s APIs.
Rackspace, a much larger web host and significant competitor, didn’t launch a public API until years after Amazon did, but it was already too late, and they gave up significant market share to Amazon and Google Cloud Engine. Amazon’s API was its killer feature, and key differentiator. And we all know how well that has gone for them.
Twilio And Telecommunications
Twilio is a good example of a company using APIs to make something that is normally really difficult very easy. Now you don’t have to worry about which cell phone network the number you are texting belongs to, what country it is in, etc. Just integrate with the Twilio API, and you know it’s going to work.
For Twilio, their API is their entire business. There is no Twilio without an API, because if Twilio was just a web form that sent a text message to any given number – even if it still smoothed over all the carrier and location differences – it would not acheive the goal of automation, and thus would defeat the purpose.
In the years since Twilio launched, countless companies have relied on it for things like 2-factor authentication and phone number verification via SMS. Twilio can even power your entire phone system through tools like OpenVBX, all with a collection of REST APIs.
The Bottom Line
If you don’t have an open REST API that is easy to use, you will lose market share to a competitor who does. It’s time to start taking your API very seriously. An API is a competitive advantage.
I was recently part of a project where, upon asking for content for the requried “Frequently Asked Questions” page, I was invited to a meeting with the objective of “brainstorming content for the F.A.Q. page”. It was painfully ironic. How can we possibly list frequently asked questions when we haven’t even launched yet and no one has asked any questions?
The meeting (video conference call) started, and I decided to stay silent for a little while to see how the call would play out. The project stakeholders begun by going over the F.A.Q. sections on a bunch of other websites, and compiling a short list of all the questions they would need to write answers for. The list included things like “How can I contact you”, and “How can I reset my password” – questions that will likely never be asked unless your UI/UX is terrible. Continue reading
Last night, I decided to pull my two iOS and Android apps SEMTab SEO Pro and my very first app, AutoRidge Lite from the App Store and Google Play. It was a difficult decision to make, because they were my first two apps, and I now have no published mobile apps to show potential freelance clients when they ask for app examples. This does limit my options, but now is a great time to make this move since I just started a full-time long-term contract and won’t be actively looking for extra work right now.
With the recent shutdown of my company, I feel like I’m writing a new chapter in my life. Having any app in the app store just to say I have one is no longer enough. The bar is higher now. I want a high-quality, well-rated app that people genuinely like and want to use. I want something I can really be proud of. It doesn’t have to be complicated or difficult, or even do anything fancy. It just has to look good, and do one thing well — and not crash randomly. Difficult task, I know.
What A Bad App Looks Like
To provide an example of the kind of results a bad quality app will give you, look no further than my own app – my only paid app – one I just pulled from the stores – SEMTab SEO Pro. This app was ill-conceived and hastily crafted. The UI wasn’t thought out very well, and neither was the stability of the source data. The code I used to fetch Google’s PR ranking was frequently wrong (I apparently used the wrong black magic incantation to summon the accurate result), and link counts from Facebook and Twitter were different than what were reported by other (more accurate) tools and by the platforms themselves (turns out the API I used was way outdated).
On Google Play, SEMTab had an abysmal rating of 1.6. This is primarily due to the app crashing or just plain not working on a few Android devices that I was not able to test on, or were not actually supported (like the “Rubbish” review you see for it not working on the Galaxy Tab – one of the first Android tablets that liked to pretend it could run normal Android apps just fine).
On the App Store, the app was a lot more stable, but still got a bad rating for its terrible accuracy.
The app was $1.99, and was on sale for $0.99 for an extended period of time to try and boost sales. Obviously, this strategy doesn’t work if your app sucks and has a bunch of bad ratings.
Google Play Revenue
App Store Revenue
A whopping $127.19 from Google and $83.01 from Apple, for a grand total of $210.20. In 4 years. Ouch. Totally not worth the (admittedly small) effort I put into it.
Why I Pulled SEMTab SEO Pro
The reasons here are prety obvious, right? At this point, the ratings and performance of this app are so bad that I don’t even want it in my portfolio. I didn’t even want people to know I made this app, and was a bit embarrased to mention it whenever the “what apps have you made?” question came up, fearful people would see the terrible rating read all the horrible reviews. Good riddance. (And if you’re wondering why I am publicly sharing all this now, it’s for accountability – I never want to make an app this bad again.)
What a Mediocre App Looks Like
I am definitely more proud (or, at least, not embarrased) by my first app – Autoridge. I was a lot more torn about taking down Autoridge than I was about SEMTab. The reviews of Autoridge basically boil down to this:
- The people who used the app and found relevant data for their vehicle’s year/make/model loved it. It provided huge value for them.
- The people who could not find their specific vehicle’s year/make/model, or didn’t find any (or very few) relevant parts for their vehicle mostly trashed it as incomplete, inaccurate or unreliable.
Poor Early Titanium Android Support
And as in the case of SEMTab, there were also quite a few Android users that the app didn’t work for at all (freezing or crashing). I mostly attribute this to the very poor early Appcelerator Titanium Android support. Both these apps were developed and released at least 3 years ago on Titanium versions 1.5.x – 1.7.x, and a lot has changed for the better since those dark ages with Titanium (we have have an MVC framework called Alloy, and Titanium is at 3.2.x). From my experience with Alloy, I am positive that updated versions of these apps would elimate all the problems on Android.
That said, it’s pretty disharenting when you develop an Android app with an intermediate platform like Titanium, test it locally with your own Android device and emulator working perfectly, and then release it to a tsunami of 1-star reviews and reports of random freezes and crashes on various Android devices that you can’t do anything to fix.
On Google Play, Autoridge Lite had a very average rating of 3.1. I am actually suprised it was this high with the number of ratings reporting freezes and crashes, but like I said, the number of people who it did work for generally loved it. You can see this wide rating distribution reflected in the data. This saddens me a bit, because the rating could have easily been 4+ in Google Play if it worked consistently across all Android devices.
The App Store rating was pretty much the same story, with all the negative reviews questioning data completeness and accuracy:
The uptake of Autoridge Lite surprised me from the start. It definitely seems like something people were ready to embrace if the data was more accurate, complete, and up-to-date. I think overall, people really like the idea of using an app instead of flipping through a greasy old parts book at the auto part store.
App Store Distribution Units
Google Play Installs
According to Google, there are still 1,584 devices with Autoridge Lite installed. Definitely far better than SEMTab SEO Pro that had only 12 active installs. A lot of people still like this app.
Why I Pulled Autoridge Lite
The decision to pull Autoridge from the App Store and Google Play was much harder than with SEMTab, but ultimately, it came down to an issue of time, energy, and focus:
- Autoridge Lite has a webservice backend that I also built and maintain, and this costs time and money.
- The vehicle data has a low degree of accuracy with no automatic error correction, and would take a significant re-investment of time and energy to correct. I would have to research new sources of auto part information and build web scrapers/parsers for each of them, as well as implement better processes for checking for updates and invalidating bad data.
- I want to completely re-code the app, and have wanted to for a while. So doing this plus all the webservice updates too would probably take longer than the original 2 weeks the entire project took initially. And since I can’t update the app only without fixing the data accuracy issue, I have to consider the whole picture.
In short – it would take too long to re-build the right way, and I don’t currently see it as worth the effort considering I haven’t made any money from it (and don’t see any path to make significant money from it ever as a one-man show).
Although this choice was tough, and arguably should have happened a long time ago, I am happy to be doing it now. The first step towards finding something that works is identifying and eliminating the stuff that doesn’t. The worst thing that can happen is to split your time, energy, and focus across so many projects that you do them all badly. This is exactly what I feel I have done. I want to be able to focus on my next project, I want it to be high-quality, and I want it to have a clear revenue path. This whole “making money with software” path is not an easy one, so I want to give myself the best chance possible by concentrating on the next big thing, and making a better product than I’ve ever made before. That’s what this move is all about.
InvoiceMore, the startup I have been working on in my spare time for over 7 months, has finally launched. This post actually comes a bit late to the party, because I actually launched InvoiceMore at OpenBeta on March 12, 2009 and blogged about it on the Actridge blog that day. I haven’t even had time to thinkabout sitting down to write this post on my personal blog about the launch until now. That’s a testament to how crazy busy my life has been since I decided to pour all my spare time into starting a business. So what is InvoiceMore, and how is it different?
moreInvoiceMore is an online billing and invoicing application aimed at freelancers and small businesses. It basically provides a super-simple web interface for creating and sending invoices to clients and recording payments for them. You can email and generate PDF invoices, print and snail mail them, and just keep track of your clients and their payments in a really easy and intuitive way. It was created based on my experience from a different billing application I created to fill my own client billing needs for freelance and contract work.
A lot of people ask me why I made InvoiceMore, and how it will be any different from what’s already out there on the market. If you’ve ever used an online billing application, or currently are using one, InvoiceMore works much the same way, with one major exception: Recurring billing. All of the online web-based billing applications I have come across so far do recurring billing the same way: a “recurring invoice template” that has a recurring interval set on it, like “1 month” or “2 weeks”. The problem is, if you have a client with multiple recurring services at different intervals, you have to setup multiple recurring invoice templates, and your client ends up getting more than one invoice per month at least a few months of the year.
Clients don’t ask for recurring Invoices. They ask for recurring products and services. An invoice is the natural end result of the products and services they buy. Competing billing applications make you create and setup what should be the end result: the Invoice. So to solve this problem, I built recurring billing in InvoiceMore in what I believe is a much more natural way: the products and services themselves. So with InvoiceMore, you associate products and services with clients and pick a recurring interval for that association. Then every billing cycle, invoices are automatically generated for that client from the recurring products and services that are due sometime within that billing period. You end up with a single invoice with everything due on it instead of multiple “recurring invoice templates” that are generated and sent independently.
So if you’re interested in learning more, you can try InvoiceMore out for free, or just read the information on the website . Let me know what you think in the comments here, or on the official UserVoice page for feedback and ideas.
I’m a big fan of Google Analytics. The service is free, can go on multiple websites using just one account, and displays and processes stats beautifully. But the one thing that’s always annoyed me about Google Analytics is the default dashboard setup when you create a new website profile.
The dashboard is the place for the most important things to be. it should be the single place you can view to and get an overview of all the most important things about your website regarding your visitors without having to drill deeper or go through multiple pages or sub-sections. But the default dashboard Analytics starts you off with is all wrong, and is almost never the information I really want to see. Let’s see how we can fix this. Continue reading
I am currently working on my own little app as a side project (who isn’t these days?), and I have determined that I’m close enough to launch that I needed to start generating a little buzz and getting at least a few interested people to signup for a limited closed beta test before it launches. Problem is, I consider myself much more of a programmer than a designer, but I still wanted the splash page to look good and get visitors familiar with the brand I was trying to create. For that, I needed a logo. So while I don’t really consider myself a graphic designer, I went ahead and followed David’s advice on the 37signals blog about doing it yourself first. And man was he right.
Just when I was seriously considering spending some of my own hard-earned cash on a logo by a professional, holding a design contest, or taking on a design partner, I instead took about 3.5 hours out of my lazy Saturday afternoon football watching to attempt to make a logo for my app on my own. I had the basic idea in my head of what I wanted it to look like, but I know that most of the time what I picture in my head and the end result rarely look even close to the same when I am the designer. Sometimes that’s okay. The end result logo (pictured) actually ended up looking very much like I had pictured in my head, and (at least in my opinion) looks great.
So with a few hours on a Saturday afternoon doing it myself first, I managed to save myself at least $300 and a few days waiting for the end result. Moral of the story: Always do it yourself first!
After anxiously awaiting a response from David Walker, the TulsaTechFest conference Director about an open speaking spot, I just about fell out of my chair today when I finally got the email with a confirmation that I was going to be presenting. I am very excited about this amazing opportunity, and have already begun putting my speech together. Here the topic info:
Procedural to Object-Oriented: The Benefits of Using Object-Oriented PHP
Learn the power of object-oriented programming in PHP5 and the many benefits it offers over the more traditional PHP procedural programming style. This session will include a light introduction to object-oriented concepts and will provide real-world concrete examples of the benefits it can offer you and the PHP projects you work on.
I will be speaking on October 9th at 2:30pm, and the presentation will last for roughly 75 minutes (60 minutes to speak, and 15 minutes for Q&A). That’s a good chunk of time to fill, but there’s a lot on this topic that will need to be covered. If you’re thinking about getting into object-oriented PHP programing or would like to learn more about it, please attend. I will try my best to make sure there is at least something that everyone can learn.
You can also view my page on the conference website to read a short biography and get more information on the event. Hope to see at least a few friendly faces there!
P.S. – I plan on posting my presentation slides on this website after the event just in case anyone missed anything important or was unable to attend.
UPDATE: The conference is over, and I have posted the powerpoint slides in another post for those that are interested in the presentations I made.