How big is the smart device market? (units)

Definitive answers are elusive. A variety of sources project the number of active smart devices in 2021 at somewhere between about 2 Billion units to more than there are people on Earth. In 2016, Apple formally laid claim to 1 Billion active (Apple) smart device users. In early 2020, they claimed 1.5 Billion active devices. Android smart devices sell in higher volume than Apple devices.

So presuming such growth claims are true... and thinking about concepts like:

• Total unit sales volume vs. replacements: a person who owns 5 generations of a device has almost no potential of buying 5 copies of one app as if they are 5 individuals. It's likely they buy & install an app on the latest generation they use now, or perhaps on a phone & a tablet if both are in use now,
• Multi-generation replacements: units sold but now mostly "retired," perhaps relegated to a singular duty such as using an old phone only as a music storage box in a car and thus probably no potential for that phone to add any new apps. It may still connect to a network from time to time and that will make it count in a "total actives" census, but that doesn't mean its owner is actively buying new apps,
• Hand-me-downs with near nill potential to buy anything in an app store, though technically still "active." Families pass their former devices down. Recipients- particularly children- are not automatically granted rights to buy apps.
• What is actually "smart" enough to be able to run (and thus buy) third-party apps? Android and similar run on many devices that have no app store revenue potential at all. They are basically semi-smart devices in they use some of mobile OS code but only for a partial experience, which does not include access to app stores,
• Plus some corporate puffery (for exciting PR sizzle)...

...we're comfortable assuming...

at least 2 Billion units in active use AND third-party app monetizable.

2 Billion or so IS likely a valid number (and possibly-to-probably leaning to the conservative). As time passes, the actual number seems destined to rise higher than fall... there are still plenty of first-time smart-device prospects in the wild.

Consider some "what if" math on 2 Billion prospective buyers in the following table. Left column lets you assume your own number for total number of active users. All other columns show revenue potential based on what you think you could get out of them.

AVG APP REVENUE SCENARIOS
MARKET SIZE	PENNY	NICKEL	DIME	25¢	50¢	99¢	$5
1.50B	$15M	$75M	$150M	$375M	$750M	$1.5B	$7.5B
1.75B	$17M	$87M	$175M	$437M	$875M	$1.7B	$8.7B
2.00B	$20M	$100M	$200M	$500M	$1.0B	$1.9B	$10.0B
2.25B	$22M	$112M	$225M	$562M	$1.1B	$2.2B	$11.2B
2.50B	$25M	$125M	$250M	$625M	$1.2B	$2.4B	$12.5B
2.75B	$27M	$137M	$275M	$687M	$1.3B	$2.7B	$13.7B
3.00B	$30M	$150M	$300M	$750M	$1.5B	$2.9B	$15.0B

Do apps sell for more than five dollars? of course they do, but this is averages on the entire universe: you won't sell ANY app to everyone.

Assuming the green-highlighted 2-Billion market size, here's a few scenarios to help illustrate potential...

• Sell each of them something for 1 penny and that yields TWENTY MILLION dollars.
• Sell each of them something for 1 nickel to realize ONE HUNDRED MILLION dollars.
• Sell each of them a 50-cent app to harvest a BILLION dollars!

Could you or your business use a spare $20M to $1B?

Of course, no entity ever sells an entire market of size, but the point is to recognize the potentials in even fractional slices of that enormous pie. Sell only a tiny segment of 2+ billion and the results are still quite lucrative. For example, sell only 1% of 2 Billion- that's 20M customers- on an app subscription model, giving you only:

• $5 each month and it yields $1.2 BILLION each year!
• $2/month for $480M/yr.
• $1/month for $240M/yr.
• One measly CENT each month yields $2.4M per year.

Marketers and entrepreneurs very rarely get to realistically think in billion-size scale... especially cost-efficiently ACCESSIBLE lead pools that size. A number like 2 billion is OVER 5 TIMES the ENTIRE population of the United States! If you sell to America now, how well are you doing in THAT much smaller pool? Consider casting at least one line in this much BIGGER one.

The incredible scale may be why the so-called "app gold rush" rolls on: even a micro-success in a recurring revenue, subscription model can seem almost magical.

ADD SOME REVENUE MAGIC

Stake Your App Gold Rush Claim: 772-546-7002

How big is the mobile app market? (revenue)

Like the answer to question #1, definitive answers are elusive. The most respected research sources for this kind of information- including Statista, IHS, IDC, Gartner and others- offer a diverse mix of revenue tallies and projections... but all tend to be fairly optimistic about rapid growth over the next few years. Columns 1 & 2 in the below table blend collective, expert projections along with our own best estimates of growth to project total mobile app revenue between 2024 and 2026.

