Should we build the software our business actually needs?

It changed the calculation for me. I was paying for overlapping applications and adapting my work to the way each one operated. As I learned to build with AI, I began creating tools around the work I actually needed to do. Across our business, I eliminated $24,000 a year in SaaS subscriptions. We still have the costs and responsibilities of running our own software, but we also have much more control over how it works.

The bigger change is how easily we can improve it. A small, contained change to one of our tools can take me 10 to 30 minutes to describe, test, and put into use. My design and development experience matters here. The opportunity for another business is to develop that ability deliberately, starting with a useful problem and the right expertise.

I look at four things: what we pay and what we get, where the tool causes friction, how sensitive the data is, and what rights the vendor has to use it. A tool that costs little and works well may be worth keeping. Several subscriptions supporting one awkward process deserve a closer look. The most useful question is often: what would this workflow look like if we designed it around our business today?

Petrograph grew out of that question. I needed illustration, diagramming, and layout capabilities spread across several applications. I built the features I used, then kept improving the tool while doing real work. By the 89th iteration, it had become something I reached for every day. Working inside the product taught me what the first version was missing.

Start by mapping your most valuable data: where it lives, who can access it, and what each provider’s terms permit. Look specifically at AI training, retention, deletion, and your ability to move the data elsewhere. Terms vary by provider and plan, so this needs a real review. Owning an application doesn’t automatically make its data private, especially if that application sends information to an external AI service.

Building can give you more choice over those arrangements. It also makes the architecture important: which information stays under your control, which services process it, and what they need to receive. I would make those decisions before moving sensitive business processes into a new tool.

I start by using it myself when I’m part of the intended audience. If I keep returning to the old tool, I want to understand why. Petrograph, SignalDMX, and several Meridium tools have earned a place in my daily work. That’s an early test, followed by getting the product into the hands of other people who match its audience and watching what happens. You can explore what we’re building at Whispering.

I look for what I call flow state: people move through the task naturally and leave thinking about what they accomplished. Familiar interactions, clear feedback, and a way forward when something goes wrong all matter. Automated tests help check the software; real use reveals whether we’ve built the right thing. A working first version gives us something to learn from.

Someone needs to own security, maintenance, backups, support, and changes to the services the application depends on. Those responsibilities belong in the cost comparison from the beginning. For software using AI, NIST’s AI Risk Management Framework offers a useful reference for considering risk through design, use, and evaluation.

My approach would be to prove one worthwhile improvement, learn what it takes to operate it, and use that evidence to decide what comes next. Building our own tools has made my team more focused and able to change how we work. The lasting value is that ability to keep improving the business as we learn.