What I Am Building

I’m building two pieces of software right now. One is for my day job. One is for me. Both exist because I got tired of waiting for someone else to build them.

The Work Project: BPStool

At SBW Consulting, I work with engineers who help building owners navigate Building Performance Standards. If you’re not in the energy world, BPS is essentially a set of rules that says: your building needs to hit certain energy or emissions targets by certain dates, or you face penalties. Cities and states across the Pacific Northwest are rolling these out, and building owners are scrambling.

The problem is that compliance isn’t straightforward. There are multiple pathways, different requirements depending on your building type and location, and a lot of documentation to manage. Our engineers were spending too much time on administrative work and not enough time on actual engineering.

So I built BPStool.

It’s an internal tool that shepherds building owners through the compliance process. TypeScript backend with NestJS, Vite frontend. Nothing revolutionary from a technical standpoint, but it solves a real problem for real people on my team. They can track where each building is in the compliance process, generate the right documentation, and focus on the engineering judgment calls instead of paperwork.

I’m not going to pretend this is changing the world. It’s an internal tool for a consulting firm. But it works, and my colleagues use it every day, and that matters to me.

The Personal Project

This one is different. This one I’ve been thinking about for years.

I’m building measurement and verification software. If you’re not in the energy efficiency industry, M&V is how you prove that an energy project actually saved the energy it was supposed to save. Did that HVAC upgrade reduce your building’s consumption by 15%? How do you know? M&V is the answer.

I’ve spent a decade working in this space. I wrote parts of the national standards that define how M&V should work. I evaluated over 150 energy efficiency programs. I oversaw more than a thousand individual M&V projects. I know this domain inside and out.

And I can tell you: the existing tools are not good enough.

I’m building the tool I’ve always wanted to exist. More details in April.

Why I’m Building This Myself

Here’s the thing people find surprising: I’m not a developer by training.

I didn’t learn math until I was 25. I came to this industry through policy and program evaluation, not software engineering. I can’t whiteboard a binary search tree or explain the intricacies of memory management.

But I can build things.

I work with AI assistants constantly. Claude Code, whatever tool is going to help me ship working software. I describe what I need, I iterate on the output, I test it, I fix what breaks. It’s a different workflow than traditional development, but the end result is the same: working code that solves real problems.

This is a new way to build software. You don’t need a CS degree. You don’t need to memorize algorithms. You need to understand your problem domain deeply, communicate clearly about what you want, and iterate quickly when things don’t work.

I understand M&V deeply. I’ve been doing it for over a decade. I know the edge cases that trip people up. I know which calculations are actually important and which are theoretical niceties that never matter in practice. I know what questions clients ask and what reports they actually need.

That domain expertise is worth more than knowing how to implement a B-tree from scratch. The AI handles the implementation details. I handle the “what should this actually do” questions.

The Open Source Philosophy

When my personal project is ready for public release, I’m going to open source it.

Not because I’m a saint. Because it’s the smart play.

Think about WordPress. The software is free. Anyone can download it and run it. But Automattic, the company behind WordPress, makes hundreds of millions of dollars providing hosting, support, and premium features. The free software is the marketing. The services are the business.

Or think about Red Hat. Linux is free. Red Hat built a multi-billion dollar company providing enterprise support and services around free software.

M&V software should be free. The calculations aren’t proprietary. The methodologies are published in public standards. There’s no secret sauce in the math. The value is in doing the work correctly, and doing it at scale, and having someone who knows what they’re doing help you when you get stuck.

I’m going to give away the tool. I’m going to monetize implementation services.

Building owners and program administrators will be able to download it and run it themselves. If they have staff who understand M&V, great. They don’t need me. But most of them don’t have that expertise in house. Most of them will want help setting it up, training their team, and making sure they’re using it correctly.

That’s where the business is. Not in licensing fees for software. In expertise.

The Connection to Standards Work

I write national standards for energy efficiency. I serve on committees that define how M&V should be done, how buildings should be evaluated, what counts as a legitimate savings claim.

There’s a strange tension in that work. We write these documents that say “this is how you should do things,” but we don’t provide the tools to actually do them. It’s like writing a recipe without providing a kitchen.

Standards define what should happen. Tools make it actually happen.

BPStool is a tool for implementing BPS standards. My personal project is a tool for implementing M&V standards. Both of them take the abstract requirements from these documents and turn them into concrete workflows that people can actually follow.

This is why domain expertise matters so much. I know what the standards actually say. I know where the ambiguities are, where practitioners get confused, where the real world doesn’t match the ideal world described in the documentation. I can build tools that handle those edge cases because I’ve lived them.

Someone who just knows how to code would have to spend years learning the domain before they could build something useful. I already have those years. Now I’m learning to code (or learning to work with AI that codes for me, which is close enough).

Building in Public

I’m going to write more about this as I go. The technical challenges, the product decisions, the business model thinking. Not because I think I have all the answers, but because building in public keeps me accountable.

If I say I’m going to ship something, and then I write about it here, I actually have to ship it. That’s useful pressure.

Also, I think more people should know that you don’t need to be a traditional developer to build software anymore. The tools have changed. The barriers are lower. If you understand a problem domain deeply and you’re willing to iterate, you can build something useful.

I’m not special. I’m just willing to try things and see what happens. More people should try things and see what happens.

That’s what I’m building. That’s why I’m building it. More updates to come.