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

Inside the Box Foxbox Digital Blog

Versapay: Digital Payments Mobile Strategy

The “Foxbox Way” serves as a framework for our culture and values at Foxbox Digital. Every single piece of code we write, every interaction we have with our clients, and how we communicate with each other are all part of the “Foxbox Way.”

The Foxbox Way

The "Foxbox Way" serves as a framework for our culture and values at Foxbox Digital. Every single piece of code we write, every interaction we have with our clients, and how we communicate with each other are all part of the “Foxbox Way.”

This is not just a guide for new hires but serves anyone who works at Foxbox, including our leadership team and founder. How we hire, the clients we serve, and even how we act outside of the office are all part of the Foxbox Way.

 It is unique to us, and that’s why it’s the "Foxbox Way."

One of Apple’s famous ad campaigns was a campaign called "

." In this short video, they featured icons who changed the world (including Albert Einstein, Amelia Earhart, and Martin Luther King Jr., to name a few) and challenged people to think differently. As part of his 

, Steve Jobs said, “If they ever used a computer, it would have been a Mac.”

A big reason we created the Foxbox Way is to drive clarity on who would make a great Foxbox team member, and who would make a great Foxbox client.

We believe in Moving Purposely. This means everything we do is thought through. It means we value proactive actions versus reactive ones. It means we measure twice and cut once.

At Foxbox Digital, every associate on every project knows that our work is mission-critical to our clients. We take that responsibility seriously, and that shows up in the work we do and how we do it. Sure, we love to engineer solutions but we want to make sure there’s a purpose behind what we’re building, and we’re communicating with the team and client before we start coding away.

We believe that in order to make an impact, you must do it purposely. We’ve seen too many failed projects that never made the originally promised impact because they were trying to solve a hypothetical problem, instead of a real one. Instead of blindly following project requirements, we like to build with a purpose. Solve real problems for people. Release your software early with a minimal feature set then keep building and incorporate what problems actually come up from real users.

When you approach everything you do with a purpose and resilience to succeed no matter the circumstances, you’re able to make a positive impact everywhere you go. This is why we only invest in talent who are determined to succeed, and partner with clients who are purposeful in their mission. We exist to make an immediate and long-term impact on our clients.

Just like the fox (the animal), every step we take is intentional, calculated, and efficient.

We are a hungry group of engineers, entrepreneurs, and leaders who have something to prove.

We’re still a fairly new digital agency, even though we’ve had impressive growth. The drive to bring our clients to a better place is the foundation of success at Foxbox Digital. This means we should operate as if every client’s business is our own.

We’ll challenge every feature, celebrate every win, and stay up all night fixing whatever impedes our client’s future growth. There’s no reason that Foxbox Digital can’t grow to 500 or 5,000 people in the next 5-10 years.

All of our new hires tend to have a mixture of a great technical skillset and be naturally ambitious. We ask that you work like you have something to prove.

If you have a crazy idea on how to solve a problem, try it out. Failing is not just okay, it’s recommended. We’re building software, not performing heart surgery. Communicate your plan with your team and try to validate or invalidate your idea as quickly as possible. If it works, it’s a win for your client, your team, and for you.

As a company, we try new things all the time. We’ll experiment with a new service offering, and if it doesn’t work, we end it with little fanfare. We also experiment and evolve the way we manage projects. Some ideas work, some don’t, but by taking risks we ultimately improve the way we deliver.

Without taking risks, we would not exist. The opportunities that await us are endless, but we do have to pursue them. We’re not a "bet the farm on a single idea" type of company, but we’re not a “let’s sit back and see how this all plays out” type of company either.

We are communicators and translators first, engineers second.

Many of our customers are not technical, and that’s a huge reason why they hire us. They already trust us to get the technical work done. When speaking with our clients, it’s worth talking about what we’re doing technology-wise that will benefit their business.

They most likely will never know what concurrency or pattern matching is. However, they do need to know that the solution was architected to focus on speed and scale. They might not know the inner workings of Scrum or Agile, but they do need to know how we operate our projects.

