We don’t believe in hourly rates, here is why:

• It creates an incentive to “waste” time and take longer on a project. It leads to over estimating the timelines.
• It takes advantage of the “knowledge gap”. If the developer says its going to take a little longer than expected, how is the client going to be able to refute this claim knowledgeably?
• As much as it’s growing, the mobile app development industry is still in its infancy. Most of the apps that we work on need a certain level of R&D. We do our homework before making promises, if we know your product will take some figuring out, we will let you know. We don’t believe our clients should pay for the early stage in which the mobile app industry finds itself.
• QA testing. We believe that the client should never pay for making sure that our work is done right. If we promise certain functionality, its our responsibility to make it happen.

So, what do we do instead of hourly rates?

Milestone payments. Milestones are about accountability and value. We typically ask for the first payment upon reaching an agreement. This shows us that the client is serious, committed and invested in this project. As we have shared before, client commitments are an integral part of developing an iPhone app or developing an iPad app.

From then on, the payments are to be released on meeting the following milestones:

• Completion of the Architectural phase
• Completion of the Design phase
• Completion of the Development phase

Milestones allow us to exchange money at the point of value creation and never on an arbitrary time measurement. To date, this method has worked very well. All of our clients have been fully engaged in the process and we have never had to change our quoted price.

To learn more about how we price apps please see our “Pricing” page.

We want to say thank you to all of our amazing clients. Thanks for trusting us with your vision and for always working with us and being open to our out of the box approach. We look forward to serving you in the new versions of your apps.

Check out the press release at MarketWatch

Thanks to SourcingLine and to the entire Ebbex team.

However, the following questions are almost always asked in the process of defining your app’s feature set:

• Is everyone going to understand how to use this particular feature?
• Should we include some explanation text?
• Should we change the layout?
• Should we increase the font size?
• Maybe we should change the design so it looks like the settings app, everyone knows how to use the settings app right?

All valid questions. But somewhat off point unless they are framed within the knowledge that, despite your best efforts, you will never be able to please everyone. There are many ways to answer a question, but not all of the answers are correct.

So, what’s so wrong with finding answers to every single issue? We want to make a great app, right? We do, but not at the expense of losing the app’s magic. We want to parade our apps’ sex appeal, not hide it under too many details. If we provide an itemized solution to every potential snag in an app’s feature set we’ll end-up with an instruction manual rather than an app. If we try to accommodate all the needs of every likely user we run the risk of diminishing the overall user-experience. And why would that be? Because we wanted to please everyone. In trying to explain a particular feature to a minority, we diminish the experience of the majority.

It feels counter intuitive at first, but quality apps are purposefully designed for 80% of potential users. Embracing this paradigm promotes innovation and stunning UIs.

So how do we avoid falling into the pitfall of pleasing everyone?

Easy. Create an app definition-statement. Apps are not a combination of features, but rather a specialized mobile solution to a specific mobile problem/opportunity. An app’s definition-statement works as the guideline for most architecture and design decisions.

Your app’s definition-statement helps you understand who your primary and secondary users are. Who are you making your app for? What is their age group? Are they a particular interest group?

Think about it this way. Let’s say you are developing a social media photography app. Will older users get confused by the swipe navigation feature? Maybe. Will my young tech-savvy users like a swipe navigation feature? Definitely. We should always focus on answering the second question, focus on our primary users, focus on the 80%.

Have a minimal feature set.

The app store is maturing and the bar is as high as ever. As a development community, we need to be bold and continue to produce great looking and easy-to-use apps. We encourage you to design for only 80% of your users.

That’s what the blogosphere has been asking iPhone users and iPhone Developers since Realmac Software announced their “Clear” app for iPhone. Now that Clear has been released, the question remains. The only difference is, this time we’re asking the question while we play with Clear’s gesture driven interface.

The app store is maturing. What once would’ve been considered segment saturation, has now become an opportunity to create something beautiful. How many to-do lists can the market support?  How many alarm apps? How many games about zombies? “As long as there are more iPhone users, there will always be room to build one more alarm app” was what people used to think. We can no longer think that way, volume over beauty, regarding potential users over an app’s value. Well, not anymore. The people at Realmac Sotware have clearly built their company (and their apps) around their “we make pretty things” credo, and other iPhone developers are following suit.

Do we really need another to-do list app? Specially when we have the awesome Siri-integrated native Reminders app? We don’t need it, no. But we all want it.

