January 27, 2020

Six Things Enterprise Apps Should Do Like Consumer Apps

Hearing the words "enterprise app" usually strikes fear in the heart of any adept app user. Will the navigation structure feel like something from 2010? Will it look like a website from 1995? How hard will it be to use? You know you'll have to use it regardless, but you know you won't want to use it more than is absolutely required.

Don't let these fears come true with your enterprise app. Here are a few of the best ways to ensure your enterprise app is up to par.


Enterprise apps are usually required for employees to use, and the visual aspects can often be deprioritized since users will have to use the app regardless of its general appeal. It may be unnecessary, but putting extra attention into how the app looks can do a lot for your brand internally. This could be through following the latest design language from Apple or Google, which are fairly extensive and can help your app feel more intuitive.

Also, whether users see it as battery-saving or just the cool, new visual style, the demand for dark mode is growing. As more and more apps adopt these crepuscular themes, apps that only offer a bright white theme will look out of date.


Gamification has become a buzzword that many don't fully understand. When properly gamified, an app deepens engagement by offering implicit and explicit benefits from more frequent interactions. If you show the user how often they are doing a desired task and how this compares to the average, you imply that others can see their behavior and give them a baseline to compare themselves to.

his can be a way to motivate users to take action more often and use their competitive nature to help motivate them in ways that are useful to the business. Providing milestones or checkpoints to reach also helps users understand which areas they still need to complete to finish a task or workflow.


Another form of direct engagement is to allow users to interact with each other through your app. There's a joke in app development circles that every app becomes a chat app eventually, but there can be some truth to it.

Allowing users a way to connect with others at the exact time they need to without needing to switch to another app can be extremely useful. It probably doesn't need to be as full-featured as Slack, but having a way to send quick feedback on something in the moment can help keep users engaged.


With so many forms of communication, at some point, users will need to be able to reference the data in your app. Whether this is for sending an email, comparing it to a presentation or entering information back into your app, users will want to use more than one app at a time, so support for multitasking should be added as early in the development cycle as possible.

In addition, Apple will require all public iPad apps published after April 2020 to support multitasking, so adapting your interfaces to support this extra method will soon be necessary for some apps anyway.


From my years of experience building apps, one truth I've learned is that apps are never done. The mistake some companies make is to "let off the gas" once they complete a release and put off their planning for six months or longer. This can be a detrimental mistake, as new capabilities and standards are constantly evolving.

Tracking and prioritizing these ideas can take a fair amount of time, so you end up going a year without any updates, which often is too long. This can lead to rushing features out, which usually means they aren't well polished, and it becomes a downward spiral of quality that is hard to recover from.


In the end, it's about exceeding expectations. Historically, any app used for "doing work" has pretty low expectations from users, so it shouldn't be too hard to do better. This may be by adding some subtle animations or transitions in the standard workflow, integrating with other apps on the phone or allowing exports that can be quickly emailed for review.

Taking location into account might help you suggest different tasks based on where they're at or the time of day or month. Little things like this may seem inconsequential compared to building an augmented reality experience, but dozens of small positive interactions can add up to a much bigger benefit than you might think.

Enterprise applications are likely to become as critical as B2C apps in the next few years, and businesses that take into account the consumer mindset will be more successful and will drive more engagement with employees, which could lead to a more productive and successful business. The return on investment on both the bottom line and employee satisfaction would be well worth any additional investment and can help set up an industry leader for success in the hyperconnected digital age.

This piece was originally published at forbes.com

January 13, 2020

7 Signs Your Organization Has Outgrown React Native

In building some of the world’s leading mobile development products, Bottle Rocket is embracing the reality that development tooling can evolve at the same rate as the consumer solutions themselves. As users demand more personalized experiences, product development teams demand new technology to drive competitiveness.

