I recently asked Claude to look at Hyve, our internal business system at Beezwax, from a sales perspective. It built me a dashboard. I spent half an hour with it, learned something useful, and moved on. That dashboard will probably never exist outside that one conversation, and that’s fine.
A year or so ago, getting that view would have meant several hours in Excel or asking someone to build a report. We’d have discussed what it needed to show, whether it was worth the effort, and when someone might have time to do it. Wanting to have a look at something for half an hour probably wouldn’t have been enough of a reason.
This took about ten minutes. Then I could get on with the bit I was actually interested in: working out what the information was telling me.
Sometimes you just need to answer a question
A lot of business software starts with a question. Where are we losing opportunities? What’s changed in this part of the business? Which customers need attention? Answering those questions has traditionally involved enough work that we try to make the result reusable. We build a report or dashboard, give it a permanent home, and expect people to return to it.
Often that’s exactly what we need. But some questions are temporary. We need to understand something, make a decision, and move on. My Hyve dashboard belonged in that second category. Its value was in what I learned during that half-hour. It never needed a home beyond the conversation that produced it.
Spreadsheets have served this purpose for years, but they could be cumbersome, took time to build, and often required a black belt in Excel. Being able to create a tool this quickly changes which questions are worth spending time on. I didn’t need a plan for using the dashboard every week to get something useful out of it.
The ten minutes depended on everything underneath
Creating the dashboard took ten minutes, which was only possible because the hard work underneath it had already been done. We designed and built Hyve on a solid foundation. It already contained the data and relationships that made the exercise useful, so I was asking Claude to create a temporary view of an existing business system.
It’s easy to look at something like this and conclude that building business software has become a ten-minute job. But establishing reliable data, connecting systems, and working out what the information actually means are still substantial pieces of work. Without that foundation, you can ask what you think is the same question twice and get two different answers. Worse, you can get a convincing answer to a question you didn’t mean to ask. A well-presented dashboard can make it very easy to trust information you shouldn’t. Clear definitions and reliable data help, but we still need to check that the answers mean what we think they mean.
When that foundation exists, though, you can ask questions of it in ways nobody thought to specify when the system was built. That’s an interesting development for anyone who has invested in a good business system. The information and logic behind it can support far more than the screens and reports you originally commissioned.
Try it before you know exactly what you need
Anyone who has commissioned software will recognize the difficulty of describing what they need before they’ve had a chance to use it. You can spend a lot of time discussing a report, then discover that the first version prompts a better question, or that you need to see the information differently. Or you realize that the thing you asked for wasn’t going to help much anyway.
That’s a normal part of figuring things out, but when each attempt requires someone else’s time, it can be a slow and expensive process. You might decide it isn’t worth asking for another version, or settle for something that gets you part of the way there.
Being able to create these interfaces quickly gives you more room to explore. You can try something, look at the result, and adjust what you’re asking. Some attempts will go nowhere, others will answer a question once, and a few might turn out to be useful every week. You don’t need to know which it will be before you start.
I think this could be particularly useful for the questions that never quite justify a development request. Most people running a business have plenty of those. You’d like to understand something a bit better, but getting the answer feels like too much work, so you carry on without it.
Then someone asks, “Can my team use it?”
Now and then you build something for yourself, show it to a colleague, and they want to use it too. You’ve found something that helps someone else, which is a good starting point for deciding what to do next. Making it available to a team brings a few more things to work through.
Before several people start depending on it, there are questions to answer. Who should be able to see which information? Have the calculations been checked? What happens when the source system changes, and who looks after it when it stops working? You should already be checking the answers you use yourself, but sharing a tool introduces responsibilities that weren’t there when you were exploring a question on your own.
There’s no reason to turn every useful tool into a company-wide application. Mine certainly didn’t need to be one. But if I found myself recreating it every Monday, or other people started asking for it, then we’d have a reason to talk about building something more permanent. We’d also know a lot more about what we wanted, having used it.
Software development is changing quickly, and we’re excited to be working this way. Clients can try things for themselves and come to us with something they’ve already found useful. It’s much easier to have a conversation with someone who can show you what they’ve been doing and say, “This helps, but I need it to do this as well,” than to ask them to describe the whole thing from scratch. We can build on what they’ve learned when it’s time to make it work for the rest of the business.
We’re also helping clients make better use of the systems they already have by connecting them to AI. For Hyve, we built a custom MCP (Model Context Protocol) connection that lets Claude access the business information it needs. Building these connections for clients is part of that work, along with deciding what information should be available, to whom, and with what context. There’s a lot of knowledge about how a business works built into its existing systems. Making that accessible lets people ask their own questions and create tools around what they need, just as I did with Hyve.
A year ago, I’d either have left the question unanswered or spent several hours putting something together in Excel. This time, I had a dashboard in ten minutes, spent half an hour exploring it, and got what I needed. If it had turned out to be something I wanted to use regularly, we could have taken it further. As it was, it did its job in that one conversation, and that was enough.
I’m excited to help our clients do more of this. When the systems underneath are built well, even software you use for half an hour can be worth building. And if it turns out to be something they want to share with the rest of the company, we’re there to help make that happen.
