Internal tools 101: How to build for scale in 2023

An effective internal tech stack is the secret weapon of any successful startup looking to grow fast. From onboarding to CRMs, operation systems, and more, efficient internal tools have the power to supercharge the scaling of your company. Many startups recognize the importance of establishing these internal systems early but struggle to break away from the ‘chaotic startup’ mold, in order to build and use them best.

And, spoiler alert: it’s easier than it ever was to start building!

But what are internal tools?

Internal tools can be any non-customer-facing app or automation used to conduct business activity.

So, with such a broad category, how do you decide what should and shouldn’t be an internal tool, calculate your potential ROI, and how do you go about planning and building it once you’ve made a decision?

Let’s dive in and answer exactly those questions.

Or, jump to the TL;DR.

‍

How do you decide which internal tools to custom-build?

Important to remember with development of any kind: just because you could, doesn’t mean you should. 

Slow custom code meant apps with a long shelf life

Had you asked this question 5-10 years ago, the nature of this answer would be quite different. Before, custom development was the only way - and came at a premium, both in terms of time and financial investment. The gap between ‘could’ and ‘should’ was much vaster. Before you spent months of developer time on a custom-coded app, I would have asked you to consider whether you’d use it for the next 5 years or more - since the developer time invested would likely have taken that long to justify itself.

Thankfully, internal software development has changed hugely over the past few years and continues to evolve quickly to help make internal tool development much faster and easier to implement.‍

Now, faster development means more apps & quicker deprecations

Now, there are plenty of no/low-code platforms and SaaS products like Zapier, Superblocks, Budibase, and more, that help make building automations and apps more accessible for non-technical employees, and developer-focused or language-specific tools like Retool, Django Admin, Ruby on Rails and more, which expedite the development speed of tools when created by a developer.

What might have previously taken many weeks or months of planning and expensive custom code, can often be spun up in a matter of days or even hours, helping to propel you into your next growth stages as a company. With more cost-effective development and shorter development cycles, you can build with the intention to deprecate quickly, treating a tool as a stepping stone to further scale your business without needing it to be long-term or integral. 

‍The decision of whether building an internal tool is a valuable investment has become a lot easier. Let’s run through some of the key factors you should be thinking about when considering the value or ROI of an internal tool build. 

‍‍

How do you know when to build a custom internal tool?

How to calculate internal tool ROI

When it comes to startups, there is no cookie-cutter equation for decision-making. First, you need to decide which apps are actually worth building, and then how and where to build or use them.

Nevertheless, if you aren’t sure where to start, here are some of the factors that should help you calculate your ROI for a custom build: 

‍

Employee time and satisfaction - good apps optimize their productivity, and make them happier!

• Is one or more of your employees or colleagues spending several hours a week, or even a day, performing a repetitive task? Would automating this process, or developing a tool to perform it more effectively, relieve them of significant time-wasting and frustrating work?
• The answer is almost certainly yes, but the ones to focus on are the problems that can be critical, expensive, or waste a vast amount of employees' time.
• Calculate the time your employees waste against the time it would take to automate and streamline it with time-saving tools (like Retool, Zapier, and the like) to see if it’s worth it. Take an example from our case study with company Bilt for how making an app for a Google API process meant better precision, saved huge amounts of money, and made employees happier by streamlining a time-wasting task. 

‍

More effective operations and satisfied customers

• As well as improving employee satisfaction by speeding up or automating repetitive tasks, equipping employees with access to data helps them to make more intelligent, data-based decisions that could lead to better sales and strategic decisions. 
• With the right data, and a dashboard that allows for direct action on this data, employees can work more effectively and provide better care for customers.
• When calculating your ROI, consider the potential value of better decision-making or improved customer satisfaction when their needs are met more effectively. In turn, these factors will go a long way to reducing business costs. 

‍

The cost of wasted developer time

• Are you working frequently with data that needs technical knowledge to access but would be useful for a non-technical team?
• A large percentage of engineers spend their time helping non-technical employees perform technical tasks (like running SQL queries). 
• Empowering your non-technical employees to work confidently with data by developing a quick database GUI can free up time for your development team to further your business and focus on your core product.

‍

The value of security & compliance: is your data safe?

• Does a team need read-only access, and you want to be absolutely sure they can’t change anything? Or are you working with a spreadsheet that you are worried might just break?
• Consider how much a potential error could cost if you keep the process manual or on an insecure platform (like a spreadsheet), and something goes really wrong. Or worse - if security is breached. 
• Custom-building is a great way to ensure that non-technical users can safely read and edit data with data validation features, security compliance protocols, and more. Using developer tools that have these elements built in makes such features much quicker to implement. 

What should you avoid when considering a custom internal tool build? 

While there are many internal tools that can perform wonders for your employee productivity and help majorly cut business costs, not all tools are created equal, and there are some things best avoided when it comes to planning which tools to build. Here are a few key ones:

Overbuilding: do you have a system that actually already works?

• We often see an over-excitement with internal tools that leads to a reinvention of the wheel - don’t overbuild something that already works. 
• Spreadsheets, word documents, or even a pen-and-paper to-do list may seem rudimentary, but there is a reason why they are still used. There are many simple, non-critical tasks with small datasets where such products perform their job perfectly, especially if your permissions system is simple. 
• Creating an overly-complex new system for something that already worked, and people were used to, often leads to a low uptake from employees and wasted time and money, and therefore poor ROI.

‍

Overly decentralized process and multiple sources of truth

