Eight Bit Studios

Eight Bit Studios celebrates our sense of wonder for creative technology and passion for teamwork.

We have a track record of investing emotionally with our partners in the apps we make and everyone who uses them. Ambitious organizations wanting custom apps and websites turn to us because we use empathy to find out what people need and craft solutions that make a meaningful impact.

Our best work happens when facing complex problems that require high levels of empathy. We have a knack for breaking challenges down to their fundamental parts, reconfiguring those pieces, and building solutions that didn't exist before. It looks a bit like this:

The world needs more empathy. We want to do our part to help make that happen so we can shape better experiences for everyone. We believe organizations that champion empathy will be future industry leaders because they are better equipped to:
 

Being a Co-Founder, my primary role is to foster a shared purpose and create the best possible environment for achieving our collective goals. As Design Principal, I support our design team and advocate for ethical and robust design practices inside and outside of Eight Bit.

Remember 2008? Banks were getting bailed out, Barack was being sworn in, and the App Store was just taking root.

A group of us were drawn together by our enthusiasm for technology, design, and the idea that eight bits are better than two. We grew up during the 8-bit gaming era, which gave rise to a generation of artists, musicians, and programmers.

Each of us had been coding, creating, or gaming from an early age. We each brought our ideals to the workforce as adults but struggled to find a company that embodied them.

As individuals, we were limited; combining our skills opened up exciting new possibilities. We asked ourselves, "If we were to create an agency, what would we have to do so that we could sleep at night?" and came up with some pretty awesome answers:

We called it Eight Bit Studios as a reminder to stay true to that creative spark that took root in our youth.

Some say a recession is one of the best times to start a business. That seemed to be the case for us. While the country was reeling from the economic turmoil, we were swimming in possibilities and brimming with optimism fueled by the internet, startup culture, and the rise of mobile devices.

The iPhone and mobile apps tapped into our sense of wonder much the same way 8-bit games did. We were obsessed. We dove into making apps and haven't looked back.

Our team works under one roof in Chicago. We want designers, UXers, coders and managers rubbing elbows throughout a project. We like to think of ourselves like a band of musicians jamming live together. It's pretty hard to do that if you're not in the same room and it's way more fun when you are. Telepresence has come a long way, but we believe in-person collaboration is beneficial to the creative process and producing the best work possible.

Our partners have ambitious goals and hire us to produce industry-leading custom applications. The stakes often get high. Having our team all under one roof improves our ability to deliver great work and build a close working relationship. Here are some of the benefits our partners get when working side-by-side with us: 

Eight Bit is industry-agnostic. Our work has touched many verticals: logistics, education, real estate, medical and health, sports, finance, agriculture, public safety, consumer data, arts and entertainment and nonprofit.

We get a lot of repeat work from our partners. We prefer ongoing building relationships. One-off projects happen here and there, but 80% or more of our work is from a consistent client-base.

Many variables factor into how long it will take to develop a mobile app. Here are just a few:

It's darn near impossible to estimate scope and timeline before a thorough discovery phase accurately. Throwing around numbers before discovery often leads to a host of problems and misaligned expectations. You need to get the entire team together — the actual people doing the work — to spend some time digging into the problem before having any shot at accurately scoping the work. 

Even after discovery, organizations should allow room in their budget and timeline for adjustments on-the-fly. Breaking down projects into small phases and deliveries helps keep things on track and manage risk.

If we're using the term front-end to talk about the native platform app for iOS or Android, then the amount of effort does depend on the complexity of the problem.

A Weather app, for instance, may try to differentiate itself by being visually clever and accurate.  Since most weather data comes from the same source, being clever with visuals or user engagement is going to be crucial. Clever can drive complexity, which can move the needle on cost.  The back-end for such an app generally does not concern itself with user log in or parity between devices. If I have the same weather app installed on my iPad and iPhone, the data will likely be managed locally through device-based storage of preferences. In such cases, the back-end is aggregating weather information for the platform, or front-end, to display.

