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
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
Below are examples of internal tools used within companies
and a general list of popular internal tools we've seen users build
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
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
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
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
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
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
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
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
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
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!