Recently, the linchpin that allowed mobile device providers control of the hardware and software to create connected experiences for users has been removed. The development landscape has now shifted to encourage open source communities to contribute mobile advancements like pattern libraries, development frameworks & backend SDKs. This has resulted in delivery teams now targeting both iOS & Android devices with a single codebase.

To that end, in 2018, we saw several cross-platform mobile development approaches emerge as clear market leaders in the enterprise delivery conversation. React Native, being atop this list, is seen as the arbiter of the latest cross-platform movement. React Native is based on the powerful React JS web library supplemented with APIs that ultimately connect to mobile device operating systems. This paper will focus on the React Native library framework.

As we accept business’ natural desire to expand mobility offerings we’ll explore React Native as a catalyst for enablement. And as with many tools used by growing businesses we’ll pinpoint opportunities to begin to transition to a more platform-specific approach.

React Native, as with most cross-platform tools, has a resounding focus on the developer. While the end-user is certainly a consideration, it’s the developer that benefits the most from the arsenal of hooks and bridges into a core layer that sits on top of native software APIs. Those native software APIs then communicate with the device to deliver memorable experiences for end-users. It’s no secret that even the best React Native performance can only hope to mimic native architecture. That said, if done well, the benefits to your organization could come in the following forms:

  • MVP scope delivery: Assuming your MVP goal is to test a focused business hypothesis, you’ll quickly realize the value of being able to release to the full dual-platform market using a single delivery team skill set.
  • Aggressive time-to-market capabilities: Considering JavaScript and React JS development resources remain plentiful, you can pair these core web competencies with solid mobile guidance.
  • Visual quality comparable to native: Performance notwithstanding, the user interface APIs available in React Native deliver satisfactory navigation & views. For the majority of standard views most users will experience acceptable scrolling and swiping.


Indicated above, React Native is an invaluable tool to kickstart your development effort on a new app or validate a React JS web product in a mobile environment — a catalyst for rapid prototyping is a great lens to view React Native through. Building quickly, validating your enterprise hypothesis and iterating aggressively can make the difference between you having a stronger quarter than your competitors.

But as, most of the software your company uses, you will outgrow React Native. In fact, you plan to outgrow most of the technology you use in order to make way for more suitable tools for the future. Plan for where your business is going as opposed to where it is currently. On any company’s product continuum you’ll begin with modest yet differentiating features so you can begin gathering usage data. React Native is going to open so many doors for your company to build quickly and maybe at a lower cost to deliver business value rather than rigid ROI.

Figure 1 — Product Growth Continuum by Al Nolan Solution Architecture @ Bottle Rocket

As your behavior and usage data begin to identify patterns, your feature goals will harden and organizational processes will begin to form around your digital offering to protect its future. We’ve identified key triggers to look for in your organization and analytics to make measurable decisions about your transition into core enterprise architecture, dev/ops & native development. The alternative is to be blind-sided by overwhelming consumer demand which could absorb any market gains achieved by your aggressive time-to-market schedule or cost savings.


1. A Mobility Practice is Born

The mobile channel rightfully holds a significant place in most organizations’ hearts & minds. Many enterprise revenue targets are directly affected by the success or failure of any group’s ability to navigate the mobility space. The response: a mobile center of excellence whose focus will be about the form factor and user and almost never the software itself.

The experience required in these conversations — if technical — will be platform focused. A seat at this table will require intimate mobile experience — leaning more towards iOS/Android knowledge rather than web technology. In the event no formal center of excellence is formed, mobility practice standards are formed. How users interact with a brand through its mobile touchpoints usually garners executive-level attention and requires a material amount of research. These findings are focused on device adoption, device engagement, device capabilities, device roadmaps, etc. The endgame being how do users interact with their “devices” and where can our brand’s message exist in their worlds?

None of this is to say that React Native contributors can’t be valuable in mobile road-mapping but it would be their device/platform knowledge rather than their ReactJS knowledge that rule the day. Organizational maturity around the future of mobile demands a mobility practice with individuals steeped in form-factor knowledge.