• If you can’t integrate enough of your resources and actions, you may find yourself in a half-in, half-out situation where employees are jumping between tools and apps to get a process done - and thereby it’s even less efficient than it was in the first place. 
• With our clients, we find that creating tools for systems that require jumping out of the app to consult too many external elements can overcomplicate tasks and processes and these apps won’t prove as useful as you might at first think.
• In the same category, if by building your app you create multiple sources of truth for your data, you may find your app creates more problems than it solves.

‍

An app with too much human input or too many manual updates

• If a process requires superfluous steps of input it is less likely to be adopted as you need, and this manual work may cause additional friction. 
• Think unnecessarily complex CRM systems or customer service tools, inventory managers, and the like, which may ask for too much input from your users - the intention is to get more business data, but the result is often rejection by your employees and improper usage. 
• Instead, break processes into manageable chunks, or even consider not developing an app that might require more input and action than your employees already need to perform.

Thinking about these factors should help you consider your ROI for building your next internal tool idea - but even better would be to try and put concrete figures and calculations to these elements in order to better measure the process and outcome. 

‍

So, you’ve decided on your tool: here’s how to create it

‍Let’s start with the planning of your tool, something that is crucial to the efficient implementation of internal tools. 

How to plan your internal tool build

1. Capture user stories. While you may know you need an app to fulfill a specific problem, getting the user story is paramount to fully understanding the nuances of how your users work with the data. Use this feedback to create a logical plan, but don’t forget that not all ideas are good ideas!

2. Determine the state of dependencies. Will your database require any schema changes? Have your API calls already been created? Does new functionality need to exist on the backend to allow for this new frontend? Making sure these backend changes are done, or can be done before building your internal tool frontend is key to getting your build completed in the desired timeframe. 

‍

3. Determine your business intelligence. To maintain full control, the bulk of your custom code is best performed on the backend, and then a simple GUI frontend should allow you to interact with this data. Ensure these backend changes can be made in line with your frontend development, and that your backend engineers have the capacity to work on them. 

‍‍

4. Avoid the all-in-one complex. One single tool will not replace your entire business. Think of your tool like your physical HQ: you wouldn’t sit one HR exec next to an operations manager, and the other with the software engineers - you’d keep everyone logically segmented, so do the same with your actions and data. Don’t just add features because you can, make sure they are truly useful and in the right place. Enthusiasm can quickly surpass logic and this can often lead to overly complex, under-utilized internal tools. 

‍

5. Plan for feedback and testing from users and use this as a basis for further iterations. While you should always be thinking about your final end product, your first iteration should not include all functionality, as it’s very likely that the user experience doesn’t entirely line up with what you would expect. Rather than wasting time building an entire app and only getting user feedback at the very end (which may result in a hefty rebuild), create steps at which to gather this feedback before creating the next iteration. 

‍

6. Finally: create a detailed scope of work. Now you have worked through these steps to get a better understanding of your product, use them to create an in-depth scope for backend and frontend development. Decide who will perform these changes and what your timescale should look like. Whether you are working with your internal team or have outsourced to an external expert (like us!), providing all of the above information is essential for getting the best out of their work. 

How to build your internal tool

‍You’ve planned it - now what? Here’s what to look out for as you begin your internal app development. 

1. Pick a platform. How quickly does it need to be built? Do you have the resources to custom code? Do you custom code from scratch, or build on a platform? Take this time to talk to your developers, speak to some contractors and choose your weapon. At Bold Tech, our preferred platform is Retool - you can chat to us if you want to know more. 

‍

2. Single source of truth. I.e. avoid copying data and instead make sure it reads and writes from the same source. Don’t fork your data (pun intended). 

‍

3. Versioning and iterations: stick to your plan. Create a basic prototype before improving versions and adding features to make sure it is truly useful - e.g. adding notes to your system. People will just go to Slack instead. At this time, maintain a close relationship with your users, not just the product manager. Maintain testing rounds between iterations. Take the same approach to your internal tools as your company product - you don’t want to create something that no one needs. Think small scale and get feedback.

‍

4. Don’t forget UX/UI. If your users are technical, you don’t need to overly belittle the system. User experience is important internally, but remember, they are paid to use the systems - so you can often afford to leave beauty at the door. Especially if you are looking for a quick deprecation cycle, it’s better to prioritize faster development cycles.

‍

‍5. Don’t neglect permissions. Think about who should be viewing this data, and who is allowed to manipulate it. Make sure to test with all of these permissions in mind. ‍

‍

6. Build for scalability: package the functionality.  If you plan the functionality in such a way that you can edit and iterate on small sections without needing to rebuild your entire system, it will allow you to scale your app more effectively, based on user experience. As an example: this might look like keeping all data actions in a dropdown bar or actions container, where you can easily add another, or having all your detailed data in a side panel next to your table, rather than a mixture of modals, containers, and more. 

7. Test & feedback. Have it tested in staging before production. Make sure the users who test are knowledgeable and trustable if they are working with production data.
‍

So what's the TL;DR?

• Internal tools are now so much easier to build that the ROI equation has changed - you can build to deprecate, or even to plug small holes in your operations and processes to save you time and money
• Good internal tools go a long way to improve employee productivity and satisfaction, and can save you money too. They also free up developers who may spend time writing queries and more to help non-technical workers. Consider all these factors when calculating ROI. 
• Avoid overbuilding and decentralizing your systems when building internal tools - maintain a single source of truth and avoid building something that overcomplicates existing systems (your employees just won’t use it)
• Decide whether to build or buy wisely
• Plan and scope your apps carefully - follow our steps above to get the best out of your planning
• When building, stick to your scope, and don’t neglect things like permissions, data validation and more, which helps to protect your data. 

‍