Use metaphors to help them understand complex technical topics in a simple, relatable way. For example, to explain concurrency to a client, you can say, "We’re increasing the overall speed of the application, and allowing it to handle more transactions without increasing your server costs. That way, if you get a huge increase in users, you won’t need to reprogram it. It’s ready to go from day one. WhatsApp uses concurrency for their platform, and it works well.“

A good trick to explaining technical terms to a non-technical person is to Google <technical term> + benefits. So, DevOps benefits, Concurrency benefits, etc. These results will give you the layman’s terms for any technical thing you’re talking about.

We’re all excited by new technology, but it’s important not to use technology for technology’s sake. Blockchain, Serverless APIs, AR, and Graph Databases are all really cool, interesting pieces of technology, but they’re often not the best or simplest solutions to the problems we need to solve. Focus on the problem you need to solve and think of the simplest, most elegant solution to solve it. Obsess about the problem, but don’t get caught up in all the new shiny technologies.

As a general rule of thumb, we should stick to using the technologies we know and use across all of our projects. If you want to bring in a new major technology, you’ll need to sell your idea to your team and your architect.

Be prepared to explain why it’s so important and why nothing in our existing stack solves the problem. This is how we brought in Typescript and Hooks, but also how we turned down using Redux-Saga in order to stick with Redux Thunk, which works just fine to solve the same problem.

Our clients get excited about solutions. We get excited about problems.

Our clients pay our bills. In fact, the clients are our only way of making money. They have a clear product vision and hire us to build it. This means they tend to say "build this" and honestly expect us to do as they say. Most other agencies will simply build what the clients want, but not us.

Companies hire us to help them achieve goals. Sometimes what the client asks for is not inline with their own goals, and that’s when it’s our job to challenge them.

For example: A client asks to build a feature for a problem they are anticipating. They’re trying to predict the future, and we may just waste our time (and their budget) if we build it for them. Instead of solving this hypothetical problem now, you should propose to release what we have to customers and solve the problem when it actually happens. Chances are, the problem will never occur, and your client will thank you for being more efficient.

A real-life example: On a previous project, the client had designed a complex image recognition component where the app would read pieces of data from a paper form. The problem is there is no standard template, and it would have been inaccurate and unusable. Instead of building what they asked for, we proposed an alternative solution that is less automated but puts the user in control and will be more than 95% accurate. The client loved our proposed approach, thanked us, and asked us to implement it.

Challenge them in a respectful way by communicating "why" and your alternative solution. Remember, we are communicators and problem-solvers first, engineers second. In the end, though, the best we can do is recommend and advise, the client gets the final say.

 is a great book that goes into more detail on this topic.

Here are three points from the book that stand out and are especially relevant for our clients:

Let the other person feel the idea is his or hers.

 People inherently like ideas they come to on their own better than those handed to them on a platter. Ideas can best be carried out by allowing others to think they arrived at it themselves.

Honestly try to see things from the other person's point of view.

 Other people may often be wrong, but we cannot condemn them. We must seek to understand them. Success in dealing with people requires an empathetic grasp of the other person's viewpoint.

Be empathetic with the other person's ideas and desires.

 People are hungering for empathy. They want us to recognize all that they desire and feel. If we can sympathize with others, they will appreciate our side as well and will often come around to our way of thinking.

The job of the leaders is to support and empower the team. Some call this Servant Leadership, where leadership’s job is to serve you as the builders. Project managers provide developers clear requirements. Software architects unblock developers, help design solutions, and communicate the plan to the client to shield developers from attending meetings.

Your architect designs complex technical solutions, but they also need buy-in from their team. However, leaders are often wrong. Your team should always challenge them, and leaders should listen and make changes accordingly. And of course, just like we do with clients, challenge leaders gracefully.

Rob Volk story: At my last company where I was CTO, I presented my technical plan for a complex feature to the team that I spent the previous night designing. An intern on the project had the audacity to speak up during the meeting to challenge my design. He proposed another way to solve the problem, and it was much better. The team agreed with him, and so did I, and we went with his solution. After that meeting, I took him aside and thanked him for having the courage to speak up and challenge the CTO’s vision.