2. A Bridge to Somewhere

What makes React Native so practical and ultimately the most popular cross-platform tool is its ability to translate JavaScript threads to Native threads through bridge. Developers with a competency in JavaScript, being the most wide-spread non-compiled language available, can now make the leap to React and then React Native to begin writing JSX within hours.

However, what’s natively available in React Native (polyfills like fetch, geolocation, localized state management, console logging, etc.) may not always accommodate your desired features at scale. You would then need to pay keen attention to writing your own native modules so understanding the bridge and how it communicates with JavaScriptCore (for iOS) and JNI (for Android) is critical.

Custom features like video manipulation, voice integrations with Siri, global state management, etc. are examples of areas where organizations have recognized the need for enhanced capabilities, built their own native modules and contributed them to the open-source communities. It’s easy to say that these are limits in React Native but another way to look at it is that the core framework handles a vast amount of use cases and enables — custom API creation through native through modules for the rest. The limitation, though, is because of React Native architecture custom code may need to be developed natively and bridged because it can not simply run as-is at run-time.

3. Single-threaded architecture limits concurrent features

Both the JavaScript realm and Native realms are lightning-fast on their own. We all have experienced countless apps (web & mobile) where either JavaScript or Native performance has delivered surprise and delight. Although it’s only React Native applications that rely on a pairing between both native and JavaScript performance through the bridge mentioned before.

Behind the scenes, your completed app can only ask the operating system to open a single thread for reading and responding to all the JavaScript written. With React Native and its single-threaded nature, communication between both realms has 1 communication stream at a time.

Messages between touch events, API calls and route to a subsequent view can get entangled and even dropped altogether if not architected carefully. All things held equal, even an inexperienced native developer can run into performance slowdowns per feature but without the single-thread limitation, the user may never be affected. This architecture requires special attention to be paid to what features and functions are most important at any given moment because the pipeline processing these requests is extremely narrow.

Presenting a full-screen camera view may not seem like an insurmountable task for React Native and by itself, it’s pretty manageable. But what if we want to add the ability to swipe a screen view on top as well as adjust the opacity based on how much far the swipe has progressed. Now we’re immediately challenging the bridge to manage the camera view, x-coordinates of a modal as well calculation of a variable to pass to a styling object. Keep in mind this will not break React Native but it certainly doesn’t keep bridge communication over your single thread to a minimum.

For an app with minimal features whose goal is to prove out a very specific use case, this will not be a concern. But as an enterprise grows and internal groups begin to rightfully ask for features this pattern may become an expensive performance hurdle to handle with React Native.

4. Product market fit demands platform-based experience

Product Market Fit (PMF) is the holy grail of product development. Eventually, your users will demand a solid experience paired with a feature set that delivers on your value proposition. This doesn’t necessarily equate to PMF. In fact, it’s only the beginning. You want to address more than the product itself. The market (defined by a feedback loop, revenues, competition, choice, etc.) will begin to reveal underserved needs that will require quick competitive responses. Your responses to these market gaps while still maintaining your market share start to form your PMF.

As this organic business pattern unfolds, the final key is uncovered: a targeted customer experience. At the moment in which you can deliver on your brand promise, create a healthy feedback loop and acquire new customers at will you’ve reached the pinnacle of PMF fit.

So where does React Native fit in? In software development, product solution fit is the pattern of validating an MVP. An MVP is meant to gather data and prove a specific business hypothesis by delivering the least amount of features. As you begin to gather data you’ll want to make small measurable tweaks to your releases. This is an enterprise’s optimal case for React Native considering the resource investment around building a native practice may outweigh the value of the information gained.

Once you begin to gain traction, you must extend your delivery practice beyond software into the relationship with your current & potential customers. Today, the analytics & reporting tools required to measure & maintain these relationships require complex library integrations that are better suited for native experiences.

