As a tech driven company, building out ad hoc internal or ‘bespoke’ tools as the need for them arises is fairly common, if not to be expected. At Deputy, we use a number of these solutions to successfully manage operations in many areas of our business. For example, we have an internal, interactive map that shows us where our customers are worldwide.
Deputy’s internal Custom App that shows our customers in Sydney
The Deputy product itself was built on such a premise. We built an internal workforce management solution to better manage the team at our past aviation company given there was no existing solution on the market that did what we needed it to do.
As such, it would be remiss to disregard the many good reasons that compel businesses to build out home-grown internal solutions, such as:
1. It’s a perfect fit. You are building out a solution that exactly matches the unique requirements of your business, (no more RFI’s!).
2. It integrates. You can build it to cater for any existing systems in place.
3. It’s secure. As an internal system, it will be easier to wrap your existing authentication layer over the top of it.
4. You own your data. With full visibility and control over data, there’s no chance of losing access to the data.
5. It may give you a competitive advantage. Given it’s not an ‘off the shelf’ solution, there’s no way your competitors can get their hands on it. If it is working well and delivering amazing value with improved efficiency, it may become your USP.
6. It’s a new product offering. Some of the best products on the market today began as internal tools built to meet internal demands. For example, Amazon Web Services built their cloud offering to alleviate internal pain points as they grew. Asana came out of Facebook. Expedia from Microsoft. And of course, Deputy as the personalised scheduling solution from my co-founder Steve Shelley’s aviation business.
However, when it comes to building out internal solutions, the expression – just because you can, doesn’t mean you should – definitely holds water. After all, there is a reason why open APIs have become so popular. These are just a few critical factors that need to be seriously considered before you start developing your internal tool:
Scalability: If your company grows, how quickly can this solution scale? For example, it’s great to build a scheduling solution that’s customised to your local legislation, but what if you were to expand internationally? How quickly would you be able to adapt your solution if the law changed? Recently at Deputy, we watched as a prospect decided to build out their own scheduling solution, only to be blindsided by the Fair Work week changes as they tried to implement it in New York.
Maintenance: Maintaining bespoke solutions come at a cost that needs to be factored in when building it out. With infrastructure, security patching, software updates, technology framework changes, system dependencies (just to name a few), the ongoing cost of keeping the solution running effectively is often significant.
Privacy: If your system contains anything that is PII (Personal Identifiable Information), then your system is subject to privacy laws. Simply having the name and email address of an individual is considered PII data. If you have any piece of data from an EU citizen, then you are subject to GDPR – of which failure to comply results in fines of $20M or 4% of your annual revenue.
Resource Allocation: Is the talent and energy required to execute all of the above being deployed to better the core product for your customers? Is it ultimately going to be increasing sales, improving NPS, and returning more to your shareholders?
Competitive Disadvantage: While your technical team are bogged down maintaining this in house solution, your competitors will be innovating in the customer space.
Ego: Having an arrogant streak is a defining trait of most if not all entrepreneurs and disruptors – and it is often the reason for their success. However, if your motivation for building something internally is “just because we can”, with the above considered, this will likely only end in failure – or to paraphrase – pride comes before the fall. If ego is removed from the equation, is the decision to build internally truly in the best interests of your company?
When it comes to build or buy, it’s definitely not as cut and dried as it seems. Throughout my own career, I have been involved in many difficult decisions like this – and I have made many mistakes. Back in 2011, we built an internal billing system for Deputy. After two weeks of hard work building it, the system worked like a charm. Our API was beautifully integrated with Xero, and my team couldn’t have been prouder. But then… it broke.
We were quickly running into limits of invoice customisation. Any changes we wanted to make to pricing required significant code change, and don’t even get me started on the issues with different currencies and payment options! After some deliberation, we swallow our pride and rolled out Zuora. Our business has grown exponentially since this decision, and without biting the bullet back then I can honestly say this would have been the biggest limitation to our growth.
With experience, we have developed a clear decision making matrix to refer to when deciding whether to build, or buy:
Will the solution be directly used by the customer, impact our customer experience or brand perception?
1. If yes, build it in-house as part of the core offering, even if it means putting a wrapper around a supplier product.
2. If no, BUY IT.
Even in the example I gave with Zuora, we built the billing presentation layer but it is still 100% APIed into Zuora.
In the instance that there is not a solution currently on the market that perfectly matches your requirements (a common argument for building in house), my recommendation is to find the closest solution that matches your business needs, and utilise one of the many solutions that can assist with integrations (like zapier, workato or mulesoft – just to name a few).
The Deputy Principle:
Throughout my time as CEO and CTO at Deputy, I have followed a simple principle on product building: businesses shouldn’t have to change to suit the software, the software should adapt to suit the business****. In following this principle as Deputy has evolved, we have introduced numerous customizable options into our product that have been to the benefit of our business, and the businesses we work with, including:
1. API: Data can be taken both in and out with our API. As the apps themselves communicate using the same API we publish for our customers, everything that apps can do can be done via API.
2. Webhooks: This enables custom workflows to be triggered based on something that has happened in Deputy.
3. Scripts: With Deputy’s dexml scripts, almost anything is possible. Deputy executes your business logic server side within Deputy, in a sandbox environment similar to AWS lambda. This makes it completely secure and fully customisable, while also enabling record validation, triggers, alerts periodic jobs and much more.
4.Custom Apps: You can easily build single page html5 apps over the top of Deputy, just like in the internal map shown above! These are also fully accessible in Deputy’s mobile apps.
The high level of customizability in Deputy is what makes us truly vertical and size agnostic (we are infinitely scalable!). From small cafes to global airlines, our product exists to support every business. At Deputy, we wake up every day with the mission to make employee management the best it could possibly be, eliminating pain points for over 70 000 businesses all around the world, and always striving to make each day better than it was the day before.
Are you still sure you want to build an internal workforce management solution?
