The report that had to sit in reception
When we built ESGRapporter, the competition had heavier calculation engines than we did. We bet somewhere else: on what the user was left holding being worth showing to someone.
The requirements arrived with the CSRD directive and the ESRS standard that comes with it. They hit the large listed companies first, but the effect travelled downwards: a large company has to report on its entire value chain, and suddenly its suppliers found a questionnaire in the inbox.
A manufacturer with thirty employees had neither a sustainability department nor the budget for a consultancy. But it did have a customer demanding the numbers.
That company is who we built ESGRapporter for. I was a co-founder and CTO, and the platform had to make an ESG report possible for someone who neither knew the standard nor had anyone to translate it.
The market was already there, and it held tools with heavier calculation engines than ours would ever have. So the question was not whether we could build another one. It was what to build instead.
The numbers are not the hard part
What users got stuck on was rarely a calculation. It was the descriptive sections.
An ESG report is not only consumption figures. Something has to be said about the company's policy in the area, about how risks are handled, about what was done this year and what is planned. That cannot be computed. It has to be written.
And there sits an operations manager with an empty field and a heading that reads like something out of a statute. They know perfectly well what the company does. They just do not know what one writes.
Taking the user by the hand
That is where the work was. Not in explaining the standard, but in saying what should go there.
Every field got its own way in: what this section is about, what usually goes in it, what a reader would want to know. Not a definition of the requirement, but a concrete suggestion of what you might answer. We used AI to help finish the wording from the user's own notes – not to invent the content, but to turn three lines into a paragraph that reads.
The difference is who stands behind it. An ESG report is a document the company answers for. Generated by a model making educated guesses, it falls apart the moment somebody asks where it came from.
The report is a product, not a filing
The other half of the bet was the document itself – what sat on the screen when the work was done.
Most tools in the market delivered data. A spreadsheet, a compliance file, something to pass on and file away. Technically correct, and entirely without value on the day the company would like to use the work for something.
Because when a company with thirty employees has spent a week on this, it does not just want it over with. It wants to show it. To the customer who asked. On the website. To a partner who raises sustainability, because it has become part of the conversation.
So our report had to be printable. Thirty A4 pages with a cover, typography and a layout carried through – not a PDF printout of a form, but something that looked like an annual report. Something you could leave in reception, bring to a meeting, show your business partner.
When design and code are the same problem
It was also why the job suited me. I have done graphic design as long as I have written code, and here the two sat inside the same product.
A report layout that has to hold with content nobody knows in advance is not a design problem or a code problem. It is both at once: a table has to break across two pages without losing its header, a section of forty words and one of four hundred both have to look as though they were meant that way.
Had a designer drawn it and somebody else built it, we would have ended up in the round where the drawing and reality negotiate. Here there was no round.
The hard part is saying no
Every time a user got stuck, there was a temptation to add: one more field, a note, an exception, a setting. Each of them is reasonable on its own.
Together they are the reason the original problem exists. The enterprise tools for ESG are not complex because somebody wanted them complex. They are complex because every single addition made sense when it was made.
Keeping something simple is not a phase at the start of a project. It is a decision you have to make again every time.
