If you build it…

There are a lot of ideas inside companies that hang around forever. "We should be able to measure this". "We should have a better way to collect that information". "We should connect the data in Slack with the data in our dashboards". "We should automate this process that someone is spending hours on every week". Most of these are good ideas, and often everyone agrees they would make things better. Yet they can sit there for months or years because every one of them feels like its own project and no one has time to invest. Every time the conversation comes up, you are staring at a blank page again.

I’ve been thinking about this a lot because of an internal app I built at Mytra called Pivot. Pivot started with a very specific problem: headcount planning. We had reached the point where too much of the process involved spreadsheets, people manually updating data, other people consolidating those updates, and then more work to turn all of that into something we could actually use to make decisions. We tried to make the spreadsheets smarter and automate more of the work between them, but there was a point where that stopped being a useful direction. The underlying problem was that we didn’t really have a home for the process. So we built one.

The first version of Pivot didn’t need to solve every problem we could imagine. It needed to make headcount planning better. It captured the information we needed, consolidated it, and gave us a useful way to present it. That alone was valuable, but something much more interesting started happening once we began using it. We would be in a meeting looking at the data and someone would want to slice it differently. Or a conversation would happen in Slack and we would realize that a particular view would make the answer obvious. Instead of adding another spreadsheet, creating another manual report, or putting the idea onto a backlog of things we might eventually get to, we could change Pivot. Sometimes very quickly. The distance between “I wish we could see this” and actually seeing it became dramatically shorter. Then the compounding started.

To do headcount planning properly, Pivot needed a record of our employees. Once that existed, we suddenly had a useful piece of infrastructure that had very little to do with headcount planning specifically. Think about how many internal company processes begin with some variation of “for each employee” or “for each manager.” Before Pivot, automating one of those processes meant first figuring out where the employee data lived, how to access it, how to reconcile it with other sources, how to present the result, and where the workflow itself should live. Now a lot of that work had already been done. The next idea had somewhere to attach.

That changed the economics of small internal improvements. Processes that would never have justified building their own application suddenly became reasonable features to add to an application that already existed. Things humans were doing manually could become automations. Manager overhead could be reduced. We could add a chat interface so that some interactions with the underlying information became a conversation instead of another form or spreadsheet. Each capability created building blocks for the next one, and each new building block lowered the cost of exploring the ideas that followed.

I think this is particularly interesting right now because the cost and time required to build software has changed so dramatically. Historically, it would have been difficult to justify building a bespoke application for a problem that was unique to one company, or even one team inside that company. There was a natural pressure to find an existing SaaS product that solved 70 percent of the problem and then bend your processes around it, or accept the spreadsheet and manual work because custom software was too expensive. With the current generation of development tools and AI, that calculation is changing. Software can be much more specific. You can build something whose total addressable market is literally your own company (or a few folks within your company!) and still get an enormous return from it.

There is also a product development lesson here that we usually apply to things we sell and less often to the software we build for ourselves. Get something real in front of people. Watch how they use it. Notice where they struggle. Listen for the conversations that start with “I wish this could…” and then make the product better. The fact that Pivot was already part of how we worked meant those signals showed up naturally in meetings, Slack conversations, and day-to-day use. We weren’t trying to predict every requirement up front (how often are any of us successful at that anyway?). The requirements emerged from using the app.

The value of building the first application isn’t limited to the problem that justified building it. You are also creating a home for future ideas. You have a codebase. You have data. You have authentication and users. You have an interface people already know how to reach. You have somewhere to put the next automation, the next visualization, the next workflow, and the next experiment. More importantly, you have people interacting with it and discovering what they want next. Once that exists, ideas that used to end with “we should do that someday” can turn into “let’s try it.”

The first feature might justify building the home. The compounding value comes from everything that finally has somewhere to live.