There are 2 types of in-app purchases:

1 Paid app with In-app purchases, accounting for 24 percent of total App Store revenue
2 Freemium: Free app with in-app purchases, accounting for 48 percent of total App Store revenue.

As welcome as this new is, the Ditismo report had one more surprise: It states that only 4% of all apps feature in-app purchases. I also had to read that line again, it means that 72% of all revenue is comes from just 4% of the apps.

There is a huge opportunity here as money is being left on the table. The only one happy with this scenario is possibly this guy.

Whether you are planning to launch a new app or publish a new version of your existing product, the in-app purchase method deserves your attention. Give us a call and let the Ebbex team help you with this important decision.

Our Front-End Approach to app design and development includes the Discovery Meeting where we will talk about your organization, your clients and your business model and how to best translate it to the mobile space. For instance, if you are thinking about a freemium model, we will consult you on what type of freemium model to use. Whether adds vs. no adds, additional content or expanded features,etc.

These statistics are not yet a guarantee but as the iOS world grows and becomes more mature, these stats can be corroborated. If they prove to be correct, we might soon live in a freemium world where developers get paid to create exclusive and rich experiences for their users. I know at least one guy that would love this set up.

There will always be a design tweak to make the app more beautiful. There will always be a navigation adjustment that can make the user experience better. You will always learn about another feature suggested by your users that you hadn’t considered.

Apps can always be improved due to a concept we call “The Verdict Volume”:
-1000 users can “test” the app in one day equaling 1000 “tests”
-It would take a QA weeks or months to run 1000 “tests”
Therefore, the best way to fully test an app is to release a first version and let the volume of your users give you feedback as to what needs to be improved and/or added.

The iterative process of building an app includes real user feedback. Think of an app as a living organism that grows and morphs. Think of an app’s version release as a snap shot in time, like the notches on the wall as a kid grows.

It’s not perfection itself, rather, the” pursuit of perfection” that drives innovation and quality user experiences. Our job as app designers and developers is to work with you to constantly close the gap between a current version and the mythical concept of perfection.

Building a reputable, dependable and beautiful app takes time; that is why its important to choose a design & development partner instead of a one-time provider. Give us a call to see if we are a good fit for your project.

If you look through the iPhone or the iPad’s settings, you will see that Apple strives to minimize the amount of explanation text. Instead, they rely on an intuitive design and smart users to make sense of the settings.

Apple has already laid the groundwork to educate the users on the iOS. Users already know how to navigate, change settings and use most apps, in general. As developers, we need to trust Apple and trust our users. There is no need to over-explain the purpose of each screen if we have designed a good User Experience that takes Apple’s “Human Interface Guidelines” into consideration.

In fact, over-explaining is counter productive, as it achieves the opposite outcome. Over-explaining leads to crowded screens that diminish:
-The general esthetics of the app, as it compromises spacing and design.
-The intuitive user experience. Instead of relying on normal Apple buttons and controls, over-explaining states the objective of the screen twice, thus confusing the user.
-The efficiency of the project, overall. Writing takes time – especially when we write more than what is needed.

So what is the right amount of explanation copy? Well, it depends on the particular app and the particular screen. A medical app, for instance, will need more explanation text than a utility app.

Nevertheless, a great place to start is to go through the “settings” app on the iPhone and iPad. Observe how each objective is communicated with little or no copy.

For example, this screen does not need to say “Use your finger to adjust the dial to the desired brightness level…”

If you want to chat about the usability of your app, give us a call and we can schedule a time for an in-depth review.

Initial Vision Casting Conversations

As an app development company, we know the right questions to ask, but nobody understands your business, your mobile objectives and your app like you do. Therefore, taking your time and explaining your vision to us is of the upmost importance.

Brand and Design Assets

Your app will be an extension of your brand. The User Interface design will be congruent with the themes already present throughout your brand. As a client, your responsibilities will be to grant us access to any design assets that you might have for us to use.

If your app is the first product/service offering of your company, we can work with you to create your brand. Ask us for examples.

Copy

The copy is the personality of your app. Is it factual and to the point? Or is it witty and smart? No one knows how to write about your product better than you. Providing us with the copy is a crucial and iterative step that is needed for the design stage. If we know how many words go on each screen, we can lay it out in a clear and well-organized manner.

While the decisions on copy are yours to make, we will give you advice on how to better structure the copy within each screen. For instance, short instructional text at the top of the screen is advisable, and an “i” information tooltip is the best place to give more in-depth instructions.

