My name is Joe Johnston and I am obsessed with internal tools. Over the last 10 years, I've created over 80 internal tools - one particular tool had over 80,000 users and saved the organization over $3,000,000 per annum. If this is your first time learning about internal tools, you've came to the right place. This is NOT your average "Internal tools in 2021" post. This is a continually evolving environment to learn about the finer details of building internal tools, and how they can help you accelerate digital transformation.
Internal tools are internally-facing software developed and utilised within an organization. They range from database GUIs to employee wikis, and are highly-tailored to an organizations processes.
Internal tools have been around since the early days of software development. They're the unsung hero that powers the majority of businesses which exist today. And they're growing in popularity.
Software is eating the world, and digital transformation is at the top of every CIO/CTOs agenda. $120 billion was spent last year on Internal tools/custom software, and this figure will continue to increase as we gather more data, become more distributed, and industries become more competitive.
Below are examples of internal tools used within companies and a general list of popular internal tools we've seen users build within Budibase.
Google are infamous for their internal tools. I have spoken with a few product managers at Google and I'm under good authority they have over 500 internal tools in the wild. Some of those tools have hit the headlines, including the two below:
Google's internal browser - Google developed an internal browser tool that monitors meeting requests made by employees. This has upset a number of employees, whom have spoken out about the new internal tool. A Google representative denied the tool was for 'spying', saying the company developed the extension in response to an uptick in spam involving calendar entries. Basically, the tool alerts employees when they attempt to auto-add a meeting to the calendars of large numbers of people. The extension does not prevent users from creating such meetings and doesn't collect personal information.
Google's Borgmon (now Monarch) - As you can imagine, Google has a collosal task on its hands monitoring its computer systems. The teams behind tools such as YouTube, Gmail, etc, need to monitor a continually growing and changing collection of heterogeneous entities including visual machines, devices, containers. The total of entities stretches into the billions and, to make matters more difficult, are distributed around the globe. So, Google built Borgmon. Any Google engineer, between 2004 and 2014, will have fond memories of Borgmon - it was a beast and involved a steep learning curve - but it worked, to a degree. Google have since replaced Borgmon with Monarch, which can manage trillions of time series and is essential to the smooth running of the Google engineering empire.
You cannot hit IPO without experimentation. Airbnb understood this from the very beginning. They state:
"At Airbnb we are always trying to learn more about our users and improve their experience on the site. Much of that learning and improvement comes through the deployment of controlled experiments."
To run and manage their many experiences, Airbnb created an internal tool. The tool did all the heavy analytical lifting automatically, whilst limiting bias when setting up an expierment. When designing the tool in 2014, simplicity was the primary goal, and it shows:
On a call with David Singleton, CTO at Stripe, we asked him if they prefered to "build vs buy". His answer was
"Build, depending on the scale of the task at hand. For example, we use Github, because the engineering effort to build a tool like Github is not worth our time and engineering effort."
This is a quintessential answer. Below is a design of one of Stripe's many internal tools, called Home. Home is Stripe's employee resources portal. It provides directories for employees and teams, as well as company-wide resources like calendars, events and announcements.
Credit to Stripe, their design always seems to strikes the perfect balance between beauty, and communicating 'we're an incredible technical company'. It's great to see a company apply the same effort to design in their internal tools, as they do their external tools.
A CRM (customer relationship manager) helps sales/marketing teams manage their prospects/clients. There are many off-the-shelf CRMs including Salesforce, Pipedrive, etc, but many organizations build their own CRMs due to the unique nature of their sales process. I worked in the defence industry and we used Microsoft Dyanamics. It was a great platform, but due to the uniqueness of our sales process, the sales team hated it. It was not fit for purpose. We spent north of $40,000 customizing the tool to fit our needs, but still, it did not suffice. So we built our own and the team loved it.
Data is eating the world. As more organizations and processes move online, the more data we obtain. Collecting data is generally the easy part, it's the interpretation of this data which is hard. In many cases, data is distributed across multiple data sources, making it a little tricky to compile and analyse. Many companies build internal tools / dashboards to help display this data in a way which is easily interpreted. This is one of the primary reasons why Budibase supports many different data sources including Mongo DB, Couch DB, PostgreSQL, Elasticsearch, CSV, Dyanmo DB, and more.
Many SaaS / eccomerce platforms require an admin panel to manage backend operations. They allow you to approve user access, manipulate data, and track transactions. Admin panels often have a dashboard element built-in to save time exporting data to another platform. Like all items on this list, the decision to build an admin panel is usually down to a custom requirement which is not available of-the-shelf.
Generally speaking, the larger the organizaton the more layers of management it has. A popular process within organizations, especially enterprise, is the approval process. This category can involve many, highly specific approval processes, from booking holidays to signing-off on a sale. When building this type of internal tool, understanding the different types of users and their hierarchy, is crucial.
Inventory can take many forms; from rockets to Tamagotchis. Managing this inventory involves a robust database, a interactive UI, and automations to accelerate the processes involved with managing shipments, orders, and deliveries. Often, a control dashboard where a manager can gain a snapshot of operations, is also required.
There are many departments within a business which require software to do their job more effectively - Sales have the CRM, HR have the HR platform, and IT Support have the ticketing system (among others). The core function of an IT ticketing system is to manage incoming support requests from general employees. As you can imagine, the life of an IT support technician can get stressful. Hardware/software have changed our lives, but they are complicated beasts and come with many problems. Combine that, with stressful/over-worked employees, and you get tickets of fury coming at you from all angles, 24 hours a day. This is exactly why a good ticketing system is essential. It helps IT Support plan, triage, dissemenate, and inform - allowing them to do their job with an impressive level of calmness and efficiency.
Some organizations will form an internal products team. 100% of this team's time is dedicated to building and supporting internal tools. Most of the time, the process of building an internal tool, is left to a single person, or team of people.
Internal tools are generally built by developers, and if we're honest, they're not the pieces of work developers like to work on. But this is changing. Due to recent advancements in tooling. These advancements have reduced the learning curve, abstracted a lot of the more difficult technical parts, and made it super quick to build internal tools. This has led to a new wave of internal tool developers. Below we will explore the types of users building internal tools with Budibase.
The illustrious internal tools developer is often the unsugn hero in many cases. They are building mission critical software, but often don't get the recognition they deserve. Over 40% of Budibase's users are developers of some type. Their general reasons for using a low code platform, include speed, ease of design, and simplicity.
Product managers are an emerging role which use to be reserved for larger organisations. We are beginning to see more product managers working within SMEs which is testiment to the importance of this role. The beauty of a product manager is they are 100% committed to a product; providing direction, ownership, and insights at all times. In a lot of cases, they're both technical and business focused - which is an incredibly powerful mix. Through conversations with PMs, one overarching theme has stood out for us - Product Managers fully understand the business value of these tools. Just under 20% of Budibase's signups are product managers, and growing!
Over 15% of Budibase users are IT managers. They generally belong to manufacturing / construction / logistics industries and work within a small team. Due to the nature of their business, we've found they are often building multiple internal tools, from inventory to CRMs, as their role primarily revolves around supporting the organizations internal technology and business operations. Around 15% of Budibase signups are IT managers or 'IT professionals'.
Below are two professional roles we were not aware of and we've noticed growing in popularity.
Due to the increasing importance and collection of data, we've noticed Data PMs signing up to Budibase. On inspection, their responsibilities lie within creating interfaces to make sense of the large amounts of data collected within their platforms. They then analyse this data to inform business direction. It's very much a data analyst / product manager hybrid - which seems like a role which could benefit almost every organization on earth.
Basically, a product manager whose sole focus is on internal operations. We're noticed this role within larger organisations, and the low-code platform/internal tool builder seems to be their weapon on choice. We are watching this role very carefully, as it seems like it could grow in popularity as internal operations increase (due to digital transformation and the increasingly distributed workforce).
Building internal tools is different from building customer-facing tools. When building internal tools, you have greater access to the end-user. Quite often, when using an internal tool builder, the build process is a collaboration between builder and user. This is a beautiful, powerful experience and often results in an outstanding internal tool.
There are primarily two ways to build an internal tool; completely with code, or with an internal tool builder.
Both options have their pros and cons; code is more flexible; internal tool builders are faster, easier, and more cost effective.
Going forward, we will illustrate how to build an internal tool with an internal tool builder.
If you are leading the quest for a new internal tool, quite often you will need a business case or approval from the powers-of-be. For this post, we will assume you have approval.
The internal development methodology is the method of building internal tools to automate processes, equip your workforce, and grow your organization. It’s about building tools to empower your employees to do more, and do it faster.
Why? Because when your employees succeed, you succeed.
The Internal Development Methodology can be applied in four ways:
To build an internal tool users love, you need the builder and the AU (admin user) to collaborate. Depending on the size of the organization, the team involved with building the internal tool may involve a product manager (if you can involve a product manager, do!). Collaboration provides motivation and enourages creativity; whilst reducing errors and upsets. During this phase, planning is completed, the project is scoped, and the architecture decided. In cases where the admin user is also the builder, it is still important to plan, scope, and architect.
Within Budibase, there are three phases to the build process; data, design, and automation. During the data phase, you structure your data, and add it to the builder. During the design phase, you build your application with pre-made components and screens. You can then pull in data to your components, and query them with incredible ease. And during the automation phase, you will automate certain processes such as email, notifications, and more. We feel the data, design, and automation pathway is the easiest to learn and the most natural for devs. Other internal tool builders may differ.
Testing should be completed across the relevant browsers and devices. It is a good idea, to test with a user who has not been exposed to the tool during development. It is up to the admin user to sign the internal tool off.
Once the tool is signed off, you are ready to deploy it to production. The admin user will record any bugs experienced and collaborate with the builder to fix them - in some cases, due to their familiarity, they should be able to fix some issues.
We've experimented with this methodology for over a year now and everytime it has resulted in superior internal tools, happier users, and advocates! And it's these advocates who promote this methodology, which results in more internal tools, happier employees, and faster, more productive businesses. This is how your organization builds momentum, and this is why the internal development methodology serves as a strong foundation for your flywheel.
As we previously mentioned, the internal development methodolgy can have a positive effect on your employees, equiping them to do more, faster. What's great about the methodolgy, is it also converts your employees into advocates, which spreads motivation.
Below outlines how IDM transforms a user into an advocate.
Collaborate (user) - The AU (employee) is fully involved from the very beginning. They lead the planning, participate in scoping, and assist with architecture. In a sense, they are the product manager. They are the ones who fully understand the problem afterall.
Build (co-creator) - The AU co-creates the internal tool, providing UI/UX feedback along the way. Co-creation is incredibly powerful, and made possible with internal tool builders such as Budibase.
Test (owner) - The AU is also the tester. They understand the tool, they understand how it should perform, and what the common user will expect from it. They have the final say on whether or not the product is the ready for deployment - at this stage, they are the owner.
Deploy (advocate) - The AU, due to their heavy involvement, is the internal tool's advocate and first line of support for their team. They are the owner, they are the creator, they will promote the product to their team and gather feedback which then kickstarts the flywheel again. In some cases, they can make changes without the need of the internal tool developer.
Once the user becomes an advocate they sell the internal tool to their colleagues. Their colleagues, the new users, experience the platform and immediately begin considering how they can create internal tools to improve their jobs and provide the company with more value. The wheel keeps spinning, and a faster, happier workforce grows.
Better collaboration results in better internal apps. It also results in happier users, advocates, less bugs, less support, and less maintainence. Trust me, it's worth it!
When deploying your apps, it's important to understand where in the world your users will reside as this will impact perf. If you are in a highly secured environment, it's generally better to self-host your apps in the comfort of your own infrastructure.
Do you remember in the summer of 2020, when President Barack Obama, Joe Biden, and Elon Musks Twitter accounts were hacked? Well, the hackers managed to comprimise one of their internal tools and get access to their accounts. Please take security serious. Below is a picture of the internal tool:
It's important to scope the internal tool to understand any areas that might require additional development outside of the internal tool builder. If there is development, please make sure your tool of choice is extensible and allows you to build on top of it - being able to see the codebase is a huge advantage here. This will also reduce technical debt.
At Budibase, we like to include an NPS feedback popover in our apps. It asks the user to rate, from 1 to 10, how likely they are to rate this internal tool to a colleage. Underneath the scale, we include a comment box. This helps us understand the general feeling towards our app. Understanding feedback helps us build better tools.
When building an internal tool, it is advised to think of your users like you would an external application. Uber have many internal tools, and Kamal Boparai, Engineering Manager, IT Eng Compliance and Legal (Engineering) Team puts it nicely in the statement below:
"The IT Eng team is very focused on our end users (Uber employees) and their experiences. We always put our end users first; from there, we can help external end users (Uber’s partners and customers) virtually. Even more importantly, we keep the Uber network functioning properly and create the infrastructure that supports Uber employees. Basically, IT Eng is responsible for everything that happens in the background to keep Uber running smoothly."Kamal Boparai,Engineering Manager | Source
Microsoft's CEO, Satya Nadella once said, "Every company is now a software company". Software is without doubt changing every aspect of the workplace. What's more accurate and less heralded, is how we've only scratched the service when it comes to the productivity gains expected from software.
2020 was a disatrous year for people around the world, and for many businesses too. The events in 2020 and 2021 will inevitably lead to organizations looking inwards to find answers. Building internal tools with internal tool builders can play a huge role in helping an organization cut costs whilst improving output.
Internal tools have increased productivity across the board for the majority of industries, but the scale in which they're rolled out can make a huge difference. A study from 2003 showed that while Wal-Mart and Kmart both invested in IT, Wal-Mart did a better job of changing the rest of their business to work with the technology, and consequently saw “higher levels of productivity and market value”.
Of-the-shelf software, especially enterprise software, costs a crippling amount. When building internal tools with an internal tool builder, you can save 10x the cost of off-the-shelf software - sometimes a lot more! You can save even more if you self-host your tools on your own infrastructure.
If you are self-hosting on your own infrastructure, and implementing your own Auth system, in a lot of cases the security will be better.
When building your own tools, you have the power to build them exactly how you want them. As previously mentioned, you are building a solution around your specific problem. One of the common reasons users come to Budibase to build custom software is because a part of their business is so unique that no off-the-shelf software can solve their problem how they'd like them to.
Providing your employees with the right tools to do their jobs is incredible fulfilling for employees. As I am sure you are aware, a common scenario in organizations is a disgruntled employee battling with an unfit tool, or using a particular tool to solve a problem the tool was not designed for. (We'll chat about Microsoft Office soon).
Previously it would take an internal software developer/development team, on average, 4 weeks to 6 months to build an internal tool. With modern internal tool builders, such as Budibase, internal software developers can build and ship these same tools in days.
Microsoft Office is the workplace swiss army knife. We're grew up using it, loving it, and inevitably hating it. But, please don't see this as slander. It's an incredible platform, with incredible tools which solve common problems. In fact, a highly product Excel user is basically an engineer with a different title; building internal software (albeit in a highly restructive environment). The problem is how we overuse these tools to solve problems which they are not suitable for. Here's an example of how nearly 16,000 people who tested positive for the coronavirus disappeared from records due to an Excel error.
Code is awesome. Boilerplate code and repetition not so much. We created Budibase to augment the development experience not replace it. You can still write code, query data, self-host; but you can also develop faster, design better, and output a real single page application.
The emergence of internal tool builders has reduced the barriers and resolved many of the concerns around building internal tools. If organizations were more willing to build their own internal tools, specific to their needs, they would experience huge productivity gains, an increase in employee satisfaction, and potential market growth. With digital transformation now a priority for most businesses, there has never been a better time to build internal tools and accelerate your organization forward. I hope you enjoyed this post, and thank you for reading.
Supporting the internal development methodology is an all-in-one platform for building, automating, and shipping internal tools. By combing the internal development methodology with Budibase, you'll accelerate digital transformation, speed up development, and equip employees with the tools to grow.
It only takes a few minutes to get up and running!
12,900 stars on Github → 12,900 stars on Github →