Blog

Beneath the Iceberg: How We Built Custom Hardware Reports

Related products: All Products

Special thanks to Matthew Kipp, Engineering Team Lead of Lifecycle Manager for co-authoring this article with me.

 

In December, we released Custom Hardware Reports to Lifecycle Manager, empowering partners with fine-grained options to highlight what matters in their reporting. The reception was overwhelmingly positive!

 

Our most impactful changes often originate from our partners, and this was one of those instances. MSPs took the time to submit the idea via our product idea submission process, so we decided to take it on.

 

Building Custom Hardware Reports

For us, software development is about building excellent products as a creative team, not executing a set of requirements like a factory.

 

When considering a product idea, our process looks like this:

  1. Identify the root problem: What’s the root of the problem, what are MSPs really looking for with this idea?
  2. Assess our constraints: How long should we be willing to invest in this? What are must-haves, should-haves, and nice-to-haves?
  3. Brainstorm: What solutions could we build that meet these constraints?

 

This is not done by one person, but is rather a dynamic process including Product, Engineering, and Design. By working together we can decide on a path forward that meets the best tradeoffs for each role — the best experience, the lowest complexity, and the highest value for partners.

 

In Custom Hardware Reports, we decided that it’s worth investing the time to include a number of elements that would make the experience powerful for partners — advanced filtering & sorting, column selection, and templates to reuse configurations across clients.

JJKSowuZ2t26nulasXYD8-BshUcVXarm3QASQa3gJELe1YhfVpbdCWL-SbvUpiHSh6jBfwo4-WfH-XF4BEWo_4P6ksEfYbvfygxuwRIEEKcsWwsPT8tUgtjTedKN7gVLsSfHTQFGVErc5XaFIdIfUAE

Custom report scheduling, including custom parameters, sorting, and configurable columns.

 

We knew how much this mattered to partners, so we decided to accept the cost of building a system that would encompass all of those needs. But to make this happen we didn’t build everything imaginable. For example, in the first version you cannot edit and remove templates — you can only save new ones. As a result, we were able to deliver a useful feature without getting lost in the rabbit holes of attempting to build perfection. That said, if you want us to add more advanced template management, feel free to submit a product idea and we may take it on!

 

The Art of Software Design

In the design stage, the Product team will tend to focus on the functional requirements, whereas Engineering needs to focus on “non-functional requirements,” or quality attributes of the system being developed.

 

At this point we often do “spikes” — timeboxed tasks where we assess the existing system, design required changes, and prototype to feel out a certain approach.

 

In spiking our solution for Custom Hardware Reports, we saw that our solution would require scalability as a non-functional requirement. With thousands of paying Lifecycle Manager partners, each with many clients, we estimated our solution would need to support at least tens of thousands of reports being sent in a timely manner on the 1st business day of every month.

 

To address this, we decided on a solution that relies on us replicating / caching our asset data to a NoSQL database which is explicitly designed to support quick reads. As a result, we knew we could process the custom filters and sorting each report would require at scale without much trouble.

 

We Code with AI!

Once we’ve planned out our work, we’ll have a clearer picture of the solution, ETA, bottlenecks, and tasks. At this point, we are able to divide the work and begin coding.

 

It’s worth highlighting that AI has changed the way we code significantly. As one example, we use GitHub Copilot daily in the process of development, and it has allowed us to code more efficiently and effectively.

 

We can’t yet plug a full task into a GPT and expect a good result, let alone a feature. Due to hallucinations, AI is not yet effective for delicate tasks such as refactoring, which involves carefully restructuring existing code without altering its external behavior. That said, sometimes GPTs can save hours of frustration. To help us create custom scheduled reports, we prompted AI with queries about formatting crons for our scheduling, data modeling suggestions, and admittedly, how to center a <div> HTML element with CSS (you try it!). We’re optimistic about AI because the trendline we see indicates that it will not replace us, but rather it will help us iterate faster and focus more on higher-level concerns that require creative thinking.

 

Let’s make sure it actually works right…

It’s great to ship new features, but if they are buggy, incomplete, or break randomly we may have actually created more harm than good.

 

To mitigate this, we have a number of processes in place:

 

  1. Code quality checks — Each code change is batched into a pull request and peer-reviewed. This often catches a majority of bugs and ensures the code meets our standards.
  2. Automated regression testing — We write automated tests that check if systems are acting according to expectations before code gets shipped. This includes standard unit/integration tests, simulating a user via an emulated browser, static application security testing, and other techniques.
  3. Manual testing — We often run manual checks in intermediary environments prior to a release to production. We also run beta testing in some cases with a subset of partners to ensure new functionality is working as expected.
  4. Production monitoring — Finally, in the worst-case scenario, if a bug sneaks into production we have monitoring and alerts set up. That way, we can notice something’s amiss proactively and send out a fix as quickly as possible.

Community-based development

In the end, we’ve found that the most important part of our internal product development process is not the code, but the very human process of collaboration. Without that, decision-making is imbalanced — the bias of a limited perspective would lead us to invest too much or too little in some area.
 

It’s the same thing with external product ideas. We know that our perspective is limited, and that it’s only in partnership with our community that we can most effectively equip MSPs on their road to success.

 

So, we’d love to hear from you. Whether you're embarking on your journey with ScalePad or have been with us through many milestones, we’re all ears for your ideas. Let’s shape the future together.

 

Submit product ideas here.

Be the first to reply!