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 are recognizing 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!
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.
Important to remember with development of any kind: just because you could, doesn’t mean you should.
Nevertheless, had you asked this question 5-10 years ago, the nature of this answer would be quite different. Back then custom development was the only way - and was 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, there are plenty of no/low-code platforms and SaaS products like Zapier, Superblocks, Make, 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, and now that you’re hopefully well aware of that fact, 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.
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!
More effective operations and satisfied customers
The cost of wasted developer time
The value of security & compliance: is your data safe?
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?
Overly decentralized process and multiple sources of truth
An app with too much human input or too many manual updates.
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.
Let’s start with the planning of your tool, something that is crucial to the efficient implementation of internal tools.
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 understand 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.
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.
Joey has been an absolute pleasure to work with! He’s provided a lasting impact on our organization by building out our Retool portal in a way that allows us to optimize how we track, communicate and launch our clients. His attention to detail and rapid ability to implement all of our product requests was unmatched. I highly recommend the Bold Tech team for all things related to Retool!!
Bold Tech did an excellent job helping us build, maintain, and improve our systems for our customers. They were professional, thorough, and dedicated at all times. I recommend David, Joey, and the team to anyone looking for a partner in helping build their next phase of custom tooling.
We build internal tools, fast.
