Foxbox Digital is an award-winning engineering-focused product development agency.

Inside the Box Foxbox Digital Blog

Versapay: Digital Payments Mobile Strategy

Foxbox Digital is growing. Here's the July, 2019 update on what's happened.

Company Update -- Here's What's Happened in the Past 6 Months

So much has happened over the past 6 months and I’m excited to share it all with you.

1 -- We changed our name to Foxbox Digital and 

! Our initial “cost-effective” model of developing apps was a great launching point. It became clear, as we grew with our clients, that our value wasn’t about being cost-effective but about helping them build better and bigger digital solutions across mobile and web. So now, instead of “Foxbox,” we are “Foxbox Digital” which also means we are 10,000 times easier to find on Google :). 

Here is a detailed update on the website changes

2 -- We acquired a new enterprise Fortune 100 healthcare client. From initial meeting to closed deal, it took 6 weeks, which is an extremely short sales cycle. I would love to tell you who it is, but due to obvious restrictions in our contract, I can’t spill the beans. However, I can tell you that it’s one of our biggest contracts and it’s a long-term agreement. We’re pumped.

We’re looking for engineers and project managers

4 -- I’ve been working on this 6,000+ word blog post for the past 3 months. It’s 

about how to build Agile products in the enterprise

. It’s funny how life works itself out. I started my career working at Accenture/Avanade doing work for large companies, then moved to found and run several startups as a CTO. Now I help big companies build products like a startup does. I’ll take it.

5 -- We moved to a new office in Wicker Park. Come and say hello. Our address is 

1720 West Division Street, Floor 2, Chicago IL 60622

That’s all for now. Thank you for your continued support!

Many stakeholder ideas sound amazing in the moment, but deciding which ones move forward and which ones do not can give you a panic attack. Here are a few ways we keep quality ideation without being overwhelmed by quantity.

How I Prioritize Product Features From the CEO & Founder

A Simple Way to Prioritize Product Features

It was like clockwork. The CEO would message me daily, if not hourly, on new feature requests, slightly changing product direction each time. He messaged me on every communication channel you can think of: Slack, iMessage, WhatsApp, and email. Whenever it was the most convenient for him, regardless of time of day, he would send me these requests.

These emails contained not only vague future ideas, but small tweaks and non-critical bug fixes, etc. Essentially, anything that came up mid-sprint, he would send me a quick note with his ideas.

A big reason why I enjoyed working with him was his excitement about the product we were building, and he was constantly thinking of new ideas. However, that came at a cost. I was drowning in new things to build, and I didn’t know how to focus these requests.

I appreciated his willingness to share his ideas, but at the same time I had to make sure we were building the right things. I wasn’t necessarily in a position to say no to these new features, even when I was only halfway done with the features we started weeks prior. I actually did care about what he wanted to build, I just didn’t think many of these features were the right decision.

I needed to ruthlessly prioritize our feature requests.

 But, again, who was I to decide what feature was right or not? So, I thought of something to help me alleviate this pain.

After a few panic attacks, I created what I called the inbox system. This was a place in our project management board where I collected all of his, and the team’s, ideas. It gave me a chance to say, “Great idea! Let’s discuss later.” He knows that his idea isn’t lost, and I don’t feel the pressure to act immediately.

In the next sprint planning meeting, we would go through all of these ideas, weigh them against all of the other issues (i.e. features, bugs, cards) in the backlog, and prioritize the things that will have the biggest impact towards achieving our company’s objectives.

The inbox system aims to solve the problem of changing the plan mid-sprint and allows you to slow down and consider your next steps. You don't want a reactionary engineering team where the latest ideas from the stakeholders are implemented over things that have been planned for weeks.

CEO sends feature request (and wants it built ASAP).

Acknowledge her feature idea and document the request in your project management board (AKA, the “inbox”) before committing to building the idea.

During the sprint review meeting, instead of asking the validity of the idea ad nauseum, discuss the priority of this request compared to everything else that needs to be built or fixed.

It was a small tweak, but it made a substantial impact. I was heard. He was heard. And together, we made the best decision for the product and the company.

Some Features Just Aren't Worth Building, Regardless of How Genius It Is

Every feature can certainly not be a winner.

This isn’t 3rd grade where everyone gets a participation trophy and feels like a winner at the end of the soccer match.

Implementing the wrong feature can significantly impact the trajectory and traction of your app. Not just because users don’t like it, but for simply how much effort and time it took to complete.

As a Product Manager or Project Manager, you’ll get a lot of input from your stakeholders. For us, it’s our clients. For businesses, it could be your CEO or boss. It used to give me anxiety when I heard all these lofty feature requests: I felt like I needed to implement all of the ideas my CEO threw at me over email, text, or Slack.

Many ideas sound amazing in the moment, but the luster wears off quickly. If it’s still a great idea during the next sprint planning, then consider implementing it. If not, then discard it—that’s okay to do, it’s part of innovation. All ideas can’t be winners!

When you set out to build a product, there's a disconnect between what you think people need and what they actually need.

How to Define your Minimum Viable Product (MVP)