That's interesting information but what you really want to know is how much YOUR own app(s) can make in the next few years. Columns 3-6 illustrate various revenue an app entrepreneur could realize from those estimates if he or she could carve out relatively small shares of that revenue for themselves...

AVG APP REVENUE SCENARIOS
YEAR	APP REVENUE	YOUR CUT AT .5%	YOUR CUT AT .01%	YOUR CUT AT .005%	YOUR CUT AT .001%
2017	$100B	$503M	$10.1M	$5.0M	$1.0M
2018	$112B	$563M	$11.3M	$5.6M	$1.1M
2019	$122B	$614M	$12.2M	$6.1M	$1.2M
2020	$130B	$651M	$13.0M	$6.5M	$1.3M
2021	$136B	$683M	$13.6M	$6.8M	$1.4M
2022	$142B	$711M	$14.2M	$7.1M	$1.4M
2023	$147B	$739M	$14.7M	$7.3M	$1.4M
2024	$151B	$755M	$15.0M	$7.5M	$1.5M
2025	$155B	$777M	$15.5M	$7.8M	$1.5M
2026	$160B	$800M	$16.0M	$8.0M	$1.6M

If the annual app revenue projections (column 2) pan out as shown, total app revenue should surpass approx. $160 BILLION in 2026. Who wouldn’t want a small slice of all that money? For example (as illustrated in column 4 above) If you could create an app(s) that wins 1/100th of 1% of that 2024 projected revenue, you make about $15 million in that year alone! If you build that app(s) to launch in 2024 and make 1/100th of 1% of the above projected revenue through 2026, your tally for 2024-2026 revenue could add up to about $46 million.

Not sure you can develop one or more apps to capture 1/100th share of total app revenue? How about cutting the goal in half by aiming for a smaller 0.005% share as illustrated in column 5? Using the revenue projections for 2024, a 0.005% share of the projected total would yield about $7.5 million or an accumulated $23 million between 2024 and 2026.

