Engineering Spotlight

Meet Kyle: From Big‑Tech Builder to Product‑First Engineer at Numeric

Kyle joined Numeric about a year ago, arriving by way of Amazon and then Opendoor, a mid-sized real estate tech company. Each move was deliberate. He was chasing something specific: more product thinking, more proximity to the customer, more of the work that actually ships.

At Numeric, he found it. Kyle has spent the majority of his time here building the cash matching product from the ground up. The team started building in May, shortly after he joined, and went live in December. It was genuine zero to one work in a new product space.

In this interview, Kyle shares what it actually looked like to build a brand new product from the ground up, how working directly with customers reshaped his thinking as an engineer, and what he would tell an engineer just getting started at Numeric.

1. What drew you to Numeric, and how has working here shaped the way you approach engineering problems?

   What I’ve learned is that I really enjoy thinking about problems from a product lens, wearing that product hat, standing at a 30,000 foot view and figuring out what we want and what we should actually be doing. It’s a skill I both enjoyed and wanted to get better at.
   
   

   I came across Numeric and it checked a lot of the boxes in terms of what we care about and how we think about product, which was kind of the foot in the door. As I learned more about the space, it started to make a whole lot more sense. I didn’t know a ton about accounting at all, but through talking to Numeric, I realized there’s this really gigantic gap between how I expected accounting to work and how it actually does.
   
   

   In a way, there are a lot of parallels to how software has evolved over the years. Accounting today kind of works the same way it did back in the 90s. It’s just a bunch of unstructured data that people put all over the place and hope that it ties out at the end of the day. These teams can get pretty big and it gets very complex. There are parallels to typed programming languages, where suddenly code becomes a lot more stable when you enforce strict typing around your data and how information should flow through the system. Enforce better change management. As code changes, people review it, people understand it, and think of things more from a systems point of view instead of shifting random lines of data here and there.
   
   

   That gap between how I think accounting should work and how it does today really drew me to the problem space. And similarly, nobody’s really doing anything about it yet. It seemed like a juicy problem to chew on, one that we could do a lot with, and that’s why I’m here.

2. What was the biggest mindset shift you experienced when building software for accounting teams versus other types of products?

   One of the interesting things at Numeric is designing for the power user, which I had not really done before. Previously, the products I’d built came more from a B2C lens. When you’re designing those kinds of products, the goal is really to make things as simple as possible for the end user. Don’t make it complicated. Build things that let them easily understand what they’re trying to do.
   
   

   When you’re building for accountants, it’s pretty different. These are people who are very knowledgeable about what they’re trying to do and they don’t want smooth workflows with big padding and pleasant looking things. A lot of accountants are power users who are used to working in very dense spreadsheets with a lot of information packed into one place and making decisions from there.
   
   Correspondingly, there are a lot of really complex accounting workflows that necessitate very strong and powerful tools to get those things done. What we build at Numeric is designed for somebody who really wants strong control of what they’re doing and dense information in one place. Which is different from how I’ve thought about tools before.

3. Can you share an example of how real accounting workflows or user behavior changed your technical approach to problem solving?

   As we were building out cash, a lot of what we were trying to understand is the line between configurability and simplicity. It’s related to this idea of designing for the power user. In cash, there’s a set of reconciliations you have to do and a set of rules you have to configure. Finding the right abstraction in that balance of complexity versus understandability has been an interesting journey for us.
   
   

   Thinking through real accounting workflows, let’s say you need to create a many-to-many match between two sets of lines, and those groupings can be defined in abstract ways across data or found dynamically. There’s a lot of complexity there that made us walk this fine line between product experience and configurability. Going through the cash workflow has been really interesting in figuring out where that line is. The takeaway for problem solving specifically is to start with the simple use cases, then keep stress testing against more and more complexity, building it out, seeing where it breaks, fixing what breaks, and going from there. Really just starting simple and building out the scope from there.
   
   

   What really helps is starting with a design partner early on. We worked with Brex from day one. We found them because their matching workflows were representative of the people we talked to, but not so complex that it would make it impossible to figure out where we were going.
   

   
   Starting from that simpler but generalizable case, building for them, adding a few more people, building for those people too, seeing where our previous assumptions broke, and going from there has been instrumental in getting the cash product off the ground as smoothly as it did. That type of problem solving is really important in a space like accounting where you can go deeper and deeper into the weeds. It’s important not to bite off too much in the beginning.