When you set out to build a product, whether it's a mobile app, website, or a physical product, you'll envision how people will use your product and what qualities they need of your product. What often happens when building products is 

If you take the Lean Startup approach to designing and building your first product, 

, you're more likely to build exactly what your users need, and eliminate waste from building features they don't need.

), and when you're building a startup company, you have real constraints with how much money and time you have to build something. These constraints force you to be smart about what you spend time building; any wasted effort could put you out of business.

The classic model to create a product is called Waterfall, and it doesn't work. With Waterfall, you start by defining all requirements, then design the product, then build it then launch it. This sounds completely logical, but problems arise if requirements change at any point in the process. 

 When this happens, your project goes way over budget and you blow past the deadline.

With a lean approach to building a product, the idea is you take the steps in Waterfall and repeat them many times over. You divide up the problem into several product phases, where each phase fully delivers on a set of objectives.

 objectives of your project. People start using your product early on in the development cycle, 

 People tell you what's working and what isn't, and you can respond by altering the product roadmap.

Think of it this way: if you set out to build a car to get people from here to there, you don't start by building a wheel. That doesn't get you to where you need to go. You could start by building a bike. From there you could build a scooter, then finally a car. At each phase of the project, people are able to use your product to achieve the main objective: transportation. They'll give you feedback along the way ("it's too slow!"), and you'll incorporate that feedback and iterate the product.

This process allows for changes in your product roadmap during active development. Changing requirements doesn't mean pushing back your delivery date - because the process accounts for change. After people use your MVP, you might decide to cut entire features, and improve other features that they actually use.

After the MVP, you'll continue iterating the product in mini releases - every week or so. The product takes shape, change by change, until you've achieved all of your objectives. The product is tested in realtime during active development, so at the end, 

you'll have confidence that you hit the mark.

At Foxbox Digital, we take a lean approach to building mobile apps. We tap into our entrepreneurial experience of building startup companies, and apply that experience to how we build products. We'll help you 

build your product with a lean, agile approach

At the end, you'll have a product that meets your objectives, has the features you need, and eliminates the features you don't actually need. 

This is how you build a product that hits the mark and deliver it on time.

After you've designed and built your mobile app, you have to monitor, maintain and support it for the life of the app.  What's involved?

The Total Cost of Running & Maintaining a Mobile App

After you've designed and built your mobile app, you have to monitor, maintain and support it for the life of the app. What's involved? There's a lot more effort than you might think.

Mobile apps usually need a server in order to operate, called an API. The API is responsible for storing and retrieving data. For example, when you create a new account as a user, the mobile app talks to the API to create that user.

At Foxbox Digital, we host our client's APIs on 

. This is a server farm that has redundancy built in on every level, so that if any single component fails, your app still runs. If the API server goes down, there are more just like it that continue to operate. If the database server goes down, there's a failover server that takes over automatically. Even if the power goes out, there's a backup generator to keep the servers running!

This type of hosting is called high availability, because your app is available as close to 100% of the time as possible. Building and configuring this type of high availability infrastructure is not a trivial task, but it's critical to ensure your app always works.

If your app goes down for any reason, the engineering team needs to know about it. At Foxbox Digital, we have a monitoring system that constantly checks to ensure the servers and the API is running 24x7. If anything happens, 

it immediately notifies our engineering team

. When this happens, we respond to the problem and take action.

It's common for errors to happen when users interact with your app in a way that you didn't anticipate. We call these bugs, and usually they are small, but sometimes they are serious.

Both the mobile app and the API needs error monitoring to ensure that when an error happens, an alert is triggered and the tech team is notified. At Foxbox Digital, 

we actively monitor our clients' apps and the API and trigger alerts when an error occurs

. We respond quickly to fix the bugs in order of urgency.

Here's a view of the error dashboard of one of our apps. The tool is called Sentry and it notifies the team on Slack, our internal chat tool. The first one is happening frequently, and the engineering team is working on a fix as we speak.

You need your API to be fast so that when users interact with your app, the experience is as fast as possible. This is why we actively monitor the performance of your API. We're able to identify performance issues in any part of the app and we use tools to give us detailed insights into what's happening.

For example, if you have a surge of users, we'll scale out your servers to support the added usage. Or if just one component, like searching, is really slow, we'll dive in and figure out why so we can fix it.

We don't compromise on application performance.

Upgrade App to Support Latest iOS & Android

Every time Apple and Google releases a new operating system, apps need to make changes to support the latest specifications. If you don't, you risk Apple or Google pulling your app from the App Store or Google Play. These upgrades can take a lot of time and are sometimes complicated.

Apps are built by using a set of frameworks, tools, and reusable components. On occasion a security update is released for one of these components, and the application developer needs to upgrade the app and apply the security fixes. Without regularly patching your app and API, the security of your app and data are compromised, and that is unacceptable.

At Foxbox Digital we regularly upgrade all of our clients' apps to apply the latest security upgrades and bug fixes. This keeps our apps running fast, smooth, and secure. As soon as we patch each app, we release it to the App Store and Google Play.

It's normal for an app to have some bugs - even the most well-tested apps do. When a bug is identified from our error alerting system, we respond quickly to fix it.

