the better bunch

“The better bunch” is a digital development company specializing in mobile apps for iOS and Android. We do app design and development for smartphones, tablets, watches and TVs, both front- end and back-end. The staff consists of a dozen professionals and we have a very large network of external talent for larger projects. Our primary methodology is scrum, and we particularly pride ourselves on the quality of our design.

I am the CEO of the company. On the development side, my primary role is making sure that the team we’ve put together is a good fit for the client, both on emotional and technical levels. I am also heavily involved in sales, again, making sure there is synergy between us and the upcoming client.

There are several stages that comprise the development of a mobile product: analytics, wireframing, design, coding (front end and back end if applicable), QA and publishing. In theory, these stages occupy more or less the same percentage of the time from project to project. Yet, in reality. certain stages demand much more investment than one may assume.

For instance, the time frame increases significantly if the client wants a lot of iterations for design. Or take back end – if it is developed on the client’s side and/or it’s not ready before the front end development the deadlines may suffer immensely. Front-end coding, on the other hand, rarely causes any problems, unless you deal with legacy code, which is code that had been written by someone else and now has to be rewritten. If it had been done badly it may be cheaper and faster to do the code from scratch.

In other words, any aspect of work that cannot be fully controlled (client’s wishes or third party actions) may jeopardize the timely completion of the project and should therefore be considered as potential risks right form the beginning. We always warn clients of such risks and suggest ways to minimize them.

We deal in man-hours, but what we sell is trust, confidence, and peace of mind. We want our clients to see that their time and money are appreciated and managed wisely. And we want them to know that we always have their interests and the interests of their product in mind and they can lean on us and consult us when it comes to tough decision-making.

We’d like to think that this personal and product oriented approach is what sets us apart from the competition. As one of our clients said, "Their project management is very good and they're very proactive. A minimum amount of information will take them a long way."

The ground rule for business in our case is making sure that the client receives a finished market- ready product within the time frame and the budget we had originally discussed. That’s our prerogative: deliver on the promise and meet the expectations. It’s business 101, but in development it is often very hard to do that: things go wrong, unexpected issues arise, third parties get involved etc. That’s the reason why it’s often difficult for development firms to deliver according to the original arrangement.

Which is why we pay so much attention to risk management and forecasting. Yes, sometimes, you need to make sacrifices in functionality or iterations, but if the client takes part in this decision making and realizes that these actions are aimed at meeting the deadlines and staying with the budget limits they appreciate that

In my opinion, there is just one criterion - the user base. Like in any other business you have to think here about your market first. If you know that 70% of your user base is Android, there is no need to develop just for iOS. The other thing that needs to be considered is the budget. If you are just rolling out, you would want to make sure that your idea and your business model are viable. You go ahead with the majority of your users. So, if there are more of iOS users but you need to develop for Android sometime in the future, you should go ahead with iOS first.

They should first do some market research. We would help with the research but that’s not our primary job so we would point at the right marketing specialists. Other than that if the client is launching an app business in a particular area, they already know the use base for that niche, so they already have a good understanding that which platform dominates.

First of all, we do pre-analytics. We have a conversation or two with the client making sure that we understand what they want. Then we move on to the personal side of things since the context behind the development are usually different: some clients have pressing deadlines (say, they have to put together an MVP before their next board meeting or their next grand proposal); some clients have a very strict budget and want to stick to the price, but care less about the duration.

Sometimes, the client is very enthusiastic, doesn’t have the time or budget constraints, but knows nothing about the mobile market. In this case, we suggest them to start with a very basic app and do some hard-core marketing training in the field when their app is already published. Once they have a taste of it and if they are happy, they can come back to us. Once again, we have great respect for our client’s money, time and efforts. We don’t want them to suffer and make wrong decisions.

Hence, we put together a proposal based on the functionality and the client’s actual needs. An example of this would be, if the client is limited with money, we wouldn’t necessarily develop the back end, but would insert all the content in the app. No server-app synchronization in this case, end but the goal is reached, the client has the app published and to end users it looks finished. In the estimate itself we have functionality breakdown by modules, the number of employees that have to be assigned to each module, comments, number of hours, rates per hour and the total sum.

We follow the Time & Material payment structure. In our opinion, that’s the best way to go since the client doesn’t need to pay large amounts of money right away. We follow two basic versions. One is that we decide on the sprints and the client pays once we deliver the results of the sprints. The other case is where we limit not the amount of functionality, but the number of hours per month, so that the client doesn’t overspend their budget. In either case, when we start with a new client, as a demonstration of good will and serious intentions, we ask for a pre-payment of 10%. Usually it’s not too much and covers the first iteration or so.

Generally we keep a minimum of 12,000 US$ to 14,000 US$. If it’s just the design, the cost may vary between 4,000 US$ to 6,000 US$. The maximum we have gone up to 200,000 US$ which was a project that lasted for about two years.

There are two basic kinds of apps: apps that are business units by themselves and apps that are interfaces for an existing business, online or offline. Recently, it has become very difficult to generate revenue for apps that are independent business units since the market is so overcrowded. Recent studies show that the best kind of business you can build with apps is when they are part of a bigger picture - you diversify your risks and sources of income. This is something I would suggest.

Yet, if you do decide to go with your app as a separate business unit, I wouldn’t suggest advertising since you have to have literally millions of users to make this worth your while. A good way to go would probably be the “free to play” model with subscription: a free basic version of the app, paid upgrades and paid subscription. Of course, in this case, you have to really kill it with the quality and the value but if you do, you have a sustainable business that generates income each month.