Interview with Digital Brand Group (DBG)

Please begin by introducing your company and your role there.
Our company is Digital Brand Group. We were founded in 2006. I’m Jeremiah Jacks, the founder and CEO of the company. DBG specializes in developing custom software applications. In 2006, we were purely Web-platform development specialists but, in the middle of 2008, with the launch of the App Store, we started getting into mobile application development, and now that makes up about 80 percent of the projects that we're working on. They're all mobile first and typically will also have a Web-based platform along with them as well. That makes up the majority of our work these days.

What are the key drivers of platform choice for a mobile app?

The key drivers to determining the right platform to go after should start with a discussion about the business and what are the ultimate goals and objectives. That would include everything from understanding who the user is, to whether it's an application that would be freely downloadable, or something that has an area of monetization. It's important to know these factors because they all play key roles into what platform should be targeted initially.

Some companies that have funding, simply say that they want to get as much mass adoption as possible, so they go with iOS and Android right out the gate. But, most startups and companies that are developing mobile apps for the first time, typically want to tiptoe into it, so they'll decide one platform over another. 

Is there a general preference for developing iOS first or Android first?

Most people tend to lean towards iOS, simply because they think it's a more popular platform. The reality is that iOS is a platform that is popular predominantly because it's very easy for consumers to integrate with the App Store. Those apps on iOS actually tend to generate more revenue for mobile app developers than do the ones on Android. So, companies are leaning more towards the iOS as the platform versus Android for that reason, from what we've been seeing. 

But, if your application isn't one that has a huge revenue stream, then sometimes the better choice would be to launch initially on Android, primarily because there's way more mobile adoption on Android than there is on iOS worldwide. However, the typical annual household income of the Android user is a bit less than an iOS user, so the consumer there is a different type of consumer spend-wise. 

If I were, for example, to develop an application that was a big community type platform that didn't really have any area of monetization, but I wanted to generate as many downloads as possible, then I would most likely launch it on Android. If I were to develop a game application that had a monetization of maybe a $0.99 or $2.99 per download and then inside of the app there would be in-app purchases, I'd probably lean towards iOS because the user on iOS is actually more likely to spend money and continue spending money than an Android user. 

So, taking all those things into consideration will play into why you choose one platform compared to another but, again, all those are really tied to what your business model is, how you make money, and how you are trying to be perceived out there in the marketplace as well, ultimately. 

What about hybrid or Web-based apps?

Yes. There are many platforms out there outside of Android and iOS that are just Web-based platforms. There are solutions, such as PhoneGap, SensaTouch, and many others that actually allow mobile app developers to create their applications in HTML5 and right out the gate, have an application that can sit on both Android and iOS. So often, that's a more desirable approach if it's not a monetization platform and the application doesn't have any really complex core functionality that might be limited by an HTML5 sort of Web application.

Are there any specific use cases that work especially well for hybrid apps?

A hybrid solution that we found was useful for companies is an application that's for retailers, actually. You might think it might be easier to develop a native application to allow people to buy and sell products, but there are some retailers that just don't have the amount of money that it would take to build a native iOS app in objective C and a native Android app in Java. They typically have a smaller budget because they're sensitive on price and their budgets are driven by the amount of profit they generate from their online channels. So, they'll typically say, "Alright, we already have a responsive website, let's make it into a mobile application using one of these PhoneGap platforms that are out there." That's often a really good reason to use a hybrid platform. 

Another really good reason to go hybrid in order to get the adoption on both iOS and Android really quickly is if you're developing a brochure website or an application that doesn't have a lot of user interaction that's required or a lot of core functional requirements because, in those cases, you just have to worry about the application loading the content from a website. 

One of the big drawbacks in hybrid applications is that because, by nature, they're based on the Web, they actually require the bandwidth to be suitable enough to render in the browser, so what happens many times is that the user experiences latency or slowness in the speed of the application and reaction time, and so that's why often companies will opt for native applications compared to hybrid Web-based ones. But, there are certainly many scenarios where the cost and especially the reason behind the application make it attractive to go for a hybrid solution.

So, does Digital Brand Group offer both hybrid and native apps? 

We do build hybrid sort of applications; most of our customers are startups and entrepreneurs and companies that are developing applications as their core intellectual property and, as a result, they typically put more functionality into the applications and functionality that specifically would benefit more from a native sort of environment. So, the majority of the work that we do is native application development, but we do our fair share of hybrid application development as well.

What are the key drivers of cost for building a mobile app?

We generally recommend an initial discovery or requirements analysis phase, and there's usually either a fixed cost to that or the company will engage on a time and material basis. At DBG, we offer both options. If a customer is sensitive to cost, then we'll typically try to drive out of them as many requirements of the application as possible, and then will agree and will mutually move forward on a fixed cost. However, it's often more desirable for a development company to work on time and materials so that we're not worrying about whether we're over or under on a project. However, on the flip side, time and materials is not desirable for most customers because it's often perceived as a project that could never end nor has an unlimited budget.

One key driver of cost is the level of the application's usage, or how many users are expected to use the application in the first few months. You'll have to make sure that you build in adequate time and resources for a testing all the various scenarios and functionality that the application should work under. Let's say someone expects the application to perform under a million users. You would have to simultaneously test out all the different usage scenarios under stress. So, you would need to define how much time will need to be spent on the application for quality assuring it on a performance level, on a functional level, and even also on a security level. So, identifying how many features and functionality in the application upfront are really going to be critical in determining the drivers for cost. 

