From hackathon idea to everyday tool: what Toolbox taught me about building for real needs

At Mercedes-Benz.io, I work as an Application Architect, also known as a Solutions Architect, in the DSDBook area. DSDBook is the booking engine behind online workshop appointments at Mercedes-Benz, helping customers schedule a visit with their preferred dealer as part of their digital ownership journey. Within this context, Toolbox is the product I’ve been developing around a very practical challenge: making the information our teams need easier to find and use. The combination of architecture and hands-on product development has shaped the way I approach Toolbox, not as a collection of features, but as something that should remove unnecessary friction and help people get to the problem they actually want to solve.

Daniel Costa

Application Architect|MB.ioneer since December 2019

Fun fact:He has more than 1000 hours in Euro Truck Simulator.

But there is one thing that has always frustrated me at work: knowing exactly what I want to test, but having to spend more time than I should finding the information that allows me to actually test it.

In our case, that information can be very specific. You might need a particular type of vehicle, a vehicle in a certain market, an account with the right conditions or an offer you can use for a test. When that information is scattered across different places, what should be a relatively simple task can turn into a search before the actual work even begins. That was the problem behind Toolbox, and it is still the principle that guides how I think about it today.

The story started with a relatively simple idea, but over time it became something much more interesting to me: an example of what can happen when you keep working on a problem after the hackathon is over, put something into the hands of real users and allow their needs to shape what comes next.

Build around a problem, not around features

Whenever I show Toolbox to somebody new, I usually don’t begin by explaining everything it can do. Instead, I try to understand what that person actually needs. Do you need a vehicle that matches certain conditions? Are you trying to investigate a particular VIN? Do you need an offer from a specific context or market?

Once I understand the problem, I can take that person to the part of Toolbox that is relevant to them. It is a simple approach, but it reflects something that has become increasingly important to me while building the tool: a useful internal product shouldn’t begin with its features; it should begin with the friction it removes.

That sounds obvious, but it is quite easy to forget when you are building something yourself. You know every feature, every integration and every improvement, so naturally you want to explain all of them. The person sitting on the other side usually has a much simpler question: Can this help me do what I need to do?

Toolbox exists to make the answer to that question easier.

Why I kept going after the hackathon

The first ideas behind Toolbox appeared in 2025, and an early version was later developed for an internal hackathon. At that stage, the scope was much smaller and focused mainly on VINs and vehicles. We built it quickly, presented it and didn’t make it to the final.

Of course, that could easily have been the end of the story. What convinced me otherwise wasn’t the result of the hackathon, but what happened around it. We continued showing the tool to QAs and people from other teams, and I could see that there was genuine interest in solving the problem. I already had a Confluence page where I kept vehicle information, and people were regularly going there because they needed that data. The fact that people were looking for this information told me much more than the hackathon result did.

So I continued developing Toolbox whenever I had the opportunity, adding integrations when I saw that they could also be useful to other teams. That experience changed the way I think about hackathon projects. A hackathon is very good at giving an idea a deadline, some energy and a first version, but whether an idea deserves to survive should ultimately depend on whether somebody has the problem you are trying to solve.

When user needs shape the product

One of my favourite examples of that evolution is Offer Explorer, which became particularly useful because finding offers was a recurring pain point.

If somebody asked me to investigate why offers were not working in a particular market, I might need to search across several systems before I even had the data required to begin looking at the actual problem. With Offer Explorer, I can search for offers according to the market or context relevant to the investigation and continue from there.

What I like about this example isn’t simply that a new feature exists. It’s that it removes work around the work. That distinction matters to me. Developer tooling can easily become another layer people have to understand and maintain. The real value appears when it reduces the number of steps between a question and the information needed to answer it.

The same thinking is behind the rest of Toolbox: understand where people are losing time, see whether there is a useful way of bringing information closer to them, and build according to a real need rather than an imagined one.

Making information accessible without forgetting responsibility

Of course, making information easier to access also creates another challenge: you have to be very deliberate about what information should be accessible and to whom. As Toolbox developed, one of the technical challenges was keeping it modular while also being careful with dynamically mapped fields. I had to make sure that information which could expose personal data wasn’t accidentally displayed, while access to sensitive areas also needed to remain appropriately restricted.

It is not necessarily the part of Toolbox that somebody notices when they first use it, but I consider it an important part of building something genuinely useful. Convenience doesn’t remove the responsibility that comes with providing access to information, which means usability, flexibility and appropriate access all need to be considered as parts of the same engineering problem.

Why feedback is the metric I care about most

If you ask me what I’m most proud of about Toolbox, my answer isn’t really a particular integration or feature: it’s the messages I receive from people who tell me that Toolbox helped them solve something, particularly when the next sentence is: Could it also do this?

I find that incredibly fulfilling because it means people are not only looking at what I built; they’re actually using it. And when users start asking for another filter, another piece of information or another capability, they’re effectively helping to shape what the tool should become next.

That is already influencing the next stage. I’m working on improving parts of the code and developing a new data model for vehicle information so that Toolbox can support additional filters and retain useful information more effectively over time.

There are still plenty of things I want to improve, but perhaps that’s exactly the point. Toolbox wasn’t created from a complete product vision that existed on day one. It grew because a problem existed, people recognised that problem and their feedback gave me reasons to keep developing the solution.

If I could take one lesson from the experience and give it to somebody building their own hackathon project, it would be this: don’t let the end of the hackathon decide whether your idea deserves to continue. Put it in front of people who have the problem. See whether they use it and listen carefully when they tell you what is missing, because sometimes the most important moment for a hackathon project isn’t the final presentation. It’s the first time somebody comes back and asks you to make it better.