Local or Offshore: Considerations When Selecting a Development Team

When you set out to build your next custom software project, be it a web app, mobile app or API, cost is and always should be a concern. Custom software projects are almost always accompanied by a substantial amount of development hours to bring them to life, the cost of which can be a hard pill for cash sensitive startups, entrepreneurs and organizations to swallow. So you’ll likely find yourselves faced with the question: do I hire local or outsource overseas?

Today, we’ll be discussing the details of overseas development and why a local software team can often save you in the long run.

Communication, Communication, Communication

In our experience, a project’s success often hinges on successful communication between the client and the development team.

Yes, practical details such as time zones and modes of communication are important (Can you pick up the phone and call the development team? What about a face-to-face meeting? Will your questions be answered in an acceptable amount of time?), but beyond the nuts-and-bolts, it’s important to place value on the ability for your development team to truly understand your project. Do they understand what you are asking to be built? Does the team understand your overall strategy for the app? Are they able to push back and offer alternative solutions or advice during technical challenges?

Building a custom app is rarely a cut-and-dry project and quality communication as your big idea is being brought to life can make all the difference.

Total Cost, not Hourly Rate

It almost goes without saying but is still important to mention here that when considering the dollars and cents of the development team you hire, think about what the total cost will be, not the hourly rate.

An hourly rate of $150+ for an experienced local developer may seem like a lot when compared to an overseas developer charging one-third of that (or even less), but take the time to consider the value that can be provided during that hour. An experienced local developer may work more efficiently and avoid many more pitfalls than a potentially inexperienced overseas developer. In the end, you may find yourself coming out even or ahead by staying local.

Quality of Work

Building a web app or mobile app is no easy task. Besides the strategy of the app itself, you’re also juggling marketing, revenue models, operations and more. The last thing you want to worry about is the quality of the work you’re paying for.

At Oak City Labs we know the value of quality assurance, continuous integration and automation, which shows in our final product. Whether you’re working with a team based locally or overseas, it’s incredibly important that you feel confident in the quality of the work being produced. When your app has its public launch in the app store and you see hundreds and thousands of downloads that first day, you won’t want to find out at that time that the quality is far less than you expected.

As you are evaluating the quality of any software team (local or offshore), consider the following questions:

  • How often is the software team going to provide beta releases so you can review and test? How soon during the development phase will you see these?

  • Who on the development team will you be talking to during the project? Will you be able to speak with the developer working on your project? Does the team provide regular status updates or weekly reports reviewing progress?

  • Will you have access to the code base (even if you aren’t technical) should your relationship go awry?

  • What is the software team’s experience with the release process? Have they successfully released projects to the App Store, Google Play Store, etc.? Do they have a tried and true method they follow for QA, bug fixes and releases?

  • What is their philosophy on building products from scratch vs. using existing third party libraries?

If you’re looking to get started on developing your custom app idea and need help navigating the pros and cons of working with a software team locally vs. overseas, we’d love nothing more than to chat with you further!

3 Tips for Releasing your App to the Google Play Store

If you’re in the process of preparing to release an app into the Google Play Store, you may find these quick tips helpful.

Package Name

Before releasing your app into the Google Play Store, you should review and confirm your app’s package name. It cannot be changed once the app is released. The package name looks something like “io.oakcity.appname” and is your app’s unique identifier on the Google Play Store and on Android devices. For the most part, it is not visible to users, but it is in the URL for your app’s listing on the Play Store. That means a user may see it, but it also means it can affect SEO and your app listing’s discoverability. You’ll definitely want your app’s name included somewhere in the package name.


Discoverability of your app may be challenging at first. Searching your app by name in the Google Play Store may not yield your app anywhere in the search results right away. More installs, ratings, and reviews will of course help, but you should make sure your app’s description and all other text content in the app listing contains relevant keywords as well. There is a ton of content on the web detailing ASO/SEO (App Store Optimization / Search Engine Optimization), this post provides a good overview.


You can automate the process of uploading builds to the Google Play Store (as well as generating your apk, running tests, and a whole host of other things) with a tool called Fastlane. Specifically, the supply tool can be used to upload your apk to any track (alpha, beta, or release) along with store listing description and other text content, images, and even app screenshots.

Build Once, Use Anywhere

If you’re anything like me, you’ve spent an unhealthy amount of time perusing adorable cat GIFs on your phone, tablet, computer, tv and anything else that will let you get your fix of cuteness.

In addition to browsing cat GIFs on every device I own, I can also check my email, listen to my collection of music, chat with my friends and even write blog posts! On every device I own I can access the same emails, the same music, the same chats, and the same text documents.

In a world where seemingly everything is connected, it is almost unheard of for a web app to exist without an associated mobile app, and vice versa.

Build Once, Use Anywhere

To reach so many diverse platforms, it is crucial to initially develop with the “Build Once, Use Anywhere” mentality. What do I mean?

Let’s say you want to create a program that lets you browse adorable cat GIFs (if you do end up doing this, definitely let me know!). You decide you want to build a website and an iPhone app, but also want to be able to add iPad and Android apps in the future. To “build once, use anywhere” in this case means building one API that knows how to talk to all of the apps, current and future, that you create, rather than creating an API for each app.


An API allows one program to interact with another. In this case, you would create an API that communicates between your cat GIF storage and the mobile and web apps people are using to view and upload cat GIFs. So, let’s come up with a few API commands you’ll want:

  • Create - Allows user to upload a GIF (Technical term: POST)

  • Delete - Allows user to delete a GIF (Technical term: DELETE)

  • Update - Allows user to change the name of a GIF (Technical term: PATCH)

For reference on the technical terms listed above, check out this article.

Now that we’ve defined our API commands, we need to create a way for apps to interact with the API. Both the device running the apps and the device running the API must be connected to the Internet. In this case, the API is part of a program that runs on a computer called a “server” which is connected to the internet.


In computer science jargon, this project structure can be referred to as a “client-server model”, where one server (a program that runs your API) knows how to communicate with many clients (iPhone, Android, desktop, laptop, etc). If you want to learn more about the details of how a client-server model works, check out this article.

In reality, the server is just a computer in “the cloud,” which means it is just a computer connected to the open internet!



Now that your API connects your server with your apps, you need a database to store the cat GIFs that are uploaded. A database can either be hosted on a server of its own or the same server as the API. To keep it simple for this example, we’ll just say the database is hosted on the same server as the API.

The goal of the database is to keep it isolated so that only the web server framework running the API knows how to access the data. This keeps the data secure and abstracted in a way that only one device (the server) has to know how to access it instead of all the devices users have.


  1. If you’re looking to have a mobile app built, make sure the API is being developed with the “build once, use anywhere” mindset. This is one of the easiest money and time-saving decisions in modern programming.

  2. Whether you’re on a phone, tablet, computer or other device, if you’re using the same service (e.g. Google, Spotify, etc.) then you’re likely interacting with the same API to access that service on all devices!

  3. “Build Once, Use Anywhere” allows you to build the logic behind a service once and allow use of that logic from as many devices as you want (or can afford).

  4. If you build an awesome cat GIF app, make sure to let us know!