Even more pessimistic about your apps potential? Column 6 illustrates aiming for a TINIER, tiny (did we say tiny?) slice at ONLY 0.001% share (that's 1/1000th of 1%) of estimated revenue. Even with such a low target, 2024 could be a $1.5M year for your business and 2024 to 2026 could deliver accumulated sales of more than $4.6 million.

That would be like making better than a $1.5M-per-year salary while capturing only 0.001% of the total app revenue projected through 2026. Only 1/1000th of 1%!

And don't take the "your cut" columns to mean you can't go for BETTER than the share estimates shown in the table. While column 3 at 1/2 of 1% (or 0.5%) share illustrates how to become an app entrepreneur billionaire (yes, that's billionaire with a "B"), some app development companies are aiming even higher with share targets of 1%-5% or more. We don't even show those much bigger numbers in the table, but larger shares would yield much greater revenue than what we do show. For example, a 1% share would simply double the numbers illustrated in column 3... and 2% would quadruple them.

Given the amount of money involved, you should aim as high as possible too... even monetize your app idea(s) within your own business. We can help you build a great company from scratch or evolve an existing business toward (also) capitalizing on the app market gold rush. If you strive for 2% but end up with only 1% you'll just have to try to get by best you can on those billions. As a frame of reference, multiple sources project the net worth of one of the Shark Tank sharks- Mark Cuban- owner of the Dallas Mavericks and 2929 Entertainment, at $4.4 billion. He seems to be surviving😉.

Want to buy your own national sports team, television network and/or join him on THAT side of the table on Shark Tank?

LETS DEVELOP YOUR APP!

There's Gold in Them There...ummm... Lines of Code

I've Got a Great Idea for an App(s). Now What?

If you are an innovator with a good app idea(s), you’ve already accomplished what many consider the most important part of the process. To monetize your app concept, you will need to take it further than only an idea. There is not much of a market for app ideas on their own. You need to work on turning the idea into a finished product and taking it to market most effectively. The very best way to proceed beyond your innovation brainstorm can be summarized in 3 key needs:

1. flesh out the details of your idea as thoroughly as possible in a written app specification document. Fully imagine it in good detail, including the nitty-gritty, and write it all down. Think of this like wanting to build a dream home. What do you start with? Architecture plans. This is the "architecture" plans for your dream app.
2. engage a quality programming team to turn that detailed app architecture description into impressive software ready to be sold in the app store(s). In the same analogy, the programmers are the actual builders- the bricklayers, plumbers and electricians. They will work from the finalized written specs to build it as you/we describe it in those plans.
3. get an app marketing model in motion, starting well before you go to market and continuing beyond your launch. The better analogy here is thinking about how you start seeing the trailers for movies long before you can actually see the movie itself. Do a Paul Revere with your app: "My amazing app is coming... My amazing app is coming!" well before you launch the app. Stimulate the market's appetite. Excite them. Build anticipation!

BI can help you do all 3 of these best-in-class. We leverage deep, award-winning resources to help you flow from your good concept to profitable launch & ongoing growth.

When you are ready to get after those millions-to-billions in software-driven revenue, there are THREE distinct steps in a quality App Development and Launch Cycle. The balance of this article explores 2 of the 3: crucial architecture and coding pre-launch steps... and closes with a link to a separate article that covers step 3: driving a remarkable launch.

STEP 1. ARCHITECTING A MOBILE APP: CAST A COMPLETE APP VISION BEFORE CODING BEGINS

One of the first things to fully appreciate is that you don’t have to become a programmer to create an app. Not believing this fact derails countless innovators from taking even one next step beyond hatching a new app idea. Think about it. When:

• you build a home, do you personally have to become a carpenter, plumber, electrician, etc?
• your car needs repairs, do you have to become an auto mechanic?
• you have some health need, do you have to become a doctor?

Of course not! Those are all experts at their crafts... professionals you temporarily hire to lend their talents to your wants or needs.

Exceptional app programming talent can be contracted just like an electrician, mechanic or doctor. In most cases, it is your shrewdest move to tap into specialists already skilled at a task as opposed trying to do it all yourself... even if you have some relevant ability. Focused talent will likely get it done much quicker and at a much higher level of quality than you’ll be able to achieve on your own.

Besides, while you’re busy trying to figure out how to code your app in Objective C, Java, Swift and/or HTML5 + Javascript, etc, someone else may beat you to market. There are many ROI advantages in agility.

BI has very capable programming teams in our cream-of-the-crop network. We can match your concept to the talent most suitable for turning your idea into a quality, usable app... FAST... and at or under budget!

BEFORE you engage programmers, there’s a very smart thing you should do first... something almost all app innovators fail to do. By far...

The best way to minimize the overall cost of monetizing your app idea is by minimizing the time programmers need to understand exactly what you want the app to do, exactly how you want it to work, exactly how you want it to look, etc.

To revisit our home-building analogy, if you want to build a new home, do you call in the carpenters, plumbers, electricians, etc, and tell them to have at it? NO! That would be chaos. The first step is to develop detailed plans for the home. An architect helps you fully conceptualize your new home in nitty-gritty detail before the first brick is laid... before you have to start paying skilled labor to do the actual building work.

BI software app architects help you completely map out your software app before the first line of code is written. This is a very important, pre-programming step that most people foolishly skip. Don't be one of them.

WHY is this "spec first" approach so important? A thoroughly-planned app can save you lots of money: programming time is very expensive time... especially when programming without a plan requires reviews, changes, more reviews, more changes, etc. You pay for every bit of that coding, including the code you paid to have written, then wanted altered or even thrown out to go some other way. Making it up as you go has sooooooooo much WASTE in it.

If you fly by the seat of your pants in developing your app, you are reviewing progress and then having them delete code to fix things you don't like... over and over again. You wouldn't want to burn all that money on carpenters, bricklayers, plumbers doing and undoing their work as you review and then recognize that you want that house to be different than how they best-guessed it FOR you. It would be very expensive to have them putting up walls, taking down walls, moving walls around, rerouting plumbing then rerouting it again, etc.

• Now that I see it, I think I'd rather have the pool over there.
• Now that I see this window layout, I want to completely redo this whole wall.
• Now that I can see that this setup makes no sense, tear those rooms back down and redo them this other way.
• You know, now that you've moved that pool, I think I like it better back in the original spot. Put it back.

Rolling your eyes at the insanity of building a home that way? Why build software like that? Bricklayers & carpenters will generally have lower fees than skilled programmers. Apply a classic, PROVEN strategy to better manage the biggest project costs & time.

Building an app without a plan is generally an exercise in chaos. You have relatively expensive specialists happy to bill you much more money than necessary as you keep reviewing progress and making changes on the fly. This is fundamental to what makes tech projects get way over budget and take much longer than anyone expected. Don't do it that way. Architecting it all out first is like using detailed house plans to get it all exactly as you want it BEFORE the first brick is laid.

The second major reason to "spec first" is that a fully-imagined app plan can incorporate all of the value and revenue-building elements important to maximizing your upside. If you want to make money with your app(s), you want to think through all of the revenue-generation options BEFORE the app is coded too.

If you want millions or tens of millions of people to want to buy your app, buy a service within the app or give you recurring revenue in a subscription model, you should weave all perceived value-building elements right into the software architecture plan... BEFORE coding begins.

This way, when the app is ready to go to market, it will be loaded with attractive benefits and clever monetization hooks to woo prospects in great volume. Trying to glom on the money-making pieces late in the process- or after an app is largely coded- tends to be a far less effective way to go... likely to result in more programming expense to force such new elements into the app. In corporate speak, this would be the "bandaid approach" or sometimes "putting bandaids on bandaids." Using a spec-first approach mitigates all bandaids: you map it all out in advance to get it as right as possible.

Our software app architects can work with you to turn your ideas about the app into very tangible plans, documenting the details so that when the programmers are contracted, they’ll have an exceptionally clear picture of exactly what you want them to code:

• Exactly what does the app do?
• Exactly how do users use the app?
• What are the navigation elements and how do they look?
• What do the various screens look like on phone and tablet-sized devices?
• Exactly what are the various ways the app will make money?
• Exactly what about the app will keep users coming back?
• What will get them to turn their friends onto the app?
• Etc. There are MANY layers to assess, plan and WRITE DOWN in your spec.

We will collaboratively share many options to flesh out your idea and you can pick & choose those you like: options to yield a more appealing app AND options to yield a more profitable revenue stream(s) for your business.

Unfortunately, the alternative approach is the MUCH more common, fly-by-the-seat-of-the-pants app development model. That model skips the architecture step because the person with the app idea calls app programmers to develop it. Again, the perfect analogy is wanting to build a house but skipping the architecture step.

The wrong way involves a ton of expensive question & answer as the programmers try to draw out of you what you want them to do, often followed by them doing some coding on best guesses, then seeking your review and change requests. This will repeat over and over, as they guess differently than you desire it and you have to ask them- and pay them more- to adjust the functionality to what you actually want. You pay for the code you keep and you pay for the code that gets jettisoned. It's a very inefficient approach even if you have lots of money to burn. Whether you use our help or someone else's, don't build your app that way.

Besides saving (relatively expensive) programmer time, a great written specification document also helps you think it all through, fleshing out the loosely-defined app concept in your head into a detailed app description. Most importantly, a complete spec-first process facilitates the opportunity to get...

fixed project bids for the coding work. 🎉

In other words, instead of falling into the almost-always, MUCH-MORE-EXPENSIVE trap of an open-ended hourly project, a fixed bid gets you FLAT FEE bid(s) to develop the app in full.

BEWARE 'DE HOURLIES Engaging programmers on an hourly basis creates a tangible, financial incentive for the project to take as many hours as they think they can bill. It’s not about how quickly they get your development project done... it’s how LONNNNNNNNG they can stretch it out. Each added hour of billings is more "loot" for them.

When shopping around for someone to develop your app, hourly quotes tend to have tremendous appeal vs. fixed bids for entire projects. In the former, you see a relatively low number. What you never know for sure is how many hours will actually be billed to get to the SAME finish line as the fixed bidders. Why do government projects always seem to go way over budget and take way longer than estimated? Often it's because the government accepted an ambiguous, open-ended timeframe project with hourly billings. Since the government will pay, the contractors make more money by simply keeping the project going. If they work as efficiently as possible to finish ASAP, the revenue flow stops.

Nevertheless, many programming contracts are won by decision-makers looking at an hourly rate vs. a total project bid and choosing the much lower number. In doing so, they are basically replicating a government contract project, very likely leading to the SAME outcome: budget overruns and ever-sliding completion times. This choice sets up an incentive that is the opposite of what they want. But they do it anyway, hoping that maybe the total cost of the project will be less than the flat fee amount quoted for the WHOLE job. In practice, this almost never occurs as long as the flat fee bids are competitively sourced.

The biggest lure of programming by the hour conceals ANOTHER hidden hook: once you get into a coding project, you somewhat get married to the developer. If it doesn’t go well and you want to fire them, their replacement often wants to throw out "all that bad code that (former) team created" and start over from scratch.

For BOTH of these reasons, we subscribe to the strategy that gathering competitive, fixed PROJECT bids for programming is the SMARTEST way to go.

On the next page, we dive right into a much better way to develop your app before walking through many good tips for contracting the RIGHT app programmers for your project. Click NEXT below to finish what you started...