We pride ourselves on building clients for life. This means our goal for an initial engagement is to knock it out of the park, and also build a trusted partnership where we can help them with future engagements. This is a mixture of them telling us what they need, and us uncovering how else we can help them.

The opportunities are endless for us to partner with our clients and build mutual respect. We aim to grow relationships we will value for years to come.

There are going to be times when you have to make an engineering or product decision that will impact the client. For example, your first option will take a lot longer to do, but will greatly benefit the client, and your second option is shorter to do, and the client might not even notice.

In these situations, we ask that you do what is in the client’s best interest, even though that means it’s impacting our profits on the projects. These little decisions add up to make better products and happier clients.

Of course, there are limits to this, and whenever in doubt, reach out to your project lead on the best next steps.

We aren’t foolish to think that we have everything figured out. We know we have blind spots.

Think it’s helpful to discuss new books with the team? Start a book club. Hate the way we report issues on Gitlab? Propose a new solution and trial it out. If you see something broken or see a new opportunity, it means your team probably notices the same. Propose it to the team and own it. If it needs a budget, let Rob know.

Our clients are, of course, always #1. So, as long as what you propose doesn’t take too much time away from your core responsibilities, we will approve it.

We believe that putting client interests first and continually adding value to their businesses ultimately leads to unexpected returns. 

Give away your knowledge. For example, if you have the opportunity to mentor a developer on your client’s team, go for it. Don’t be concerned about teaching your way out of a client. You’ll actually become 

 valuable in your client’s eyes for helping them. 

We also believe in giving graditude to those who help 

 along the way. It feels good to receive gratitude and it actually helps us when we give it.

Whenever you’re given the chance to give first, do it. There’s a wonderful book on this topic called 

However, under no conditions should you risk the quality of what you’re building or detract from your core responsibilities. Stay away from stop-gap solutions as much as possible.

Build it right the first time, even if it means delaying when the feature will be complete.

All meetings are important (if they’re not, please tell us, so we don’t waste your time!). Some meetings, though, you absolutely cannot miss. Here are the two types of meetings we ask you to attend.

 We have a one-hour monthly meeting with the entire team. We don’t often get a chance to meet as a group, and this meeting is a great way to do it.

: We generally operate on a 2 week sprint schedule, and there are recurring meetings within it that must be attended. They may differ depending on what team, but generally speaking, those meetings are Backlog Refinement, Sprint Planning, and Demos. Those meetings are opportunities for you to learn what the goals of the sprint are and to be able to coordinate activities so no team members are blocked. We also use this as an opportunity to show off your best work.

We understand that things come up where you absolutely can’t make a meeting, and in those cases, please let the meeting organizer know as soon as possible. You should confirm your attendance to all meetings, so the team lead can get an accurate understanding of who is attending and who is not.

The number one rule for our team is that we must COMMUNICATE. We do this because it makes us a better team, a better firm, and, ultimately, a better final product.

Being a global and, mostly, remote team means communication is a must. This means both internally AND externally. At no point during a project lifecycle should there be any mystery as to what’s happening, who’s responsible, "Is it done?" “What’s left to do?” “Are we making money on this?” “Are we going to hit the deadline?” Etc.

The Foxbox Way includes open, consistent, bi-directional (that means listening and speaking) communication between all parties. We use a variety of tools to accomplish this (Slack, Zoom, email, text, in-person discussions, weekly meetings, etc.).

You’re encouraged to have and voice opinions—even dissenting ones.

You’re MANDATED to openly and quickly communicate any issues, concerns, problems, or missed deadlines. That means if you know we’re going to miss a deadline, communicate that as early as possible, not at the deadline! People are rather forgiving if they know in advance. Please, no surprises.

Take a peek into how this concept works at Pixar: 

https://hbr.org/2008/09/how-pixar-fosters-collective-creativity

We love Slack. It’s our main method of communicating internally and with our clients. However, we also recognize it’s a huge time sink. We have three main rules when it comes to using Slack (and other communication tools):