4. Since joining Numeric, has your perspective on good engineering changed? If so, how?

   My perspective coming in was shaped by larger companies where things move a little more slowly and carefully. Back then I thought that was just how you did engineering. You ship things that are correct and figured out already, and you continue to make them more correct over time.
   
   

   Coming to Numeric, that perspective has shifted quite a bit. A very concrete example is the feature flag. At bigger companies you’ll often put things behind a feature flag, expose it to a couple users, and figure it out from there. That can work in places where it’s really important that things aren’t broken. But one thing we actually do at Numeric, especially earlier in the product life cycle, is intentionally discourage feature flags.
   
   

   My point of view has shifted considerably on this. I’m now of the opinion to just get things in front of people as fast as you can. Even if it’s not perfect, get their feedback right away, because there’s always going to be a misalignment between what you built and what they were expecting. Those two things can converge if you just put it in front of them, get their feedback, and figure it out from there.
   
   

   That’s representative of how we operate at Numeric. Build things with urgency and get them in front of people as fast as possible. You don’t necessarily have to be super careful about that. Don’t break things for people that matter, obviously, and once you have a lot of people depending on a product that workflow changes. But as you’re trying to figure out a problem space, there are a lot of learnings that come just from going and building it. Learnings for the engineer, learnings for the customer. When you put something in front of them, it kind of changes their perspective on what they thought they wanted in an interesting way. Proceeding with less fear and more urgency has been really important.

5. How have your interactions with customers either at onsites or elsewhere changed your thinking as an engineer?

   It’s been really cool. We have New York clients at Numeric and I’ve been to four or five different companies for on-sites. With Brex, as we were building cash, we went on-site several times over the course of several months.
   
   

   In terms of how it’s changed my thinking as an engineer, I wouldn’t say it’s materially changed how I think about a product and getting it in front of people. I think that’s always been the case. But what has changed is my motivation. It’s really energizing as an engineer to go on-site with a customer, hear what they’re frustrated about, and then go fix it for them either the same day or the next, and see their trust in you change significantly.
   
   

   That’s both energizing and really awesome in terms of making someone’s day or fixing their problems. But there’s also a ton of value in just getting face time with a customer. Over a call you might have this barrier of corporate speak. Someone using your product might be scared to tell you the truth about what they think. But getting on-site with them builds rapport. You work through that barrier and suddenly they’re telling you a bunch of things they never communicated before because they trust you more and you’re there to listen.
   
   

   As you go through that loop of fixing things for them as they bring them up and building that trust, you learn a lot more about your product than you thought you knew beforehand.

6. What advice would you give engineers new to Numeric or to building products for financial systems?

   One piece of advice: you’re not really going to understand the problem until you go and build it yourself. That’s certainly been true for cash, where so much of the learning has come from just building it out.
   
   

   Initially we thought cash was going to be a pretty quick project. Justin, the other engineer I worked on it with, famously said “I can build this in two weeks.” As we got into the weeds we learned more and more about the complexities of the space. It turned out to be much more complicated.
   

   
   So really just go and build it. Get your hands on the data, test your assumptions, and keep going through that process over and over again. Your mental model of what the problem space actually is will get bigger and bigger. Put it in front of people and see what happens. Those learnings will build up and compound over time.

   Kyle's path from Amazon to Opendoor to Numeric reflects a deliberate pursuit of something most large companies make hard to find: the chance to build something from nothing, stay close to the customer, and feel the direct impact of your work. Building cash from the ground up gave him all of that, and then some. What comes through in his answers is an engineer who has genuinely shifted his thinking, not just about how to ship faster, but about what good engineering actually means when real users are depending on what you build. That orientation toward the customer, toward urgency, and toward learning by doing is exactly the kind of engineering culture we are building at Numeric.