Usually what we recommend for applications, especially for the very beginner customer, is that they'll identify the minimal viable product, which is essentially an application that has the minimal amount of features and functionality required for you to get to market and start your initial user testing. The way the app performs in the market would then ultimately drive the rest of the features and functionality, pulling certain things back or adding certain things or changing up certain things. So, it's really important to make sure that initially you do actually build with that minimal viable product mindset. That way, you're limiting the amount that you have to spend, because you're limiting the amount of the features and functionality. Also, with the minimal viable product plan, you'll come up with an initial test group, so you don't have to worry about launching it to a group of millions of users, which ultimately drives the cost up as well because you'll need to make sure that you have a testing team in place and the right tools and technology to actually test those scenarios. 

In the end, the cost really just depends on the features and functionality. It's difficult even to drive deeper from there by saying, "Well, a camera function might cost more than a video function." The reality is a lot of those features, especially with how mobile has matured through the last few years, are very similar to integrate with because there are software development kits, or SDKs, out there that will allow you to integrate all kinds of different things easily. But, really limiting the features, functionality, the scope, and the purpose of the application initially to create that minimum viable product is a really key objective to making sure you've got not only the cost in an area that can be absorbed initially, but also to ensure that you actually have a plan moving forward for success in maturing the application based on user feedback.

About what percentage of the project cost can be added for testing?

It really depends. At DBG, we have three different levels of testing that we go through that are built into every application. We have an initial user interface acceptance testing that's where we make sure that the visual design is 100 percent pixel perfect and consistent to the application and how it actually looks, visually, in the interface. A second component of testing is the functional testing, which is directed by a test plan created by our quality assurance managers who, at the very beginning of the project, identify all the features and functionality of the application in conjunction with the performance requirements to determine all the different test case scenarios that will need to be tested by our manual team of QA and testing experts. Then, we have a third, which is the performance test, and that's where we use our own internal tools and technology to actually test and benchmark the load and performance of the application and how it works in different scenarios.

In general, fixed cost projects at DBG include those three different areas and, on an average project, it might take anywhere from 20 percent to 30 percent of the budget to do all those tests adequately. But, for a MVP, it could be anywhere from 10 percent to 15 percent of an application that will be tested. 

We also have a fourth area of testing that we can add on to a project if a customer requires it, which is a security level of testing. DBG specializes in application security, both on Web and on mobile. We have a team of both penetration testers and also static type analysis testers that will go through the application and try to basically break the functionality, break the algorithms, and test the business logic. We'll report our findings back to the customer and make recommendations on how to improve the application from that standpoint. So, testing can really take anywhere from 10 percent to 30 percent of a budget.

What would you say are the benefits to your business model from a cost and value perspective? 

We are based in Los Angeles, but have an office in India. In fact, most of our engineers are working out of our India office. There are actually many providers that have an outsourced model. Most mature companies will ultimately end up having a delivery center where it's a little bit offshored. Ultimately, based on resourcing needs and the need to drive cost down, most mature companies will actually start looking into developing offshore divisions of the business. The key to success there is in the people, in making sure that you are attracting the right talent and the right people, and creating an environment and a culture within your organization that is more entrepreneurial and startup minded. The reality is there's a huge entrepreneurial mindset right now in the service world as it pertains to people trying to develop mobile applications. So, it's important for a service-based organization to adopt a similar mindset.

What you get from a lot of development companies is that they treat their customers from a kind of manufacturing standpoint, where they're getting in a contract, they're looking at a scope, and they're just delivering on the scope. They're not going any further beyond that. They're not really thinking with the customer or with that entrepreneurial mindset about all the issues that they might foresee. At DBG, it's important for us at the very beginning of a project to not only listen to a customer and see what they want and what idea they have that they want built but, actually, lend them our own expertise. This just happened a month ago, when a customer came in with full funding, like $600,000, to develop an application. They wanted an Android app, an iOS app, and a Web-based interface. They needed an admin portal. They had this big idea and with a little bit of research, we found that there were several competitors already in the field. Based on our independent research and bringing it to the customer's attention, they ultimately decided that it wasn't the right direction. They would have been a great projectfor us and would have kept us busy but, ultimately, it wouldn't have been a success for the customer. It wouldn't have been a long-term engagement for them. 

At DBG, most of our engagements are very interactive, where we're driving a lot of the technology implementation details behind project features and functionality, primarily because it's kind of a mutual understanding that our customer is paying us because we're supposed to know how to build technology, and advise accordingly. On the other side, we're very cognizant of the fact that a lot of our customers will come to us with a lot of domain expertise in their area of business and that's really what they're bringing to the table, so with the fusing of their domain expertise and our expertise in technology, we're able to make a great partnership and build products that actually have a worthwhile chance in the market. 

As a global company, DBG faces many challenges associated with having teams spread across different offices and countries. Our United States office is on Pacific Time and our office in Trivandrum, India, is 12 1/2 hours ahead. But, going back to what I originally said about having the right talent and people in the mix, I can call our India office right now and it's midnight over there, and I guarantee that we're going to get somebody who's actually in our office working. We just have a dedicated and amazing group of engineers at DBG, working all over the globe, and they are really who make us who we are. At the end of the day, the people at a service-based company really are the most important thing. Without the right people, you really aren't going to get anything done.

About the Author

Natalie Craigmile Marketing Manager

See full profile