The quest for PMF doesn’t end at development’s door. Product groups have to be able to think primarily about the customer’s experience and not be hindered by the risk of a library or plugin being unavailable for upgrade along the journey. React Native relies on a significant number of libraries to access native APIs in order to maintain its competitive edge. If any of these libraries are out of compliance or not maintained it could risk the entire project roadmap.

Eventually, Android users will demand an Android-specific experience along with complementary features. IOS users will demand an iOS-specific experience along with complementary features. Biometric integrations, payment, navigation & routing, media access, etc. are all critical for immersive mobile experiences yet have all had their share of implementation issues when it comes to React Native.

5. Platforms eventually demand different release cycles

As you iterate and explore your product’s traction in the marketplace you will notice bugs, fixes & feature opportunities on each individual platform. An iOS improvement that is already an inherent feature in Android can trigger a targeted release. An iOS-specific bug, unrelated to Android, should trigger a targeted iOS release. Why is this important? Your single React Native codebase -which had been an advantage up to that point — now requires a fork.

There are certainly methods to target platform-specific upgrades but your development organization now has to maintain a React Native codebase with custom iOS & Android scripts or native modules.

Your goal of carrying a small single-celled team of JS engineers now must evolve. You now must consider an issue-specific Android knowledge base and track this issue against industry best-practices. Will the issue be addressed in the latest version of React Native? Will the issue persist as long as its native code integrated with React Native? These are questions you’ll need Android knowledge readily available to answer. And you must also do the same for iOS.

6. Intellectual property concerns warrant core technology to be proprietary rather than open-source

React Native is open-source code. The libraries you inevitably integrate will be open source. Your deployment tooling will be open source. Open source technology has made huge contributions to software development at large and this is not a claim that it is a pattern that is bad for business.

However, even with the recent adoption of more open source tooling at the enterprise level, your organization now has to manage the licensing, crediting & contributions of these tools — publicly. If your enterprise, like an increasing amount of enterprises, has the appetite to employ this practice knowledgeably and responsibly then the open source concern is minimal at best. Just know that each license of each library should now be reviewed with the same scrutiny as a non-disclosure agreement or any other commercial licensing agreement.

7. Performance efficiencies/advantages required at scale

React Native, which is still considered beta, is a framework created by Facebook but is now community managed. As the major contributors advance the APIs and tackle reported issues they will release new versions on an unpredictable cadence. This means that critical changes your organization may need may be reported by you and others but fixed on an undetermined schedule.

And when one set of issues is fixed, that new version may introduce breaking changes to existing code previously addressed by in-house workarounds.

In fact, it has been widely noted that libraries are regularly abandoned and run the risk of no longer being maintained. A mature development organization can address this phenomenon with forks of their own but it’s good practice for enterprises to work with libraries that offer accurate, secure & predictable results as often as possible.


Whether its financial management software or customer relationship management tools, your organization will have a tendency to outgrow its original intent. In managing 100 receivables per month, certain software may be the perfect fit whereas managing 1000+ may require an upgrade or a pivot altogether. Your revenue will grow. Your teams will grow. And at the root of that growth are customers demanding more and more custom experiences.

You don’t want any software or its limitations to hinder you from thinking more about your customer than the method you use to reach them.

This piece was originally published at Medium.com/rocket-fuel.

December 30, 2019

Hack Week Recap: “Teemwork” Makes The Dream Work

At Bottle Rocket, we occasionally take time out of our week to focus on exploring new technologies. We call these “Hack Weeks” and they generally consist of small teams forming and meeting for an hour or two each day to try out some new ideas.

In early December, we had a hack week around office apps that we called “Teemwork Makes The Dream Work,” a play on words that uses the Teem moniker for an extra level of puns. We had several teams explore integrating with Teem, and several that worked on other ideas. With Hack Week, anything is on the table! So let’s dig in to a few of the ideas we saw:


