Internal tools are a waste of time

I've spent almost my entire career designing internal tools.

Here's why that was a waste of time, and what made me join Basedash.

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.

Internal tools at SaaS

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.

Internal tools for Insurance

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.

Internal tools for field services

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...

All. Different. Internal. Tools.

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:

• Build (or rather advocate for us to build) another internal tool.
• Ask for CSV exports, update those, email them back to a DB admin.
• Find an internal tool that might work for it already and hack it to work for my use.

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.

Quick anecdote:

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.

They couldn't.

Not "wouldn't". Not "I'm not allowed to". Not "I don't understand". Not "that's against our policy".

Couldn't.

Didn't have the button.

Lacked the internal tool to make that happen.

It was an edge case.

{{ img:2ef7a4 }}

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.

Couldn't.

Internal tools can never keep up with customer needs. Every button has to be prioritized, story pointed, roadmapped, implemented, and then maintained.{{ img:f2b5f4 }}

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?

No.

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 you do.

Stop wasting your time building internal tools, and start using the one that builds itself.

www.Basedash.com

If you're a skeptic, tell me why this would never work.

I know a lot of the reasons, but I want to hear it from you so I can add them to our backlog and convince you.

You can read the unrolled version of this thread here: https://typefully.com/u/tomjohndesign/t/TTvDuVVsJAWt