You don’t need to respond to Slack messages right away (seriously).

Video calls > phone calls and daily stand-ups > meetings.

Protect your mornings (and evenings) for deep and focused work.

Everyone has their own working style, but for the most part, productivity means doing your best work in times you can fully focus while minimizing distractions as much as possible. Your goal is to achieve deep work in order to accomplish things. If that comes at the expense of not being immediately accessible and responsive—that’s a good thing.

Here’s a more detailed article I wrote about how Slack is ruining productivity

We are not a grow-at-any-cost type of company. We prefer to hire kind, thoughtful team members. Being rude has no place at this company. Honesty is great, but honesty for the sake of hurting someone's feelings won’t be tolerated.

When giving feedback, it is OK to give your honest, truthful feedback. Instead of saying, "I think this thing sucks." It should be, “Have you thought about this?” or “What do you think about this alternative?”

https://hbr.org/2018/11/making-kindness-a-core-tenet-of-your-company

https://thriveglobal.com/stories/value-of-kindness-in-business/

https://www.entrepreneur.com/article/326114

https://www.forbes.com/sites/forbescommunicationscouncil/2017/07/25/why-kindness-matters-in-the-workplace/#550f848570c7

Rob Volk is the founder and CEO of Foxbox Digital. He started his career working as a technology consultant for Avanade, which was a Microsoft + Accenture joint company. He was able to work with a lot of big companies like Pfizer, USPS, and Morgan Stanley, mainly helping them build enterprise applications.

Most of the work done was traditional waterfall-type methodologies, which caused a lot of project issues and delays. How software was built for enterprises was broken, so a big reason Foxbox was created in 2018 was to help organizations build and deploy software with the agility of a startup.

He also had entrepreneurial and technical roots prior to starting this company. He was the CTO of Beyond Diet and implemented technology that scaled to over 350k+ customers, and was the CTO and Co-Founder of Detective (detective.io), a venture-backed intelligence platform that amassed 200k+ users in a short time frame, and was a $1MM ARR business.

Our first major client was Home Chef. This was, and still is, a big deal. Home Chef got acquired by Kroger, and at the time we were working with them, they were #2 on the Inc. 5000 fastest growing companies.

We helped them rebuild their mobile product in React Native for Android and iOS. Their CTO hired Rob to lead the development effort and train their team on React Native. It was a successful launch, and this gave us the confidence to move to bigger companies and projects.

Prologue

First, some history

Chapter 1 What is Elixir?

Chapter 2 Why Elixir Is Better Than Ruby for Your Business

Chapter 3 What’s Right with Ruby

Discord

Pinterest

Bleacher Report

Cars.com

Chapter 4 What Companies Use Elixir?

Chapter 5 The Best Elixir Resources Online

Chapter 6 Where Should I Start?

We’ve been using Elixir for the past 24 months, and I thought it would be a good idea to write down my thoughts on Elixir vs Ruby and why our engineering team decided to stop programming with Ruby altogether and put all of our efforts behind Elixir.

Elixir is designed for programmer happiness. Here is why Elixir is better than Ruby, and why you should choose it as your programming language of choice.

Elixir vs Ruby | How Switching To Elixir Made Our Team Better

Ruby wasn’t always a popular or mainstream language, but it did gain more popularity with the creation of 

Ruby on Rails by David Heinemeier Hansson

 (a fellow Chicago resident) in 2005. We used Rails as our primary web application framework for quite a bit.

When Elixir grew in popularity, we were quickly dazzled by its uncanny resemblance to Ruby, the language we already loved and cared about. The more we learned about Elixir, the more we understood its strength over Ruby and how it could tremendously benefit our business.

Fast-forward to present day, and the Elixir vs Ruby debate has been solved. We have switched completely to Elixir and thought it was one of the most important and best decisions we have made for our business.

The creator of Elixir, José Valim, was actually a Ruby developer himself.

