All posts

The Day Jasper Made Me Snap (And What I Built Instead)

I've dealt with legacy codebases, race conditions at 2am, and bad architecture meetings. None of that broke me. Jasper Reports almost did.

A man walking his golden retriever down a quiet residential street at golden hour, lost in thought

I've been a software engineer for over a decade. I've dealt with legacy codebases that looked like they were written by someone actively hostile to future developers. I've debugged race conditions at 2am. I've sat through architecture meetings where someone suggested rewriting everything in microservices for a CRUD app with twelve users.

None of that broke me.

Jasper Reports almost did.

The Problem With "Standard" Reporting Tools

At a previous company, I was tasked with building a reporting module. The requirements were straightforward: pull data from a few sources, render it nicely, export to PDF. Classic stuff. I'd done similar things before, so I wasn't worried.

Then I opened the Jasper documentation.

What followed was several days of learning a proprietary XML schema, wrestling with a visual designer that had clearly been designed by someone who hated visual designers, and trying to figure out why my query (which worked perfectly in PostgreSQL) was behaving differently once it passed through Jasper's query layer. At every turn, I wasn't solving a business problem. I was learning Jasper.

To be clear: Jasper is not a bad tool. It has been solving reporting problems for decades and has an enormous ecosystem behind it. The frustrating part was something else entirely. I already knew how to do everything it was doing. I just had to do it Jasper's way. HTML and CSS for layout? I know those. GraphQL for data? I know that. But Jasper wanted me to learn a whole new vocabulary to express things I already knew how to express. That mismatch is what I could not shake.

I finished that project. But unlike most work frustrations that get filed under war stories and forgotten, I could not let this one go. In 2023, I started building an open source proof of concept: HTML templates, GraphQL queries, browser-based rendering. It worked. Then life got busy and I shelved it. But the idea stayed with me.

A Dog Walk and a Spark

Fast forward to early 2024. I'm on my Onewheel, riding around the neighborhood with my golden retriever Luna, who is deeply unimpressed by my decision to resurrect a year-old side project. And I start thinking: why isn't this a real product?

Every developer already knows HTML and CSS. Every developer working with APIs has probably touched GraphQL. What if a report was just an HTML template with GraphQL queries in it? What if the rendering engine was the browser, the thing we already trust to render everything? What if connecting to a data source just meant defining a schema, not learning a new DSL?

Luna did not have any objections. I came home, dusted off the old code, and started building in earnest. A few months later, in August 2024, Wolfware was officially a company. Golden Reports, the thing born out of that Jasper frustration years earlier, was its first product.

Introducing Golden Reports

The core idea is simple: reports are HTML + CSS templates with GraphQL queries for data. If you know those technologies, you can build a report. No proprietary language to learn. No custom schema to memorize.

Here's how it works:

  • Data Sources: connect to your actual data, PostgreSQL, REST APIs, and more
  • Data Contexts: define a GraphQL schema on top of your data source, a clean contract between your data and your reports
  • Reports are HTML + CSS templates with GraphQL queries, rendered in the browser by built-in components

A Monaco editor (the same one powering VS Code) lets you write templates and queries with full syntax highlighting and autocomplete. It should feel familiar from the first minute.

What's Coming

We're targeting a soft launch before the end of May, starting with PostgreSQL support and HTML output. PDF, Excel, and other formats are on the roadmap. A visual schema editor is planned post-launch for teams who prefer a non-code interface.

The soul of the product is, and will always be, developer first. No custom languages. No proprietary abstractions. Just HTML, CSS, and GraphQL doing what they already do best. It is not trying to replace Jasper or out-feature SSRS. It is just a more familiar path for developers who think in web technologies.

If you've ever spent an afternoon fighting with Jasper, SSRS, or Crystal Reports when you just wanted to render some data nicely, this one's for you.

Subscribe to the newsletter below to get updates as we get closer to launch.

Mariano Santoro
Published February 26, 2026
All posts