First, let’s define what an internal tool is:
An internal tool is a piece of software that a company builds to maintain their own software. Think B2B, but for yourself.
What do these do?
They help solve customer requests, give support teams the tools they need to help, tell employees what they need to do, update employee information... really anything.
Early in my career, I worked for Intradiem, an automation software company. The first app I designed was for Sprint retail employees. It helped deliver training so they could be ready for corporate promotions, new materials, new phones, things like that.
It also need to tell managers when training was missing, incomplete, told regions how they were doing, and gave insight to corporate leadership on the status of the nation as a whole, so they could know when everyone was trained enough to launch, and if not, who to push to catch up.
It shipped. But never beyond v1ish.
It did what it needed to do, and then was almost immediately put on maintenance mode.
Could it have been better? 1000x yes. But as soon as it did the basic thing, it was good enough. I had such dreams of what it could have been...
While at Intradiem, I designed internal apps for automation, internal skilling of employees, for large scale contact centers to use to tell their employees what to do.
Again. Shipped, rarely updated.
At Asurion, the first app I was assigned to was an app for us to see and score applicants to our kinda uber-for-technical-chat app. It tested their ability to help customers via chat for certain technical questions, and then we would manually score them and add them to the platform if they passed the tests.
But each time a new technical topic needed to be added, like a new iPhone launching or something, we'd have to add a new skill, and then add a new skill to the "experts" who knew about that. Most everything was manual, and there was a constant flow of new things to change and improve with the product.
The Admin UI for assigning some skills had already been built, but it was years old, no longer maintained, and therefore no longer able to be changed, updated, or improved. We had to make due with what we had, and because that wasn’t enough, we had to build a whole new tool to augment the capabilities of the first.
It was easier to start from scratch then it was to track down and build on top of the older internal tool.
It worked, don't break it. You break it, you build it. So we built something else instead.
Then I was the lead designer on our same-day phone repair service. Think Amazon Prime Speed + Ubreakifix service. To support that project we had to send training, manage logistics, know inventory stock counts, manage lost/stolen/damamged inventory, skill new employees, make sure they got the right jobs, reporting on success, failure, customer scores...
And it wasn't because we wanted to.
It was because we had to build fast and we didn't have time to understand the APIs, legacy integrations, organizational structures, massive monolithic systems that needed to exist to support these efforts. I was the lead design on a small piece of the bigger pie that needed to be spun up to support this project. Hundreds of teams of engineers, designers, support personal, operations staff, supply chain managers...
Teams used Airtable, Retool, Googlesheets, Excel, Coda, IN ADDITION to the custom internal tools that had been built and never maintained by who knows and when knows. Sometimes we even found out that multiple different tools did some of the exact same things as each other. Sometimes we even did them differently.
Move fast. Break things.
But the truth? The things we broke were our customer support and operations teams. We wanted to make better tools for them, but our resources could not keep up with the evolving nature of our product features, employee needs, and customer demands. As a result, teams needing to keep things running often had to juggle dozen of different tools and workflows and spreadsheets to stay on top of what was happening.
We could build new internal tools fast, but they rarely replaced each other or eliminated issues. Revenue generating apps will always ALWAYS win against internal tools.
Right before I joined @basedash, I was working on a product that was meant to help you track warranties for tech in your home. We had a massive database of products, but I had no way to update the data when it was missing or inaccurate.
So I either had to:
Instead, I joined @basedash.
Because I knew that building internal tools can be fast, but maintaining them was slow.
Because seeing internal data changed the way I worked, but I was blocked from accessing it.
Because I didn't want to build another internal tool...
I wanted to help build @basedash into the internal tool, so that you don't have to build one yourself.
A month ago I ordered a Roomba and immediately changed my mind before it shipped. I asked their rep to cancel the order right away.
Not "wouldn't". Not "I'm not allowed to". Not "I don't understand". Not "that's against our policy".
Didn't have the button.
Lacked the internal tool to make that happen.
It was an edge case.
Couldn't find a way to avoid the shipping costs, the trip I'd have to make to the UPS store, the delay in refund, the poor taste I'd have from that customer experience.
Internal tools can never keep up with customer needs. Every button has to be prioritized, story pointed, roadmapped, implemented, and then maintained.
I joined Basedash because being able to edit a database directly changes that. You don't have to build a button if the data is directly accessible. We're working on making sure that you can see what changes are made, who made them, control what can be edited, by who, obscure private data, restrict access, remove syntax issues, make DB language human-readable...
We're making your database accessible for your team. Data access changes how fast products can be built, what assumptions are made, and if customers can be helped. It frees up teams to build products.
So was it a waste of time to build all of those tools? Did I waste my career designing new versions of apps that never got released?
Because I didn't have a better option. I had to build from scratch. I didn't have anything that could give me direct access to product data.
But with Basedash, you do.
Get to know what Basedash can do and how it changes traditional internal tools.
See a full app that connects to a Postgres database and external API made from scratch.
Ship your product faster.
Worry about internal tools less.
No credit card required.
September 26, 2022
Sooner or later in development work, there comes a time where you just need a flowchart. Recently we started using Mermaid, a markdown syntax supported by Notion and Github to document and share and annotate new features in-line rather than having to use a design tool or draw them out by hand.
September 21, 2022
Doing user research is difficult in and of itself, but no matter how good your are at asking the right questions, gathering data, taking insights from research, and putting that data to use, one of the most important parts of user research is finding the right users to talk to in the first place.
September 14, 2022
Product analytics tools are failing startups. At an early stage (pre-product-market fit), aggregate data is a distraction.The cure? Entity-level data.
August 29, 2022
Internal tool product management is identifying a need for, creating, and managing internal tools that will fulfill the needs of multiple people at your company. It's one of the most intimidating product roles in tech startups, but it doesn’t need to be.
August 16, 2022
It's challenging to keep track of dozens, if not hundreds, of different business processes at any given moment, let alone provide a timely report on them. It’s always tricky because of how many processes across other systems are involved.Internal tools solve this business problem by integrating all the data sources they use under one user interface. In doing so, these tools streamline and speed up work for your employees and your business. This article will go into several benefits of building internal tools, what you need to consider, and how to build them.