Tyler Milner, one of our iOS Jedi, decided to dig up an old Rocket Science project of his called BR Ice Box. The project observes the temperature readings from the Bluetooth beacons around the office and stores that information in a Firebase Realtime Database, displaying a list of all of the beacons and their corresponding temperatures in a list. The main idea of the original app was to make it easy for people to figure out the warmest/coldest areas of the office.

For hack week, he decided to build upon this project, extending the functionality to also send the temperature readings to the Teem API. In the Bottle Rocket kitchen, we have a large television that shows a list of meeting rooms and their current availability. His goal was to also display the temperature information that the app picks up on that screen as well, so people could get a sense for office temperatures without needing to download or use an app.

Overall, I didn't get very far in my implementation of the Teem API since it took some time to write the code that executes the Teem API's OAuth flow. I did get the OAuth flow working, and was able to successfully get an access token and verify I could hit Teems API to get a list of room information, but I didn't have time to take my temperature readings and execute the necessary PATCH calls to attach my temperature readings to each meeting room.

Tyler Milner

Hack Week doesn’t require successful completion of the projects that are started, the learnings from the experimentation lead to more ideas. Next up was an experiment with using a keyboard within iPad apps.


John Davis explored using a third-party framework to expand an application’s support for keyboard-based navigation.

I believe great keyboard support sets apart iPad and Mac applications that feel well considered and accessible from those that feel preliminary. The need to discover efficient solutions and patterns to implement this results from two fronts: Apple’s allowance of iPad applications to run on Mac, and a drive to better support accessibility standards that require keyboard controllability.

John Davis

The framework John explored is named KeyboardKit and is developed by Douglas Hill.  The demo app highlighted components, like tab bars and navigation bars, provided by the framework that come with easy to use support for invoking buttons and navigation actions via the keyboard.

As with most hackweek projects he was short on time and not able to explore much more, but he found the framework falls short in the same ways that Apple’s provided tools fall short. That said, it helped him learn how simple it can be to add these interactions to an application and provide a more complete experience to users.


Several weeks ago, a few Rocketeers discussed the idea of using a Slackbot as an internal test bed for analytics and user engagement tools. For Hack Week, Jason Brewer was interested in the effort it took to develop a Slackbot and how feasible or successful this idea might be.

I found that developing an intelligent Slackbot was as easy as getting an API key and standing up a Node JS server. Then I needed something for it to do so I grabbed several easy public APIs that returned nice JSON and connected them to key words the Slackbot watched for.

Jason Brewer