Let's consider a social media app.  The front-end complexity is going to shoot up drastically. Not only are the visual and user experiences usually more robust than those of a standard utility app, but they also need to display much more data in a visually appealing way. Your platforms must also be in parity. If I login to Instagram on my iPad and my iPhone, I expect that liking a post on my iPad will also be reflected on my iPhone. That like will also be visible to everyone else to whom I am connected.

It's a good rule of thumb that native app builds are going to be more complex and take more time to implement than most things implemented on the back-end.

The platform choice can often be boiled down to the audience; who will be using this app? Who will you be targeting? If your users tend to use Android, you should begin with Android. It still holds that the US smartphone market is duopolistically split between iOS and Android. So if your market is US based and your demographic is ambiguous, we recommend picking one platform to start with and execute against. This decision could be based on development costs, availability of engineering talent, devices available to the beta-test audience, and a host of other factors.

If your market is global, Android tends to lead the pack by being available on a wide variety of lower-cost devices. In this case, it might be advisable to develop the Android app first.

We recommend leading with one platform to shake out all of the design and UX flaws, as well as general functionality and data bugs. Once you have a stable product, it's much easier to use that as a development roadmap for the other platform.

If it's unreasonable to finish one product first, we recommend staggering the product timeline so that one product's development is ahead of the others by several weeks or a dev sprint.

Native gives you a few things: stability, fidelity, longevity. When developers are building native apps, they are building functionality using the APIs directly provided by the platforms, i.e., Apple and Google.  Those APIs change over time.

Usually, a development team will have years to update their code to new APIs as older ones are queued up for deprecation. Overall, this creates a stable environment where developers can deliver products with known risks, and product owners can factor those risks into their roadmaps.

More often than not, there is a lower barrier to build out functionality that takes advantage of platform-specific features to create the best user experience. Animations on iOS come to mind.  Though some of the hybrid platforms can achieve a higher fidelity now and again, there is just no substitute for native code.

There are many examples of platforms, frameworks, corporate experiments that can be leveraged to get across the finish line quicker or cheaper.  There are numerous cross-platform options, some better than others.  Most of these options leverage a bridge between their own language or technology and that of the mobile platform.  Things can get complicated during implementation.  At any point, a company can choose to end-of-life or not support a product, and that can leave you in the lurch.  Parse, a database-in-the-cloud comes to mind as an example.  Many people jumped on parse because it offered easy ways to stand up a data-based application.  Facebook acquired parse and eventually shelved it as a product, forcing many teams to scramble for a solution.

Though native has been our tentpole at Eight Bit, we continually explore other technologies. From where we sit, React Native is very capable. Flutter is also interesting, but we'd like to see it mature a bit before onboarding a client to that platform.

We've used all of them. We choose the structure that best fits the partner and project. It's almost always a question of risk-management and risk-tolerance.

We don't have a set minimum. For new opportunities, we consider the potential for an ongoing relationship. Small one-off projects are not an excellent fit for us. If we think a small project could turn into a longer-term relationship, then we'll keep the conversation going and look for ways to work together. Often we'll bite off a small piece first to test the relationship and get some momentum. We really try to meet people where they are in the process. We're quick to tell people if we're a good fit or not. If we're not, we try to point people in the right direction and connect them with a better match.

The range is wide. $20k on the low end up to $2M. Our typical project rolls in at $200k. Once a project is launched, our partners typically engage with for ongoing support, maintenance, and continuous improvement. This requires a team of five or more people working on frequent releases across multiple platforms (iOS, Android, Web).

We like to do a variety of workshops with our partners early on to dig into the business model, objectives, and key performance indicators. We want to be very clear who the audience is, what value we're creating, and what we're measuring. Value comes in many forms —  productivity, efficiency, and scalability, to name a few. The majority of the apps we build don't generate revenue from direct sales. For instance, EdNavigator is a nonprofit organization that helps busy families and students achieve their educational dreams. We were able to help them scale their operations to allow each team member the ability to serve a more significant number of families. This increased efficiency and productivity can significantly impact an organization's bottom line.