Location can help transform customer experiences from average to outstanding. Once a business decides to invest in building location infrastructure, they need to decide whether to build the required infrastructure in-house or purchase a pre-built solution. Given the complexities involved in client-side location infrastructure, this can be a challenging decision to make. This article will walk you through the various considerations so you can make the most informed decision possible.

Requirements gathering

The first step in deciding between building or buying location infrastructure is to articulate specific location-related programs or business objectives your company is looking to accomplish. After defining your objectives, you can begin outlining the corresponding functional requirements a location infrastructure will need to have. It can be helpful to identify both immediate requirements and longer-term considerations. The benefit of structuring requirements in this way is that it allows you to develop systems that can more easily expand to support future projects.

Example collection of business requirements:

Systems design and functionality considerations

The next step is to outline key components of location infrastructure and identify how they must meet the needs and requirements that your team has outlined.

Key components of location infrastructure include server development, integrations, and privacy and security. Each component brings functional requirements, which add additional layers of complexity and cost should you choose to develop location infrastructure in-house.

Infrastructure components with example functional requirements:

The need for a server

Since iOS and Android both offer client-side location and geofencing capabilities, developers often ask whether server-side infrastructure is needed in a location implementation.

It’s true that both iOS and Android offer geofencing capabilities in their location services. These geofencing capabilities allow you to register geofences with the operating system (OS), specify a location and radius, and then listen for entries, exits, and dwells upon which you can build experiences. Unfortunately, these services fall short of delivering on both immediate business outcomes and long-term flexibility in three main ways:

1. Client-side geofencing limitations

Client-side geofencing presents limitations on accuracy, observability, and flexibility. For instance, only geofences with a radius over 100 meters will trigger reliably which is often much larger than physical store footprints, especially in high-density areas such as malls. Since a limited number of geofences can be registered on the device (20 at a time on iOS, 100 at a time on Android), a refresh mechanism needs to be built either client-side or through repurposing another existing API, requiring extra development resources. Additionally, only one identifier can be attached to a geofence registered with the OS, which requires a new data model to be designed to store any further attributes. For example, if you want one grouping of geofences to trigger marketing notifications and another to detect store presence, you would need to develop and maintain a data model to support delineation of these two types of geofences.

2. Maintenance and QA challenges

All internal applications that are developed must be maintained to reflect evolving business needs and OS updates. For instance, location data collection requirements change with annual OS releases, requiring recurring maintenance. Server-side processing and detection minimizes client-side dependencies and allows you to iterate and adapt rapidly as mobile technology evolves.

Additionally, since location technology requires real-world movement, the effectiveness of traditional QA and functional testing is limited. Since QAing is often performed from a desk, in order to truly stress-test location-based features, teams have to dedicate additional resources to physical real-world testing. Radar’s SDK goes through robust testing across a wide variety of OS versions and devices to assess changes in behavior and verify functionality release-to-release. Radar’s dashboard also offers views into location updates and geofence entries on a map.

3. Lack of data democratization

Many companies collect location data and send it directly to a data warehouse for offline analysis or post-processing. While this may solve initial business requirements, this data isn’t always organized or processed in a way that can provide value to other business units as needs develop. Client-side-only implementation makes it difficult to send captured data to a data warehouse, making it difficult for teams to access actionable information. Since many businesses lack the resourcing and tooling required to effectively make the most of their location, they are unable to take full advantage of their data to make critical decisions or launch new functionality.

Data coverage issues

For companies with geocoding or address search requirements, there are a plethora of open datasets available (e.g., OpenStreetMaps). These data sources have some strengths, such as providing continually improving, user-generated coverage in areas where commercial interests are low. However, they are often not comprehensive enough to support enterprise requirements due to coverage gaps or missing attributes. As a result, businesses must supplement open datasets with commercial datasets.

To do so, businesses must develop a data pipeline to match points of interest and addresses across datasets. Beyond this, additions (openings) and removals (closing) of addresses or points of interest are common and frequent, which requires data pipelines to have robust and well monitored refresh mechanisms.

Costs

Now that we’ve established the components and functional requirements, it’s time to assess the cost associated with building out the needed systems internally. This includes:

Upfront costs

• Infrastructure build-out: The resource needs depend on the scope of work, but we see these projects can take anywhere from 3-6 months to build out with up to 5 full-time employees involved (mobile, data, server, devops, and security engineers).
• Initial data licensing costs: The cost depends on the types of data needed, but this can range anywhere from $5K to $50K.

Ongoing costs

• Infrastructure maintenance: This includes feature optimization, scaling requirements, and supporting changes to location collection (OS changes around permissions, location services) among other ongoing needs. This usually involves a mix of data, mobile, and server engineering.
• Infrastructure costs: The costs depend on the server-side infrastructure that is up and running, but will include server, database, and storage costs which starts at $2K+/month.
• Data licensing: The cost depends on the types of data needed, but this can range anywhere from $5K/month all the way to $20K/month if the data licensing agreements are on a recurring basis.

Opportunity cost

As highlighted above, there are monetary costs related to development and maintenance. Additionally, building location infrastructure internally leads to lost time to market and the opportunity costs of working on other projects that could also contribute to business value. This could be a 3-6 month time to value depending on the scope of work.

Radar advantage

At Radar, we pride ourselves on supporting our customers with robust location infrastructure that delivers rapid business value at an effective cost. We are typically able to support our customers with a rapid implementation (go live in 30 days) with low engineering headcount investments (often just half a mobile engineer FTE for 2 weeks).

If you’re looking to harness the power of location data and considering building a location implementation in-house, it’s critical to evaluate the financial cost, resource strain on staff, and the possible quality and flexibility of the end result. In order to provide significant value to businesses, location infrastructure must be built and routinely managed by development teams and often require expensive hardware to run smoothly without interruption. Instead, you might consider working with a platform like Radar to capitalize on the power of robust location infrastructure in a more rapid and cost-effective way.