Revisions & Comments

You will constantly receive work from our side for your comments, feedback and, ultimately, your approval. A quick revision time is needed in order to not lose momentum on your project. We usually ask for a 24 to 48-hour time period for revisions.

Testing

As the coding phase comes to an end, we will release test builds to your iPhone or iPad. We believe that even the QA process is cooperative: the more set of committed eyes on the app the better. You will receive simple instructions from our side on how to perform thorough testing and how to report the results back to us.

Testing is a very enjoyable process since you can begin to see the fruit of months of hard work. It is normal to have many test builds before settling on a final version to submit to the app store.

Deployment

During the coding phase, we will send you a questionnaire that will help you define what you want your iTunes page to say. This, again, is an iterative process, since getting the copy right for the conversion page is important.

Communication

Ebbex is fully committed to any project we take on.  As part of this commitment, we promise to always communicate and keep you informed, regarding your app. An open line of communication from your side is the most crucial of your commitments. Every project has its unforeseen challenges and its unique difficulties; the solution is always found in good communication.

Setting a well thought out deployment strategy for your app is as important as deciding upon the correct feature set. There is a common misconception which states that apps should be deployed to the widest audience possible by building for multiple applications. This broad approach seems to make sense initially, but it is actually a detrimental deployment strategy. We recommend deployment of the first version of your app for one platform only: the iPhone.

Reasons for a one platform deployment:

• Lower initial investment
• Faster time to market
• Easier design and development process for both the client and the provider
• Creating an app is a very collaborative process and working on 2 or 3 platforms at the same time can be a challenge
• Easier to manage and provide customer support
• Easier to justify an investment on the next platforms
• By deploying on one platform first, you will have a faster time to “verdict”
• You will have a measure of success including what features had a positive response, which ones didn’t, as well as beginning to get a sense of what features the following versions could have

Reasons to deploy on iPhone first:

• Highest standard when it comes to design and user experience
• Android platform supports a diverse number of hardware devices
• This makes the design, development and testing processes longer,since each device has different graphical and technical specifications
• Easier to port a finished iPhone app to Android, rather than vice versa
• Creating a great user experience on the iPhone is generally harder than on the iPad, due to the screen real estate
• If you have a phenomenal iPhone experience, creating its iPad equivalent is easier than starting with the iPad and then moving to iPhone

Caveats:

Depending on the subject matter and the size of the company, multiple platform deployment might be advantageous. For instance, an established company with an existing brand, product or service might opt for a mobile strategy that has an iPhone/iPad deployment. They might even opt for an iPhone/Android deployment, if such company has enough resources and support to allot to the project.

Our objective is to find the right solution for you, even if it means less business for us initially. We strongly believe that developing an iPhone app first is the most efficient way to enter the mobile market. When and if the time comes, we will talk about developing a version of your app for other platforms. We are happy to say that 100% of clients who have chosen to deploy for subsequent platforms, continue to choose us as their developer.

So what should your deployment strategy be?

• Do you have an established brand and a team of people committed to the project?
• Does your general business plan call for multiple platform deployment?
• What is your estimated time to market for your app?
• Does deploying for iPhone first make sense for you, your company and your app?

These are very important questions that will set the tone for your project; like always, finding the right deployment strategy begins with a conversation. Give us a call, or write us an email, and lets schedule a time to talk.

Naturally, we agree. If your app fails to address a specific need, an extra set of features will not make it more or less successful. For this reason, we work with our clients to pinpoint their app’s value proposition.

Discovering an app’s minimal feature set is productive in many ways:

• It shortens the app design and development process, thus getting your app to market sooner.
• It simplifies the app’s message. You can answer the question, “What is this app for?” in one or two sentences; therefore increasing your chances to connect with and market to users.
• The cost is lower when compared to a more expansive feature set.
• The feedback loop from users is clearer. You can easily figure out the reasons for users who like or dislike your app and make changes or additions accordingly.
• Releasing future app versions becomes easier. If the minimal feature set Version 1 of your app is successful, investing in added features and functionality is almost a no-brainer.

The MVP concept, or Minimal Viable Product, is another way to explain the minimal feature set. Entrepreneur Eric Reis (http://bit.ly/olte7b) defines the MVP this way:

“So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.”

If you are serious about creating a quality iPhone/iPad app, drop us a message or give us a call, and we will share a simple exercise developed to help you discover your app’s minimal feature set.