Our events kept falling short.

Sometimes they lost money. Sometimes they broke even. But the frustrating part was that we often didn’t know which one we’d gotten until the event was over.

By then, of course, there wasn’t much we could do about it.

I wanted us to be able to answer those questions before we committed to an event.

What does this event actually cost?

How many people need to attend?

What should we charge for tickets?

How much sponsorship do we need?

And there was another wrinkle.

As a nonprofit, making the most money possible from ticket sales wasn’t necessarily the goal. We wanted people to attend. If sponsorship could cover more of the event costs, we could keep ticket prices lower and make the event more accessible.

So I started working backward from the outcome.

If we knew the costs, expected attendance and ticket price, how much sponsorship would we need to break even?

Or if we knew how much sponsorship we could reasonably raise, what could we afford to charge for tickets?

Or what happens if attendance is lower than expected?

The calculations weren’t particularly exotic.

But I didn’t want to be the person who had to do them every time someone planned an event.

So I built a calculator.

Someone planning an event could enter the assumptions and see what happened. Change the ticket price. Change attendance. Add sponsorship. Change the costs.

Instead of finding out afterward whether an event worked financially, we could explore the possibilities beforehand and make decisions while there was still time to change them.

And then something interesting happened.

The thing I’d built to solve our problem turned out to be useful beyond the original problem.

I’ve built things like this throughout my career—spreadsheets, calculators, dashboards, frameworks, checklists. Usually not because I woke up wanting to build a tool.

Usually because I was trying to answer a question.

And, apparently, because I didn’t want to have to answer the same question manually forever.

I’ve started thinking of these as the tools left over.

You solve the problem once.

Then you notice that part of the solution can be made repeatable, handed to someone else, or used to answer the next version of the question.

Sometimes what’s left over is useful enough to keep.

Sometimes it’s useful enough to share.

That’s where Green Hawk Tools come from.