So the first language I became really proficient in, really confident with, was Ruby. What I really liked about Ruby was this ability to explore, because the language is unrestricted and you can try out different things. And it’s very flexible—you can change it in many different ways. That was really what attracted me to Ruby at the time. [

José loved Ruby so much that in the earliest version of Elixir, he experimented with running Ruby in Erlang virtual machine! At the time, he was frustrated with inconsistent behaviors when running Ruby on multi-core machines. Concurrency was a very hard problem to solve in object-oriented programming languages, and José was not the first one to discover this.

However, he realized that in functional programming languages such as Erlang, the problem doesn’t even exist in the first place. This sort of lateral thinking opened up the path to solving many kinds of issues inherent with Ruby, such as background processing, long-running tasks, and process monitoring; while also incorporating the strengths and features from other programming languages such as Clojure, Haskell, and Python.

You can find a solution to the problem, but if you can make the problem disappear altogether, then, yeah, I’ll take that.

Most importantly, Elixir was designed with programmer happiness in mind, stealing Ruby’s main selling point. Elixir is growing as a mature language and should be acceptable for a demanding Ruby programmer.

Here is why I think Elixir is better than Ruby, and why you should choose Elixir as your primary programming language of choice. But first, let’s talk about what Elixir is exactly.

Chapter 2: Why Elixir Is Better Than Ruby for Your Business

Chapter 5: The Best Elixir Resources Online

Elixir is a functional, concurrent, general-purpose programming language that runs on the 

. It is an excellent choice for any situation where performance, productivity, and scalability are top priorities, especially web applications and IoT development projects.

Elixir runs on BEAM, known for running low-latency, distributed, and fault-tolerant systems, while also being successfully used in web development and embedded software domain.

Erlang was created in 1986 by the Ericsson company to deal with the increasing demand for processing power within the telecom industry. It was designed to handle thousands of phone calls in a single PABX.

Erlang was released as free and open-source software in 1998. Although Erlang has remained an obscure language for most of its existence, its popularity is growing due to the demand for concurrent services (which I’ll explain in a bit). Erlang is also used in massively multiplayer online role-playing game servers, mainly because of the performance and scale that Erlang offers.

Cisco also said that 90% of the internet 

For context, Foxbox is a digital agency that builds mobile and web applications.

The companies we work with often come with user bases that are large enough to run into serious scaling and performance issues. Our engineers are exposed to almost all imaginable engineering problems you would probably come across at any stage of a typical tech startup. So, choosing the right programming language is not just important to guarantee the success of our clients, but also the survival of our business!

With that in mind, here’s why we found Elixir to be better for our business than Ruby:

Let’s be honest—we are excited about Elixir’s effortless handling of concurrency, but it’s not the main reason we stick with it. Elixir is a highly-productive language. Here are some reasons for that claim:

 — Utilizing the BEAM virtual machine, one can expect to have a consistent development experience on almost any machine—even Windows. While this can also be true for Ruby, as a project progresses, a typical web application in Ruby accumulates more dependencies that make it increasingly difficult to get it up and running, while an Elixir web application would remain relatively easy to set up.

 — Elixir enforces true lexical scoping and encourages explicit codes. What this means at the code level is that Elixir makes data transformations, code organizations, and application interfaces much more predictable and easier to reason with—thus saving a lot of development time.

 — This is probably the most undermentioned, yet most powerful, benefit of using Elixir. Elixir provides developers access to super-fast, concurrent testing with relatively minimal impact on hardware performance. Ruby testing, on the other hand, can be painfully slow and hardware-intensive—to the point that it could bog down the whole system for those with underperforming machines. Elixir completely takes away the headache by making tests faster.

 — We have used Elixir to build a quick MVP project to building large-scale projects. In both scenarios, Elixir provides powerful built-in features to satisfy the requirements for a typical modern web application such as caching, background processing, and process monitoring. On a platform such as Ruby on Rails, these solutions usually come with tightly-coupled dependencies on services such as Redis, Resque, and Foreman.

I will admit, at first, I was extremely frustrated with Elixir. I struggled with pattern matching, which was touted as this revolutionary new concept. After getting used to it, and all of the other advantages of Elixir, I have found myself coding with less effort and frustration to achieve the same exact output as Ruby. There are two reasons for this.

Functional languages, as opposed to object-oriented languages like Ruby, are “beautiful” and simplify programming. I greatly favor functional languages for several reasons:

It leads to coding faster and more predictably.

No state to keep track of! State makes it extremely difficult to track down problems. There are no reference errors. Everything is a pure function, which is wonderful.

One of the biggest advantages and differentiators of Elixir is pattern matching. Pattern matching comes from its Erlang roots and is one of those things you wish was also incorporated into other languages.

put together a code sample comparison between Elixir and Ruby

In that example, pattern matching makes the code more elegant, expressive, and easier to read. It may seem like a small thing, but I find myself using pattern matching any chance I get.

Programming is a mixture of fun and frustration. I find Elixir to be slightly more fun and a lot less frustrating than Ruby. Elixir, a dynamically-typed language, has type-safe and guards built-in, along with pattern matching, which significantly reduces the bugs.

This results in fewer compiler errors. And for the bugs that do exist, they are easier to find because of the compiler. Compiled code is a huge safety feature. In Ruby, bugs can remain hidden until someone hits them; in Elixir, the compiler will find most of them.

Safety → Fewer Bugs → Easier to Track Down Bugs → More Fun → Happier Team → Happier Me.

Elixir compiles into BEAM bytecode, so it inherits all the performance benefits of Erlang with almost zero penalties. On the other side, Ruby requires an interpreter that reads its code line-by-line during runtime. While choosing the right kind of production-ready Ruby interpreter for your application is already an uphill task by itself, squeezing more performance out of Ruby often requires strict adherence to Ruby’s do’s and don’ts. Want to concatenate strings? Sure. Want to make it run faster? Use string interpolation instead!

Elixir liberates programmers from having to carefully craft their codes based on an endless list of “best practices” for the sake of making their codes run just a tiny bit faster, and focuses more on producing codes that satisfy the needs of your business.

To be fair, Elixir may also have a similarly long list of performance best practices, but they come at a much later stage of development. Moreover, since Elixir is a compiled language, most performance issues can be caught by the compiler automatically, reducing the time and effort to write efficient, performant code.

Remember how I said Elixir was fun? Well, the way concurrency is handled in Elixir is one of the reasons I don’t see myself programming in other languages (unless I absolutely need to).

, you can understand how frustrating it is. The same program can generate different results if not handled correctly. You have to deal with locking, race conditions, and bugs that are difficult to solve.

The beautiful part of Elixir is that concurrent libraries are built into the language. You won't need third-party dependencies to achieve scalable, safe, concurrent programming.

These two reasons are a HUGE selling point for Elixir.

Cheaper to run: achieve more with less hardware

Ruby applications take up a lot of memory on a server because you have to run many instances of that app to handle multiple requests. Why? Ruby is effectively single-threaded because it has something called the 

 that enforces only one thread run at a time.

Elixir applications can handle magnitudes more requests per instance because it's concurrent and compiled (much quicker execution time). You can run a single instance of an Elixir application on a server to handle a huge number of requests. That lowers your memory utilization considerably.

When it comes to data processing, both Elixir and Ruby are considered expensive solutions in terms of memory compared to languages such as C, Rust, and Go. But in the world of concurrent data processing, Elixir and Erlang have a robust pre-built infrastructure.

With the smaller door (Ruby), you’ll have to wait longer for people in front of you to get in. On a wider door (Elixir), more people can get in at the same time.

Elixir handles concurrency in a really efficient way, allowing for more concurrent connections with the same hardware.

Elixir is built on top of Erlang, a battle-tested 40-year-old language. Erlang runs highly concurrent applications like WhatsApp.

This title and quote from Wired is a great Erlang case study: 

Why WhatsApp Only Needs 50 Engineers for Its 900M Users

Additionally, Elixir has Phoenix, a world-class web framework for modern web apps modeled on Rails, which we all know and love.

 you can leverage while building your application. Not everything is available in an Elixir package, and for those cases, you can run any Erlang package natively from your Elixir application.

. It hasn’t caught up to Ruby, in terms of job posts on Hacker News, but as you can tell from this graph below, it is trending upwards while Ruby is trending downwards.

From my experience, since Ruby has been around for much longer and is easier to learn, there are a lot of great Ruby programmers and many who have a lot to learn. This makes it a little bit harder to hire Ruby engineers since you’ll have more candidates to filter through.

Let’s talk about the positives of Ruby. Essentially, why should someone choose Ruby?

Ruby is easier, and many developers already know it.

Ruby has been around longer (there's a Ruby gem for everything).

The sheer number of Ruby gems available is a lifesaver for developers. Any problem you’re facing has likely already been solved by someone else, available as a Ruby gem.

It's easier to hire a skilled Ruby developer, there's no question about that. There are a ton more in existence. We struggle to find skilled Elixir devs. What we find is motivated Ruby devs who want to learn Elixir, but then we have to train them.

Although Elixir is much smaller than Ruby, it's a growing community.

How Switching From Ruby to Elixir Made Our Team Happier and More Productive

2019 was an incredible year for Foxbox Digital. Here is the good and the bad of the year. It’s been a great journey, and we are ready for the next decade!


Foxbox Digital 2019 Year-In-Recap

When I first started Foxbox in 2018, I knew what I set out to achieve, but I honestly had no idea what it would become or how it would evolve. So, let me start by saying thank you to everyone who has contributed to making 2019 an amazing year.

2019 was by far our best year, not just in terms of revenue and headcount, but a sort of confirmation that what we’re doing is working and making an impact. We’ve also increased our confidence in the role we play in the market (and even the role we don’t play).

We definitely found our stride by figuring out our core strengths and identifying some differentiators from our competitors. But, for this recap, I wanted to not only cover the good, but also some of the things we learned the hard way.

I’ve never been a big fan of, “EVERYTHING IS GREAT, LOOK AT US!” When, in reality, the exact opposite is the truth. Business is hard. So, my goal with this is to share a behind-the-scenes look into growing a business, the good and the bad.

We Nearly Tripled Our Headcount, Moved Into a Chicago HQ, and Opened a New Development Center in Santa Fe, Argentina

We crossed our stretch 7-figure revenue goal, which is incredible. We are only a 2 year old company, and crossing this mark in our second year is a huge accomplishment. We expanded our team from 8 to 25 people, including 20 full-time equivalents. We opened our headquarters in Chicago and our first development center in Argentina, which I will talk more about below.

Overall, this definitely beat my expectations, and we’re on an incredible growth path.

Additionally, we’ve placed a much bigger effort into hiring more senior talent and promoting the highest performers. We brought in 

 as our VP of Engineering and promoted Jasmine Slivka to Head of Project Management. We also hired on 

 to our agile-related projects and Syamil MJ as Software Architect.

We Added More Clients to Our Client Roster, With Many More Extending Through 2020

One of our biggest goals in 2019 was to continue to add value to our clients beyond the initial project, and many of our clients renewed their agreements after the first scope of work. The three clients who didn’t renew were mostly out of our target audience, as we refined our core strengths.

We also signed a large healthcare company in 2019, and we’re happy to announce that we have an extension in place to last us through the rest of 2020. This has everything to do with our new executive team, team layouts, and an increased focus on core engineering skills.

, which we’re really proud of. It’s amazing how businesses are really being impacted by digital.

How NSLC’s Move to Digital Increased Parent Communication, Student Engagement, Staff Productivity and Program Referrals

We definitely upped our game in terms of building in-person relationships with our clients. Yes, everything can technically be done remotely or in our office, but once we made the attempt to be on-site with clients during key meetings, projects went smoother, and communication was improved. This meant a lot more flying for many in the executive team, but it was well worth it. It’s a win-win for everyone involved.

I’ve always had a lot of ideas to talk about but never dedicated the time to do it. This year, I decided to bite the bullet. Here are a few that we’re most proud of:

Agile & Scrum: How to Build Better Products, Faster in 2020

Why CTOs Should Choose React Native as Their Mobile Development Platform

Inside the Box

Articles, updates, and ideas you can put to use.