At Foxbox Digital, you have a direct line to reach out to our support team. If you need to make changes to your app, or if you just need help with something, we're here for you, when you need us. Our clients have 

At Foxbox Digital, we handle the hosting, monitoring, maintenance, bug fixes for you. We also specialize in 

. You'll also have unlimited access to our premium support. You'll have the 

 of knowing that your app is running smoothly, forever. And if anything happens, you know that someone is actively monitoring it and working on a fix.

We're your trusted partner, for the life of your app. 

Let's compare the best cross-platform app frameworks (React Native, Ionic, Cordova, PhoneGap) to develop for iOS and Android at the same time.

Comparing Ionic vs Cordova vs PhoneGap vs React Native

I set out to build an app for myself called 

 (it’s the insider’s guide to the city).

I looked into the cross-platform frameworks available so I could build it for both iOS 

 — Apps created with these frameworks are basically websites created with HTML, CSS, & Javascript, smushed into app form. It 

 like an app. When you interact with the app, it feels slightly sluggish and not responsive.

 — This framework take an entirely different approach to hybrid cross-platform apps, and uses native UI elements, powered by Javascript. You write your app in Javascript, then 

 works some magic and turns the user interface into 

. This means that when you touch & feel your app, it 

React Native apps are snappy, responsive, and a joy to use.

. I argue that it takes less than half the time to build an app compared to full native apps, because not only do you have to build an app once instead of twice, it’s just faster to build the first app period.

Under the hood, React Native uses Javascript to run the business logic, for example handling a button click or fetching data from a server.

Technically it does this with a headless browser. Because of this if you don’t program the app right, you may see some slowness.

There are ways in which to program the app however that eliminate this problem and the user will never know the difference between a pure native app and a React Native app.

Companies including Instagram, Facebook (parts of their app), Bloomberg, & Skype (

From a technical perspective, it wins some points because it uses technology many developers already know: Javascript and React. Web developers don’t have to learn an entirely new language (Objective C, Swift, or Java); they just apply the skills they already have to a new form factor, mobile.

So how did the app come out? Speakeasy is snappy, responsive, and I bet you couldn’t tell it’s a React Native app.

React Native strikes the perfect balance in creating cross-platform apps because it’s super fast to build them and the apps look 

 feel like native mobile apps. The end result is a polished, snappy and responsive mobile app.

You write the apps in Javascript, which is one of the most popular programming languages and use the React framework which is a revolutionary and brilliant framework.

React Native isn’t great for games or anything with complex animations. But for most apps that simply display and let you edit data, it’s a great choice.

React Native is a great choice for 80% of the apps out there.

I envisioned a mobile app development company that takes a radically different approach to building apps.

How We Create Beautiful Mobile Apps in Half the Time

Here’s the story of why I created Foxbox Digital, a different kind of mobile app development company.

 we needed to build a mobile app to complement our existing web app. We were a team of web developers and didn’t have experience building iOS or Android apps. We reached out to some local app development companies in Chicago to get quotes on what it would take to build the app. The quotes were really high, and that was for 

. And after that, we’d need to have them build the Android app too.

We’re responsible for hosting and supporting the API that actually runs the app. We ended up finding a freelance iOS developer to build the app, and he did a killer job. It cost a ton of money though, and at the end of the day we could only support half our users because the other half were on Android.

 I understand why mobile app development companies charge so much for a mobile app — developers are expensive, and in-demand. But isn’t there a better way?

, Ionic, and Cordova. Ionic and Cordova apps look like native mobile apps, but they don’t feel like them — they’re slow and sluggish. React Native strikes the perfect balance because they’re fast to build, and the apps look and feel like native mobile apps (snappy and responsive). And it’s simply a joy to program the code. 

With a cross-platform framework like React Native, we build both the iOS app and the Android app at the same time. 

This cuts the development time (and cost) in half

Through our engagement with Home Chef, we developed and published both iOS and Android apps using React Native.

This helped them significantly increase app store ratings, meal kit conversions, and user engagement rates. 

The mobile app is only part of the solution though — every mobile app needs an API to power the app. An API is the server and software that the app communicates with in order to do what it needs to do (i.e. get and store data). Once you have an API built, you need to host and maintain it. As a client, do you want to be bothered to maintain an API?

I thought about all of the things that you need to do in order to keep your app up and running in the app stores.

Mobile App — build it, launch it, maintain it (fix bugs and security issues).

API — build it, build servers to host it, maintain it.

Monitor the API to ensure it stays running and respond to issues as they come up.

Upgrade the mobile app every time Apple or Google releases a new phone or operating system. Re-release to both app stores.

Do clients really want to do all of this?

 We’d use reusable building blocks to create the core of the app, and a finely tuned process to develop them. With this approach, it’s much easier to predict how long it will take to build the app.

 that handles everything from design to building clients’ apps to keeping them up & running, for the life of the apps. We’d be a trusted partner to our clients, so they wouldn’t have to worry about anything involved in building or running their mobile apps.

Foxbox Digital creates beautiful cross-platform mobile apps  in half the time. We handle everything involved in running and maintaining your app, for the life of the app.

 and let's come up with a strategy to build it.