To bring in the analytics and engagement element, he had the idea to just let users engage the Slackbot with no context or information about its features and collect analytics on the discovery of its ‘random’ features. Using the workspace we have as a result of our partnership with Amplitude, he integrated an Amplitude package into the bot and defined events to track:

  • User joined the channel
  • User asked for help
  • User asked for a clue
  • User ‘discovered’ a feature (by typing one of the key words that triggered the feature response

By gamifying the interaction, he was able to collect data from other Rocketeers who played with the slackbot. Few people found all the features, but quite a few people participated and enjoyed interacting with a rudimentary AI. He was able to collect data around which features were the easiest to discover, and how the clues given by the slackbot impacted the successful discovery of more features. This kind of analysis is similar to what we see in our clients’ analysis, so it was nice to experiment with a version of this ourselves.

Hack Week is a great time to explore new ideas, and experiment with technology we have been following. We never know where these ideas could lead, and if you any questions, or would like us to explore ideas with you, feel free to reach out. [Link to contact us page].

December 11, 2019

Five Mistakes of Mobile Design

When it comes to designing a mobile experience, it’s easy to think users will be satisfied with something that mirrors your website. That may be true, but it’s important to consider the unique benefits of the mobile platform. Here are a few common mistakes we see all the time in the mobile industry.


The most important mobile feature for any given app isn't usually surprising. Just ask a few users “What do you wish we could let you do from anywhere?” The challenge is that this “one thing” can require changes throughout the whole organization -- new APIs, new interface designs and maybe even operational changes. Having a restaurant mobile app without mobile ordering would mean that very few people would use it, and it could never have much impact on your business. It may be the hardest feature to build, but if it’s the right one, the return on investment will be more than worthwhile.


Humans are fickle. We get bored easily, and we want newer and better, faster and more features. If your app still looks the same two years after it launches, users could be enticed to try a new app. The design guidelines from Apple and Google are constantly being tweaked and updated, and it’s smart to keep comparing your app to them. Be sure to look for areas that could be improved. As new features come online, you may want to rework your experience to highlight them -- or guide users to the most popular areas. And with dark mode being supported by both platforms, users will expect this battery-saving change from all apps soon, and blindingly white apps will start being left behind.


Everyone has an opinion, and sometimes the only thing worse than users sharing them is users not sharing them. If the perception is that you don’t care about your users, they will leave and never come back. Responding to reviews is possible on both the App Store and Google Play, and this can be a great way to engage with your users. It not only shows the individual that you care, but it signals your empathy to other users as well. Sometimes users are just confused, or they can’t find something in an app, but a negative review can make it look like it’s not possible. A response from your team can help users find what they’re looking for. You’ll never please everyone, but if you’re not receiving any negative feedback, you probably don’t have any passionate users.


Mobile experiences are often the most-used experiences, and some new services may be only available through mobile. This can lead to frustrated customers who want to do the same activity through a web browser on a computer when they have access to one. Instagram famously launched as only an iPhone app and did not have a web experience for almost three years. Even today, you can’t visit the website and upload a photo to your Instagram feed. Instead, you have to use another service that accesses the API. Few brands can afford to be this cumbersome for users, so think about what other ways users will want to interact with your service -- and make sure your app runs on those devices.


Beyond just the mobile app, you must think about how users can interact with your brand. Going back to my first recommendation of building the right "thing" for mobile, you also need to think about the right thing for other devices. What do your users want to do from their watch? What about their voice assistant? If they have an iPhone and an Echo, how do Siri and Alexa help build out their experience? With Car Play and Android Auto, users can even interact with your brand from their car, but their expectations will probably be different. Brands need to meet users where they are going to spend the most time since users often already think of them as always available anywhere, not just always available from their mobile device.


Mobile experiences are here to stay, and they will be a baseline expectation for most businesses. Unfortunately, companies can’t always pivot their business to be mobile-first overnight, so transformation takes time. Hopefully you can avoid these pitfalls in the long term -- and keep them in mind as you continue to center your experience around your users.

This piece was originally published at Forbes.com.

November 10, 2019

Amy Czuchlewski Honored at this year’s Technology Ball gala with Luminary Award

Digital transformation has become a hot topic as of late. Once you decide that your business needs one, how do you go about actually implementing the technology to bring your business forward? Here are three key ways that most businesses need to adapt for the digital age, and some technology that can help get you there:

Bottle Rocket’s own SVP, Technology was honored last night at the annual Technology Ball gala with the organizations first ever Women in Technology Luminary Award. Amy was recognized as an exceptional woman in the field of technology who has made a positive impact within her organization and/or the technology community in Dallas.

A “luminary” is defined as “a leading light who has achieved success in their chosen field and who serves as a positive inspiration or influence to others. “Congratulations to all the other amazing finalists for their accomplishments - you're all luminaries to me,” said Amy in her acceptance speech. “Thank you to Bottle Rocket for supporting my passion and vision, and for creating an inclusive environment with many other female leaders by my side. And a huge thank you to Technology Ball and SEI for shining a light on female technology leaders and helping to inspire a new generation.” 

More info on Technology Ball can be found here: http://technologyball.com/.

Congratulations Amy!

Bottle Rocket Logo
digital transformation redefined.

Bottle Rocket is a digital transformation company that leverages a unique Connected Customer mindset to build technology-enabled solutions that propel businesses and delight customers.

© 2019 Bottle Rocket. All Rights Reserved.