Building closer to the problem: from accounting to engineering through billing

If you had looked at the start of my career, engineering would not have been the obvious destination. I started in accounting, spent years deep in billing and finance systems, and kept finding myself drawn closer to the technical side of the work. The more I understood how billing actually worked inside a company, the more I wanted to own the systems behind it.

A lot of that started at Slack. I was the first revenue accountant there, and because the billing model was usage-based (before it was cool!), I ended up doing a lot of the work by hand. I pulled reports, worked closely with Stripe, handled invoicing workflows, and became the person who knew the details of how the model actually worked. Over time, I found myself wanting to be closer to the work of actually building those systems.

"I knew the changes I wanted to make, and I wanted to build them myself."

That shift did not happen all at once. I taught myself SQL, moved into a more technical product-oriented role, and eventually made the jump into engineering. What kept pulling me forward was the same thing every time: I liked working on hard technical problems that sat close to the business, and I liked being close enough to the system to actually fix what was broken.

Why Orb was the right fit

When I joined Orb, I already knew I wanted to be back in the billing space. I had intentionally moved onto an internal billing systems team before, and worked on implementing Orb from the customer side, which gave me a close look at both the product and the people behind it.

What stood out to me was the caliber of the engineering team, and it was obvious I was working with people who understood the domain deeply. Billing is one of those spaces where surface-level understanding only gets you so far. Orb also felt like the right fit because of the kind of problems the team was solving. There are a lot of use cases, a lot of edge cases, and very little room for hand-waving.

Where Pricing Lifecycle sits

At Orb, we have three engineering teams: The infrastructure team takes in the events our customers send to Orb, the pricing lifecycle team takes those events and turns them into prices, subscriptions, and invoices, and the revenue team helps present that information in the way finance and accounting teams need to work with it.

My role sits on Orb’s pricing lifecycle team. We work on the part of the system that turns product usage into the actual logic of billing. That means taking the events customers send into Orb and turning them into prices, subscriptions, and invoices. In practice, we are working on the rules that determine what gets charged, when it gets charged, and how different pricing and contract structures behave once they are live.

That is part of what makes engineering on this team technically interesting. You are building systems that customers depend on to run their business, and every edge case matters.

Building dunning from first-hand billing experience

One of the clearest examples of that fit was getting to help build the foundation for dunning. The project mattered to me because I had already seen the problem from the other side. Earlier in my career, I had manually downloaded invoices, sent them to customers, and tried to keep track of overdue follow-up by hand. I had also seen what happens when failed payments cause a risk of losing revenue. By the time I worked on dunning at Orb, I was coming back to a problem I already understood.

At Orb, dunning is built as a rule-based system for handling failed payments and overdue invoices. It uses configurable schedules to trigger retries, send email reminders, and move an invoice through collections based on the specific conditions tied to that customer or invoice.

We already had some pieces in place, but I got the chance to help rebuild the service on a much stronger foundation. That part of the work felt especially meaningful because it solved a problem I knew first-hand while also creating a base other teams could continue building on. That is also what I like about how Orb works. The first version does not need to be the final version for it to matter. It needs to solve something real and create a strong path for what comes next.

Growing through ownership

One of the biggest things Orb has given me as an engineer is the opportunity to take real ownership. Because the company is smaller and scrappier, there is a lot of room to take responsibility for important problems, follow them through, and grow through that process.

That kind of environment is a strong fit for engineers who want real responsibility, and there is also a lot of room to improve existing systems, shape better solutions, and take ideas seriously from start to finish.

It also helps that the team is deeply collaborative. We work closely with infrastructure, success, and support because customer needs have to stay top of mind. Internally, we pair program, work through ideas together, and break down large problems into pieces that each person can own before bringing them back to the group. That combination of ownership and collaboration is one of the things I value most about working here.

The kind of engineer who grows here

The engineers who tend to thrive on this team are the ones who want to solve hard problems all the way through. They are comfortable with complexity, like working inside real systems, understanding where those systems fall short, and improving them carefully.

I also think this is a strong fit for engineers who care about details for the right reasons. In billing, details are not cosmetic. A slightly off workflow, a confusing display, or a gap in logic can chip away at trust very quickly. We test thoroughly because the work demands it. Customers need to trust what they are seeing, and they need to trust that the system will hold up when it matters.

“At Orb, ownership is real. You are expected to take a problem from ambiguity to implementation.”

That level of responsibility is what makes the work compelling to me. I came into engineering by way of billing, but I stayed because I like building in a space where the problems are real, the systems are consequential, and the work asks a lot from the people doing it. Orb has been the right place for that kind of growth.

If you are the kind of engineer who likes edge cases, ownership, and business-critical systems, Orb is the kind of team where you can do some of your best work. Check out our careers page for open roles.