Nick joined Numeric with nearly nine years of startup experience behind him. He started his career at Addepar as a full-stack engineer building financial software for asset management, gravitated over time toward backend development and architecture, did a brief and decisive stint in grad school (”left very quickly, was not for me”), and spent time at Attentive on their data platform team before landing at Numeric. Data-heavy work has been the running theme ever since, and it’s where he is most at home.

In this interview, Nick talks about what it means to engineer for sophisticated users, why he stopped worrying about not having a roadmap, and what on-sites taught him about who the real systems thinkers are.

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

I think my answer is very focused on engineering culture and mindset. I really describe myself as a craftsman. I care about software as a craft and the output of software itself being high quality. I’ve always felt that the production of high quality software is an end in itself. Even if the goal is pushing out impact and value into users’ hands, the best way to go about it is to also care about the details of the software.

I very much felt that sense, that intuitive feeling, from everyone I interviewed with at Numeric. Everyone seemed like they had a similar care of craft. Very crucially, though, it was balanced by a strong motivation to deliver good product at high velocity. It’s really easy to end up working on a team that cares about software but doesn’t invest enough into pushing out the right product decisions. Numeric balances that very well. It hit that hard-to-balance niche: a place where people care about the software they write, but are also pushing out product that’s actually very impactful.

2. What was the biggest mindset shift when building software for accounting teams?

Accountants are very sophisticated users, and very opinionated in the best ways possible. I took for granted just how much sophistication I can expect from them, in terms of how they do their workflows today and their sense of what good solutions look like. I have been continuously impressed with the way that accountants have solved their own problems peppered over suboptimal tooling.

As a consequence, I don’t feel afraid, and I don’t feel like I need to handhold in pushing out a solution I think is complex. In fact, sometimes what I’ve found is that my natural instinct, the voice that says “users are going to get confused about this,” is actually detrimental. It’s often better to push something in front of users that I feel is too complicated, because they’ll surprise me and grok it immediately. The more constrained solution actually limits them and pisses them off. Like: why won’t you let me do X?

3. Can you share an example of how real accounting workflows changed your technical approach?

Going on-site and watching clients close their books was a big one. I saw someone show off a Python script they’d written to automate data aggregation for a monthly email they send to their CFO. Something very specific that they solved in a very technical way. And I found that kind of finely grained, pinpointed solution is quite common. Teams have bespoke processes because of the nature of their business. They come up with unique solutions to unique problems.

That directly informs how I think now. I’m not shying away from saying we’re going to have a big configuration page where users are technically configuring conditional logic that could be quite complex. With the right UI, just handing them a big box to play with, I trust that our users can handle it. That’s directly informed by what I’ve observed from them.

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

One thing I’ve very much over-indexed on in the past is having a roadmap, or at least a clear-cut North Star to inform my immediate decisions. I’ve leaned very platform-heavy, backend-heavy, critical-systems-heavy, and I used to have a lot of anxiety about the unknowns. If I didn’t have a clear sense of where something was going to grow, what the difficulties were going to be, I felt anxious.

At Numeric, it’s been nice to just let that go and become better calibrated at considering what matters in the moment. Most problems we’re trying to tackle, we won’t find the right solutions until we’re facing them. So it actually behooves us to build out software, push it out there, see what falls over, and then respond to it as it does. We’re not manning the space shuttle. If my code goes down, I don’t have to worry about the accounting team blowing up in a fiery explosion.

5. How have interactions with customers at on-sites changed your thinking as an engineer?

I think I had an unstated bias that systems thinkers are primarily found in engineering. I thought of it as: we are the computing experts coming in, you are the expert in your domain, let’s see how my expertise can help empower yours. I took for granted how much that concept of a systems thinker applies across all kinds of domains.

I no longer think engineering is where you find the systems thinkers. Accountants are systems thinkers. They work with sophisticated systems all the time. Some of our solutions team members who are former accountants are among the best systems thinkers I’ve encountered in my career. That’s a phrase I never would have said before about someone outside of engineering.

On-site, I’ve seen that play out. Someone automating a monthly email had to interact with six or seven different data systems to pull everything the CFO needs for a four-sentence email every month. That requires juggling a lot in your head. Beyond just the accounting, there’s a random constraint from an Excel spreadsheet over here, and all of that has to fit together. It was genuinely eye-opening.

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

Go on-site. I would be making worse software right now if I hadn’t gone on-site early on to really burst my bubble and learn more about how accountants think, and to challenge those implicit biases about what it means to deliver good software and what it even means for my users to need my help.

And then lean in heavily to your area of expertise, knowing that no matter where you choose, you’ll have interesting problems to solve. I don’t think there’s a single boilerplate, cookie-cutter area of the stack here. In extracting data, we’ve applied interesting algorithms to deal with the constraints of accounting data. In designing user workflows, there are interesting constraints around how accountants think about things and how reports have to be formatted. At Attentive, I never really had to think about the fact that I was working with marketing data. It was just blobs of data going from here to there. I don’t think that’s the case with our work. Accounting knowledge bleeds its way in everywhere.

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.

Once you have a Money object in your code, the next challenge is storing it in a database without losing its structure. This guide compares common storage methods and lands on Postgres custom composite types as the superior choice.

This approach allows you to keep your amount and currency bundled together at the database level, ensuring data integrity while using Drizzle ORM to automatically map those database records into clean, type-safe TypeScript objects.

At Numeric, we've been designing how our code interacts with money using Martin Fowler's money pattern. As part of this effort, we want to use an integer, lowest denomination representation of money in both our application code, as well as our database.

In our previous post, we discussed modeling money using BigInt in JavaScript. In Postgres, we have bigint which isn't exactly the same as JavaScript's BigInt but what matters is that any valid Postgres bigint can be deserialized into a JavaScript BigInt. We could handle this bridge ourselves in application code but it's much simpler to leverage an existing ORM or query builder such as drizzle-orm. While it has "ORM" in its name, Drizzle is just a query builder that provides a thin, type safe layer above SQL. This helps us catch errors without abstracting away the most powerful features of SQL.

When storing money, we have two components, the currency code and the amount. Traditionally, we would store these two values in two separate columns. This is fine, but when interacting with a money object that has amount and currency bundled together, it requires extra effort from the developer to break down the JavaScript fields into the Postgres columns. For example, let's try inserting a transaction record using drizzle-orm.

Then when we read our data back from the database, we have to reconstruct our money type.

This creates extra friction whenever querying the database or inserting records. When changing developer workflow across a large team, we want to make the transition as frictionless as possible in order to drive adoption. We should increase velocity, not slow ourselves down. Luckily, we can have drizzle handle serialization on our Money object using custom types. Unfortunately, we run into the limitation that custom types cannot span across two separate columns; we would need to put both amount and currency in the same column. Traditionally, SQL doesn't allow you to do this, but with Postgres, we can use JSONB to combine both fields together.

This is fine, but we lose some restrictions that we had before. We can no longer validate that the amount is an integer and we can no longer validate that the currency has a length of three. In addition, the query syntax for JSONB deviates from regular SQL syntax. For example, if I wanted to sum all my transactions, our original two-column approach would be easier to understand.

But what if we could have database-level validation and an approachable SQL syntax at the same time? Maybe we can use Postgres custom types! Using Postgres custom types, we can enforce that the amount is a bigint and our currency code as being three characters.

When summing the money_with_currency column, the SQL query looks pretty similar to our two-column approach.

In addition, a custom type defines the type for just one column, so it maps neatly to Drizzle's custom type. We can turn our JavaScript Money object into a composite type string that Postgres expects. We can also parse back Postgres' custom type string into our JavaScript Money object.

When using this custom type in our application code, drizzle will handle converting our Postgres custom type into our JavaScript Money object.

With our Postgres custom money_with_currency type, we get database-level validation, a simple, familiar SQL query syntax, and we get clean serialization and deserialization of our JavaScript Money object when interacting with the database.

Custom types are not supported with Drizzle’s default query helpers like eq and inArray, so we can create helpers to access our amount and currency fields.

And we can continue extending this idea to create other complex SQL string builders. For example, we could create a custom moneyEq helper that can check equivalency on both amount and currency.

This is a simple example where we can only compare a column against a JavaScript Money object, but you can extend the query helper to also be compatible with checking equivalency between money_with_currency columns on different tables.

Providing a set of well-tested query helpers that are equivalent to Drizzle’s query helpers can reduce errors from hand-writing SQL template strings and also take care of SQL edge cases that downstream developers may forget to consider.

In conclusion, using a Postgres custom type allows us to cleanly map our JavaScript money representation into the database. In comparison with our two-column approach, we remove the need to manually map queried data into our JavaScript money object. When comparing to our JSONB approach, we get database-level data validation and a simpler query syntax. Using our money_with_currency type provides a clean interface when moving between JavaScript and Postgres.

Standard decimals and floats often lead to “disappearing cents” due to rounding errors. This post explains why you should treat money as a composite object—pairing a currency code with a BigInt (the smallest unit, like cents) instead of a decimal. By using specific algorithms for splitting and allocating funds, you can ensure that every penny is accounted for across your application, while leveraging modern browser APIs to handle complex international formatting.

When we think about money, it’s easy to think of modeling it as a decimal number. After all, we have dollar amounts for our integer component and cents for our decimal component. If you’ve used decimal numbers in JavaScript, you’ve inevitably run into its bizarre division behavior.

This is a real issue with modeling money since first, $0.000000000000000004 does not exist and second, the math isn't even being computed correctly. Incorrect computations are solvable with a big decimal library such as big.js that supports arbitrary and accurate decimal multiplication and division. So let's try that out with a new example.

Well, $1.66666666666666666667 is still not quite a valid value for US Dollars. We have to treat money as a separate data type that doesn’t behave like a regular decimal number.

This is exactly the problem we hit at Numeric. We were using a variant of big.js to handle money, modeling it as an arbitrary-precision decimal. We’ve since decided to adopt the Martin Fowler Money pattern. The basic idea is that unlike regular numbers, money is a real thing that has a smallest denomination.

Treating money as a decimal number is straightforward; what you see is what you get: a 10.99 decimal is $10.99 USD. The issue arises when dealing with rounding. Without good primitives, it’s up to each developer to handle rounding themselves. For example, splitting a $1,000 contract over three months results in three invoices of $333.333... The problem is that three-tenths of a cent doesn’t exist in the real world, much less 33 hundredths or 333 thousandths.

So, what are the rounding rules here? We can’t just round down; otherwise, the sum would become $999.99 and we’d be missing a cent! Our books won’t add up during the month-end close. But instead of discussing remainders and long division, perhaps we should answer a different question: How can we model a real-world value like money in code?

In the past, JavaScript was limited by its data types, supporting only floats as the number type. Some libraries solved this issue by checking Number.isInteger, but nowadays, we can instead use BigInt to enforce this at the data type level. Finally, a worthy integer type. Of course, we can't ignore the runtime penalty of BigInt compared to number when doing math operations like + or -; however it's a worthy trade-off since there is the additional benefit of avoiding number overflows when attempting to represent really large amounts of money. With this in mind, our example becomes as follows.

With that in place, we must also consider the currency component of money. We can start with a simple example of adding together money of two different currencies.

If I handed you a ten US dollar bill and a ten Euro bill, you wouldn't be able to buy a burrito worth twenty dollars in either currency. Money operates on the principle of currency. We can't add money together unless we know we have the same currency. This is easy in the real world, since Euros and Dollars look different. It's also easy in JavaScript. Let's add a currency component to our money representation.

And let's add some checks before we add our money.

This is a good start to building a money library. Using the principle of currency comparison before operation, we can build functions for many common mathematical operations such as comparison operators (greater than, less than, equal to, etc.), addition and subtraction.

The main issue with this approach is that we must do explicit currency comparison before we operate in order to avoid runtime exceptions.

Leveraging the Type System

So what if we could leverage TypeScript’s type system to enforce the same currency rule during compile time? It might look something like this.

The compiler can actually catch that we are operating on two different currencies! This is a fun idea coming from Haskell's type system. Unfortunately, the compiler can't see into the real world. When we receive money over the wire from an API call or from a database query, we still need to have our runtime checks to enforce currency compatibility.

Division

Now that we can add money together, the next most useful thing is dividing money. We have a lot of accountants at Numeric and they do love to divide money into different buckets. Division is not as simple as addition; we must take special care when implementing operators that can produce remainders. Remember, money is a real thing, not an arbitrary floating point number.

Let’s start with a simple example. Andrew, Parker, and Anthony go to lunch. The total for lunch comes out to one hundred dollars and, since they’re good friends, they decide to split the bill evenly in thirds.

Where did the last cent go? If you’ve used Venmo to split a bill before, you may recognize this scenario: one person ends up having to pay the remaining 1 cent. In actuality, Andrew might pay $33.33, Parker pays $33.33, and Anthony pays $33.34.

We can express this as a function called split. You can think of this like integer division that automatically takes care of the remainder.

It's the next day now, and Andrew, Parker, and Anthony go out to lunch again. Once again, they spend $100 on lunch. Let's pretend Andrew decided to get an entire bowl of calamari for himself; Parker and Anthony aren't happy he didn't share. They no longer want to split the bill evenly. If Andrew's share of the bill was $70.00 then Parker and Anthony only owe $15 each, then we can express this with the allocate function. allocate is similar to split, the difference being that we can define our percentages.

While these examples seem straightforward, with arbitrary amounts of money, split and allocate can help prevent rounding errors resulting from division. Multiplication, on the other hand, often doesn't result in an even split.

Multiplication

In finance, we commonly have to multiply by percentages in situations such as taxes and interest. For example, our sales tax in San Francisco is 8%. How can we express this using integers? If we try to multiply our BigInt amount with a decimal number, we get an error.

If we only use numbers for multiplication, then JavaScript doesn't complain of a type mismatch. In this case, we end up with a tax amount of $7.9992.

When we think about percentages, there are actually two components we are dealing with. First is the multiplier, in our case, it is 8 since our tax is 8%. Then we have our scale which is the "percentage" or parts of 100, so our scale is 100. Both multiplier and scale are integers.

What are we supposed to do with 92 hundredths of a cent? In the real world, for sales tax, different countries, states, and counties can all implement different rounding methods in their local laws. For example, in San Francisco we currently round up to the nearest cent, but there have been proposals to round to the nearest nickel.

So we have to force ourselves to deal with that remainder!

With division and multiplication complete, we can continue building our library by adding helper functions such as sum.

Sum

When summing money, we can start with a simple reduce.

This works fine, but what if we are presented with an array of money with different currencies? Should we simply allow our add function to throw an error? We could convert all our money into the same currency but then we would be losing some currency data. That is one valid strategy; but let's think about real life again. If I handed you a bag of money with mixed currencies, in order to spend the money, you'd need to sort it into piles of cash of the same currency. When we bag sum, we compare currencies before adding so we can avoid mismatched currency errors.

Then, if we still want to, we can handle currency conversion on the resulting bags of money. Currency conversion is out of scope for this post, however it’s worth noting that some money is always lost during conversion due to rounding. When we bag sum before converting currencies we reduce the amount of error since we are only doing currency conversion on the resulting bag rather than the individual amounts in the bag.

We can reuse this strategy for other operations like finding mean, median or average. With these concepts, we can build the majority of mathematical expressions a developer might expect out of a money library.

Display

Of course, money is a real thing that people have to look at, whether that be your wallet, a checkbook, or online banking. Thankfully, the good people at the W3C have already thought about this and graciously gave us Intl.NumberFormat.

Wait what? We ended up getting $1,000.00, not what we expected! We should be seeing $10.00. Unfortunately, the good people at the W3C didn’t consider that we were making an integer-based Money library.

To get formatting to work properly, we have to first scale down our BigInt amount into its decimal string components. For US dollars, we would scale our money by a precision of two since we have two decimal places to represent cents. For other currencies like Japanese Yen, there is no precision since there is no concept of cents.1 Let’s update our currency type.

Then we can augment our format function with our new currency type, making sure to break down our integer into its real dollar and cent parts.

With formatting complete, we've covered most of the functionality needed to build on the web. From here, our library could take different shapes, so far, we've been writing examples using a functional pattern but we could also do class based chaining.

Whatever ergonomics you prefer, just keep in mind that money is real! You can use it to buy things, and it has physical properties in the form of nickels and quarters and stacks of hundred dollar bills.

That happened to me with Node.js AsyncLocalStorage. I remember reading a blog post about it a while back and thinking, “That sounds useful; I have absolutely no use case for it.” Months went by, and that assessment held true—AsyncLocalStorage was a neat tool with nothing to unlock.

Then DrizzleORM’s logging limitations finally gave me the excuse I’d been waiting for.

The Problem

At Numeric, we use Drizzle as our fully-typed Postgres query builder. I’ll save the deeper discussion of why we chose Drizzle and how we think about our tools for another post, but long story short, for our core technologies, we like tools that don’t abstract away the thing they’re wrapping. One of our core engineering values is taking pride in extremely deep knowledge of our tools, and we consider SQL to be among our most critical. Drizzle’s query builder creates queries that are immediately intelligible to anyone who writes SQL, which is exactly what we want.

But Drizzle is still an early, beta product. That comes with some blind spots. Custom query logging is one of them.

For every database query, we need a canonical log line that includes:

• A unique query key (for tracking specific queries across our codebase)

• Execution time in milliseconds

• The sanitized SQL query

• Argument count and the sanitized arg values

• Row count from the results

We’ve relied on these logs for years with our old Postgres client (slonik) for monitoring, optimization, and debugging in Datadog. When we switched to Drizzle, I needed to maintain that same logging capability.

Drizzle’s logging story is... minimal. They give you one logger override that exposes a single handler function. This handler gets called before execution and only gives you access to the query and arguments. That’s it. You can’t benchmark execution time because you never see when the query finishes. You can’t log row counts because you never see the results. And they document this under the “Goodies” section (oof).

The most upvoted solution in this GitHub issue involves JavaScript prototype manipulation to override node-postgres internals. Prototype hacks work until they break spectacularly, and you’re now coupled to library implementation details. Knowing how painful that failure mode is, I was happy to save myself the trouble and keep looking.

The Answer in the Attic: Async LocalStorage

AsyncLocalStorage is one of those Node.js features that sounds almost too good to be true. It lets you maintain coherent context data throughout an entire async call stack. If you come from React, think of it like useContext but for async operations. If you come from languages with threading, it’s the async equivalent of thread-local storage.

Under the hood, it works because Node.js tracks every async operation with an ID and maintains parent-child relationships between operations. When you call AsyncLocalStorage.run(), Node associates your context with that async ID. When you spawn child async operations, Node links them to their parents. Later, when you call getStore(), Node walks up this chain to find your context.

From the Node.js docs:

These classes are used to associate state and propagate it throughout callbacks and promise chains. They allow storing data throughout the lifetime of a web request or any other asynchronous duration.

Brilliant—this was exactly what we needed. We could create a context at the top of our database call stack, let Drizzle’s limited logger populate what it could access, and then complete the log line when we got back to the top with the full results.

The Solution

The implementation has three parts working together to produce complete, post-execution query logs using Drizzle and AsyncLocalStorage:

1. Set up AsyncLocalStorage to hold query context

First, create a context store that will hold query metadata throughout the async call stack:

The wrapQuery function creates a new context with initial data (query key and start time) and runs the provided function within that context. Anything called within fn can access or modify this context.

2. Use Drizzle’s logger to capture query details

Drizzle’s custom logger runs before query execution. We use it to push query details into the context we created:

Now when Drizzle executes a query and calls our logger, it automatically adds the SQL and parameters to whatever context is currently active.

3. Wrap query execution to complete the log

Finally, wrap Drizzle queries with the context and emit complete log lines:

The flow:

1. wrapQuery creates a context with the query key and start time.

2. Drizzle executes the query and calls our logger, which adds SQL and params to that context.

3. Back at the top, we grab the context to get all the pieces and emit a complete log line.

Everything flows through AsyncLocalStorage automatically. No manual context passing, no prototype manipulation, no hooks into library internals.

Conclusion

With this implementation, every database query now produces a complete, structured log line:

The AsyncLocalStorage approach also gives us type safety and no runtime overhead beyond what we’d already have with any logging solution. Most importantly, we didn’t have to touch JavaScript prototypes or mess with library internals.

The pattern shows up in more places than you’d think. OpenTelemetry uses AsyncLocalStorage for trace propagation. Sentry uses it to maintain error context across async boundaries. A bunch of logging libraries use it to attach request IDs to all logs within a request. Once you know the pattern exists, you start seeing it everywhere. Maybe this will be the blog post that you remember in years once you too have a reason for AsyncLocalStorage!

A company’s accounting department is responsible for the financial data set of the business. Accounting itself is the process of collecting, interpreting, and verifying an entity’s financial activity; it’s ultimately about translating the infinite unique complexities of businesses into a common language. This information not only prevents catastrophic mistakes and fraud, but also serves as a critical window into the business to support strategic decision-making around budgeting, investment, risk, and planning.

Software engineers have experience managing complex systems of data. The field evolved as a consequence of growing data volume and complexity—tools that we take for granted from the last 60 years like relational databases, version control, unit testing, cloud computing, observability, and more emerged out of necessity. As computers became ubiquitous, the volume of data and the demand for software exploded; engineering simply had to change to keep up. Practices evolved as well. Engineers now hold the correctness and consistency of application data as paramount. We treat bugs producing bad data as critical, and understand statefulness to be one of the foundational challenges of our work.

The practice of accounting has historically been comparably modest in its data volume and complexity. Consequently, it didn’t require the degree of evolution and sophistication around data that software development had. Over the last 25 years, however, the volume and complexity have ballooned, revealing the shortcomings of today’s tools and practices.

Accounting now faces a path for change similar to the one that software engineering took as the world digitized.

Abstraction, interfaces, and CRUD APIs

A first step in this journey is to move beyond the world of simple CRUD interfaces. To understand the evolution from basic practices to robust systems, consider the progression of a small software application into a mature product. If a bug caused a failed user sign-up, a developer of a small hobby project may find it perfectly natural to simply insert a user record to the database. He or she may not even need an endpoint—simply connecting to the database and executing a query could get the job done.

If the application grows, however, our developer will encounter challenges. A single operation can cascade multiple downstream effects, like updating various data stores, firing requests to 3rd-party services, sending emails, etc. This is when database transactions become essential to avoid writing bad data as the application scales. When multiple operations can trigger writes on the same tables, the difficulty of ensuring consistent behavior increases. And as more engineers join the team, observability and history become critical for debugging.

So at a small enough scale, it’s reasonable for a developer to connect to the database and fire off an ad-hoc query to insert the user record. But for an engineer at Facebook, the same behavior would be borderline insane. Who knows how many events and side effects occur when a user is created in Facebook? How many layers of validation, permissions, and logic have been skipped? Additionally, ad-hoc write queries create a nightmare for reproducibility and debugging down the line.

This direct insert query is a “CRUD” operation. The term is used to describe interfaces which contain very little logic between the inputs and the ultimate interaction with the database. CRUD is simple, imperative, and un-abstracted.

Complex applications require abstraction to unify and manage more nuanced needs and logic. In a mature system like Facebook’s application, few write operations would hit CRUD-like interfaces directly. Instead, we build and iterate on higher level abstractions to manage complexity in the face of a growing scope and size of system. This is what allows us to build progressively atop our systems while ensuring data consistency.

In short, our small application grows, and the viability of ad-hoc queries and scripts diminishes. So we must invest in a more structured approach by developing proper APIs and systems to support abstraction and to obviate the practice of directly manipulating the data.

Accounting has only CRUD

Accounting in enterprises today has reached this very inflection point. The ad-hoc tooling has stretched too far and it’s time for a better system. Day-to-day work is a painful game of constant catch-up because errors abound, testing is done after the fact, and a huge proportion of the work is reviewing and correcting for the mistakes and holes.

In spite of new scale and complexity, accounting gained little in the way of new tools over the last 25 years. In that time, the number of digitized sources, the volume and granularity of data, the expectations for liveness and richness of information, the complexity of accounting standards (especially post-2001 and post-2008), and the ubiquity of multi-national and multi-currency businesses have all come knocking at accounting’s door. The software which is expected to handle all of this complexity still looks suited to a world of manual data entry, yet the problems at hand more closely resemble modern data engineering challenges.

Much of the blame falls on the general ledger. It is the system of record—every sale, refund, purchase, loan, payroll run, and more must be reflected because your general ledger must be comprehensive. Yet despite being the essential system underlying accounting and finance, it offers only CRUD-like primitives. Its interface for mutation is to create, update, or delete (yes, delete) transactions which contain credits & debits that increase and decrease the various account balances.

This CRUD interface and the lack of higher-order primitives prevent the work from evolving.

Consider an example: a refund to a customer. Imagine we are a software company and our application has gone offline for multiple days, so we issue a refund for part of our customer’s contract. How do we account for this situation? The naive solution would be to directly reduce the amount of revenue we’ve earned in tandem with the reduction in funds. A simple “insert” operation introduces a transaction which reduces the revenue account (and our bank account accordingly).

Things get more complex, however, when you consider that the revenue may need to be reduced proportional to the various products that make up the customer’s overall contract in order to maintain visibility of revenue earned by product line. Additionally, the original records should have metadata to associate them to the source object from Salesforce—will the negating refund record share the same metadata? The refund might also be a credit against a future invoice rather than a direct cash transfer; did we associate the loss of revenue to the appropriate source? This business logic isn’t reproduced via the naive approach, and so the need for some higher level operation is evident.

The role of the spreadsheet

The state and logic to handle at least some of these complexities must nonetheless live somewhere, and that place is the spreadsheet. Excel is the only available tool for an accountant to define higher-level abstractions so it’s what they use, but it cannot offer the degree of robustness and abstraction necessary for accounting to apply nuanced logic consistently nor to support growing complexity reliably. The spreadsheets are the logical equivalent of a script containing CRUD-like database queries; they help to ameliorate the immediate situation but have a very low ceiling for progress.

In some cases, point solutions have emerged to take the place of the spreadsheet; these softwares help to address the logic required to manage a slice of your accounting. They nonetheless lack the robustness of an integrated system, meaning data integrity, traceability, and testability are lacking. They’re glorified spreadsheets, and call for the same level of double-checking and manual review as our ad-hoc spreadsheets require. In some ways, they exacerbate the problem by sprawling the number of systems to be managed.

Ultimately, accounting departments are left responsible for resolving the activities of the business into CRUD mutations of financial data. They’re quite good at it too; some accountants are downright experts in reasoning about their data and the impact of changes to the resulting financial reports. The cost, however, is immense. Hundreds of hours are spent on post-hoc review. Unsurprisingly, these ad-hoc behaviors produce a steady leak of errors and subtle gaps in the information. As a consequence, a great deal—even the majority—of the labor consists of checking and reconciling the outputs for correctness.

This isn’t how software engineers work. We assume manual work begets errors and bad data. We build our systems ahead of the data, testing and verifying behavior prior to deployment, and then allow the code to encapsulate logic and execute state updates. The other direction—modifying data and verifying it after the fact—would seem crazy to us today.

The transformation ahead

The office of the CFO is facing a transformation.

The field of accounting is losing people. The work to keep up is draining, even existentially so—I believe many accountants have a gnawing sense that the current approach is not scaling. Like engineers, they feel a great responsibility to do things right while also wishing to build for the future. But they’re only playing catch-up and falling behind. To break out of this situation means not only to reduce the pain for those involved but also to raise the bar for transparency, clarity, and strategy in companies.

By evolving towards a better system for abstraction and automation, we’ll open the floodgates for the field to advance. The relationship of accountants to financial data should shift, and a new role will emerge: an engineer for accounting. They’ll adopt a function similar to that of software developers with application databases. Instead of directly manipulating records, they’ll design, test, and execute the software system for financial data. This shift is what will unlock a new tier of execution, trust, and speed for business.

I remember one PR I made to fix a small bug – fewer than ten lines of code. I submitted it thinking it would be a quick review. Instead, I got a long, thoughtful review challenging if the fix addressed the reason the bug was created in the first place. The bug wasn't just a bad line of code, it was rooted in deeper assumptions about our data; the real solution meant addressing those, not just patching the symptom.

That was when I realized that good code isn't just about correctness. It's about clarity. It's about the future engineer who will come in with zero context and still need to understand, debug, and extend your work. This mindset has changed how I approach every line of code since.

That learning was one of many I took away while interning at Numeric, where I spent my summer helping build out our core platform infrastructure - everything from data pipeline optimization and API integrations to workflow automation and system monitoring. Here are ten lessons from the internship that changed how I think about engineering, startups, and life.

1. Conviction > Perfection
When you're new to a company or to a career, it's easy to default to listening. Just trying to absorb as much as you can and not get in the way.

But something our CTO, Bihl, told me early on really stuck: people want to follow conviction. A clear, directional opinion, even if imperfect, creates momentum. It gives the team something to respond to, iterate on, or rally around.

This pushed me to stop hedging and start forming stronger points of view. It's something I'm still working on but now I try to show up with an opinion. It's not always right, but it always moves the conversation forward. And that's the fastest way to grow.

2. Building with High Stakes
When you're dealing with core accounting infrastructure, the stakes are higher than typical product code. A bug doesn't just mean something looks off, it can mean data inconsistencies, failed integrations, or breaking critical customer workflows.

As a result, I adopted a much more defensive style of programming. I learned to think harder about edge cases, even the ones that 'should never happen.' It's better to hard-fail early and clearly than to silently continue in a broken state. So I started to think: What happens if this API call fails halfway through? What if this endpoint gets hit twice?

I remember working on our data synchronization flows and realizing how important idempotency was. One thing that we simply could not afford to do was duplicate or corrupt customer data. Whether it was a network issue or a system failure, we had to design around that, tracking every operation and ensuring the system behaved correctly no matter how many times it was triggered. With this, I learned to build systems that anticipate mistakes before they happen.

3. Prioritization is Hard
Once we launched new platform features, feedback came flooding in. Suddenly there were endless feature requests and support tickets:

• Can I customize this workflow?

• Why isn't this data syncing properly?

• Can I get better visibility into this process?

As someone who was just a few weeks into my internship, figuring out where to start was hard. I learned to group issues into buckets. What's blocking customers right now? What can we work around for the moment? What's a nice-to-have vs. a need-to-have?It's something I'm still learning. But the key was that not everything that seemed urgent was actually a priority. Learning that distinction is the difference between shipping what matters and drowning in distractions.

4. Testing is a Lifesaver
On my first day, I was handed a set of failing tests as my first venture into the codebase. I was confused - how would writing tests help me onboard or even benefit anyone? They just seemed tedious.

Looking back, I realize how powerful testing really is. When you're joining a new project, seeing exactly what the desired behavior is for each event helps you understand what each part of the system is responsible for.

And testing isn't just an onboarding tool. They're also a safety net for the future. When we refactored our data processing pipeline, failing tests pointed us exactly to the areas of code that needed attention. The same thing happened when I was working on getting our system to support new integration patterns. The tests gave me a clear starting point for rolling out the changes and understanding their impact on existing codepaths we knew we needed to support. Once we had passing tests, I felt much more confident in our ability to ship this code to production without breaking existing workflows.

5. Start with the Hardest Thing First
De-risking early sounds obvious, until you're looking right at the messiest, least defined part of the project. It's tempting to push that to later, in hopes that it'll somehow become more clear down the line.

But the hardest part with the most uncertainty is usually where the real complexity lies. For my platform work, it was the core data transformation logic. That came first, then the external integrations, and finally the more predictable parts like monitoring and alerting.

Starting with the hardest things meant fewer surprises, and more confidence in everything that followed.

6. Narrative Matters
One thing I didn't expect to learn as an engineer: storytelling. At Numeric, the best leaders didn't just do good work or build good systems, but they also told the story behind the work.

Whether it was a spec, a demo, or a company update, they started with the bigger picture:

• What problem are we solving?

• What's been tried before?

• What does this change for the rest of the company?

That kind of framing makes decisions easier to follow, feedback more grounded, and discussions more productive. I got to put this into practice by leading demos of features I built to our entire company, even those with little to no context of what I'd been working on. By contextualizing with our current processes and highlighting the clear problems being solved, it made the results more tangible to everyone. Storytelling is not just a skill for GTM, it's a core engineering (and even life) skill.

7. Talk to Everyone
I made it a goal to talk to as many people across the company as I could, and those conversations became some of the moments I learned most in:

• A session with Albert walking through a Gong sales call together and dissecting the dynamics of the conversation

• A chat with Ben Baker about how understanding yourself well allows you to motivate others more effectively

• And my favorite - when I asked Eli if I could shadow a customer onboarding, which somehow turned into me leading one (and going to a customer onsite!)

Being in the driver's seat with a real customer taught me how to think on my feet, communicate clearly, and focus on what actually matters to the user.This reminded me that some of the most valuable learning happens in simple conversation. Ask questions. Be curious. The people doing the actual work are the best teachers, and all you have to do is start the conversation.

8. Timing is Important
I joined Numeric at a rare moment — right as the company was starting to scale. In just a few months, we went from a handful of engineers to growing so quickly we started to split into pods working on different areas of the product. The sales process was becoming more standardized. A brand new product team took shape. Processes that didn't exist when I started became essential.

Being in the middle of that kind of change taught me how timing shapes the problems you work on. In the early days, everyone touches everything, and when you scale, you have to start building systems and processes that help people focus on where they're most effective. I was lucky to experience that shift firsthand.

9. Leadership Sets the Tone
One thing that stood out at Numeric wasn't just how talented people were, but how much trust they had in each other. People owned their domains and made decisions confidently.

Leadership set a tone of clarity, speed, and empowerment. That kind of trust-based culture changes how you work. It pushes you to take ownership, move fast, and level up quickly.

This summer, when I was told I'd be working on our core accounting infrastructure, I felt both trusted and challenged. That trust was motivating.

10. San Francisco is the Place to Be
I've been here for 13 weeks, and it's hard to imagine a better place to be for this kind of learning and energy.

A few highlights outside of work that wouldn't have been possible anywhere else:

• Rode in a self-driving car

• Ran the SF 10K (with no running experience before the summer)

• Met so many inspiring people, including Joe Lonsdale (co-founder of Palantir, 8VC)

There's a magic to being in a place where everyone's building.
This summer taught me more than I could have imagined: not just about code or systems, but about learning, ownership, and building for the future.

Huge thanks to Bihl, Owen, Ben, and the entire team at Numeric for making it an incredible experience.

We'll walk through our development philosophies concerning the why and the when to integration test, briefly discuss where we write them, and present the method of how to integration test that we've developed. We'll wrap up with a conversation on key considerations that must be kept in mind when following our testing methodology, and a deeper presentation of the test fixture we've developed for integration testing Postgres systems. It's all powered by the the embeddable Postgres implementation PGLite; these experiments have been a great way to learn and interact with the tool, and we're impressed!

Why

We consider a rich automated testing suite a key component of our efforts to build developer confidence. With increased confidence, we can attain greater speed, free of any hesitation to kick off a scary deploy. Engineers should feel empowered to merge code, fire off a deploy, and move on to the next PR. Good automated tests also provide us increased confidence in code quality; they codify what expectations we have for our software's behavior, guarding us from regressions and adding additional layers of validation for new feature releases.

Integration tests are one pillar of such a confidence-boosting test suite. For our purposes, they are differentiated from unit tests in that they aim to verify the correctness of full systems, rather than isolated functions or components. In particular, they test systems in which multiple components interact to produce results. Complexity explodes at these points of interaction, so one hundred percent verification is not the goal. Instead, through a solid set of integration tests, we aim for coverage of the invariants we expect to always hold.

No presentation of integration tests is complete, of course, without consideration of the canonical aches, fears, and worries their mention can trigger in a seasoned engineer. Because of their very nature, they can be difficult to write, expensive to operate, slow to run, hard to maintain, and prone to flakiness and test pollution. We hope that the demonstration that follows will show that this state of operation is not a fait accompli; it's very, very possible to introduce integration testing into a codebase without incurring these pains.

When

Our canonical target for integration test coverage is a data in/data out system, which you could argue, is every computing system… anyway, many times this is a REST API: the data in (HTTP request) triggers some operation (application logic) that produces data out (data in a database, data in the response, etc). To produce the data, the API may interact with multiple components: data stores, cache clients, data transformers, domain calculations, etc. Even more of a clear match, data ETL or ELT processes pull data from some source store and dump it into some destination.

So, when we decide whether to integration test, we look at our code and ask ourselves: What is the data in? What is the data out? Once identified, you can probably integration test. With the right fixtures in place for preparing the data in and inspecting the data out, of course.

Where

We write our integration tests like any other vitest script. We place tests in a file entitled <component>.integration.test.ts, where component is the target system under test; for example, accounts-data-transform.integration.test.ts would hold integration tests for some accounts-data-transform system. It should live next to the entrypoint of the system under test.

CI runs are triggered on PRs, where integration tests and unit tests execute in parallel via separate vitest workspaces. This allows us to isolate the generally quicker unit tests from the generally slower integration tests.

How

So we've created an integration test file for our target system. Nice. What now?

We have the plumbing set up today to support integration testing anything that writes result data to Postgres, the main database in our tech stack. Systems that return data via API responses should also theoretically be integration testable, but we haven't yet written those. So, we'll walk through the first scenario, and leave writing an integration test for the latter as an exercise for the reader.

Our goal is to verify the correctness of a simple ETL pipeline that pulls data about ticket sales at the world's finest, fictitious sporting venue, the Dimmsdale Dimmadome , from the equally fictitious "DimmaAPI" (special thanks to Doug Dimmadome for access to this incredibly useful dataset). Once data is extracted, the pipeline applies some calculations on it, and ultimately dumps the results into tables in our internal Postgres database.

We test such Postgres sink systems following a simple pattern: mock data with in memory providers (also known as fakes) and an in memory DB client, run the system under test, then verify what data was written out via the same in memory DB client. In detail:

1. Source data is provided through the creation of in memory data providers. Naturally, this requires some foresight at the start of development (or after the fact with some refactoring) to separate the source of data from the code that acts on the data. We put that source behind an interface that can then be plugged and played with different implementations. This is generally a good design pattern to follow, so it's worth promoting beyond the benefits of integration testing.[1]

2. The in memory providers should expose an easy way to configure the test data to input into the system, and a way for state to be reset between tests. For example, consider this DimmadomeInMemoryDataProvider. It implements a IDimmadomeDataProvider interface. The interface abstracts away where the data comes from. In the real system, we have an implementation that pulls data from the Dimmadome Data API. Let's define the in memory provider and instantiate an instance to use in our test:

3. Source data may also come from Postgres itself as a target. We thus introduce the pièce de résistance of our integration testing capabilities: a PGLite powered in memory db client. PGLite is an embeddable Postgres client. It's lightweight enough to instantiate/tear down quickly, which helps mitigate many of the historic pains of writing and maintaining integration tests. For one, we aren't reliant on spinning up a separate, heavier Postgres process. And because we can afford to reinstantiate new PGLite instances between test runs, we eliminate the potential for difficult-to-debug failures due to data pollution between tests. For our purposes, we've built a testing client using it that is compatible for use with Slonik, our Postgres query library of choice. Our test client exposes methods to execute queries. We use these to configure initial tables and data for use by systems under test. Our Dimmadome ETL depends on some metadata tables, so let's create our test client and get those configured.

4. Once test data sources have been set up, we can execute our target system. It should perform its magic and ultimately conclude with data written into the in memory test client.

5. Now we can use the client to inspect the data written. How? Through good old SQL queries. Additionally, the client provides assertion methods that we use to inspect what queries were executed. This is useful for asserting things like "when we see data matching situation X, we should NOT run a query to do Y". We've already asserted that our ETL process returns a success response. Let's run some more assertions to verify it wrote the data we expect.

6. That's it! We've successfully written an integration test that confirms a particular configuration of data into the system results in data out of it as we expect.

Here's our final test in full.

To what extent

Now that we've walked through an example of integration testing in action, it's worth taking a moment to consider a delicate balancing act our procedure asks of test writers: to what extent should your in memory providers emulate the behaviors of the real data APIs used in the production system under test? In other words, how complex should their implementations be?

Writing in memory providers for use in mocking involves… writing code. And as is the case with any code, the more of it that exists, the greater the surface area is for bugs and disaster. Ideally, the in memory providers require little code, and what code is written is straightforward CS101 stuff. This was the case for mocking the DimmaAPI. But this may not always be the case. There are rougher paths that one might be led down, asking you to mirror more complex data operations or logic. Consider some source data API that exposes a findKMeansNearestNeighbors endpoint. At face value, it seems that it asks us to fully implement k-means clustering in our in memory provider to match its behavior. If we do follow that path, then what are we testing? We want to say the system as it actually exists, but past a threshold of sufficient complexity, the mocking code itself is what's under test.

As the test writer, it is your responsibility to consider the complexity of your in-memory providers – of your mocking utilities – and to find alternatives when possible to keep it contained. With the findKMeansNearestNeighbors example, do we need to provide the real k nearest? For many tasks downstream of it, we probably care about what is done with the results pulled from the data source, not the nature of the results themselves. For example, if the data source declares records X, Y, and Z the three closest neighbors of record A, do the downstream processes treat them as such? Viewed from this lens, we arrive at a straightforward implementation of findKMeansNearestNeighbors… simply return any three arbitrary (but deterministic!) records. Fin.

These considerations are more art than science. And are heavily context-dependent. Ergo, the balancing act.

It's also worth considering why we implement these in memory providers rather than using more traditional mocking libraries or frameworks. Our dominant motivation is to avoid complexity –another reason why the balancing act we discussed is so important! In our experience, mocking frameworks carry footguns that can make test code hard to understand. We consider this the classic "with great power comes great responsibility" issue. Full-fledged mocking frameworks offer a plethora of powerful tools for testing. Spys! Mocks! Stubs! We've found, though, that our tests are simpler with directly written in memory providers that provide exactly what you need, nothing more. As a bonus, they can be extended with custom assertion or verification utilities directly tailored for your use case in similar ways to the assertion methods we demonstrated on the PGLite test client.

The client in detail

We'll now present some of the inner workings of the test client; namely, its constructor (which initializes the PGLite in memory database), internal data structures for tracking executed queries, and its query interface.

All of the heavy lifting of executing queries is passed on to PGLite. The test client serves as a simple wrapper that adds in the special sauce of tracking what queries have been executed. This is what allows us to provide richer assertion functionality beyond just inspection of table content. For now, these queries are normalized (whitespace stripped) and stored as strings in the query log. We have plans to more richly parse queries into ASTs, which can be interrogated with more complex questions like "did an update statement execute against table X settings column A to value W?"

Conclusion

We've benefited tremendously from this method of integration testing, in no small part due to the low barrier of entry to writing and executing them. There's no dependency on Postgres running in your local environment or in some container in our CI environment. It's all in memory. The tests are easy to write, cheap to run, cheap to reset. Which contrasts beautifully with the canonical worries surrounding integration testing we presented at the start of this article. With positive experiences under our belts, we at Numeric welcome the new era of in-memory, embedded Postgres.

---

[1]: We generally consider it nice to think of any data manipulating code in this way, for the benefit of readability and, especially, for testing. Separate the work of getting data from the work of actioning on the data to promote testability. This also produces code that adheres to the pure functions style standard.

…if you ask what the team needs, they may say more accountants. At Numeric, we’d say they need a proper data platform.

Why work on accounting? It’s a common question—one that we get all the time. We’ve built a product-centric company with a strong engineering culture, and accounting is not typically thought of as a domain which attracts top minds for solving problems in software. Yet we remain laser-focused on accounting.

In speaking with other engineers, an important part of explaining what we do is setting the baseline for what the state of play is today: the work of accounting is substantially, frustratingly, unsolved and manual even though every company has to do it. What you might assume is fully automated often isn’t. Here's a simple example:

A software company “Todo List Apps, Inc.” signs a 2 year contract in January with AWS for $240k worth of reserved EC2 instance capacity. It’s a win-win: TLA saves 40% on their compute costs, and AWS gets the full cash amount paid upfront.

From an accounting standpoint, it would be wrong to say “we burned a great deal of money in January but now we’re profitable”. The goal is to approximate the profit function of the business, and to be able to answer: if I put a dollar into this business, will more than a dollar come out? So we must normalize for time. In the case of this expense we’ve paid upfront for, the logic is fairly simple. Instead of saying we spent $240k in January, we consider that we’ve converted one asset (cash) into another asset (a pile of service owed to us). We then “spend” this asset evenly over the course of 2 years, using about $10k worth of EC2 credits a month.

The actual math here is dead simple: take an amount, and spread it out evenly over the length of the contract. There are corners, sure, but addressing things like partial start/end months or a leap year are fairly everyday problems in programming. In spite of this, automation plays only a small role in the way companies of all sizes solve this today (spoiler: with manual work and Excel). Here’s what it looks like.

At month-end, Angela on the accounting team has a task to search their accounting software for large expenses from the month to see if any look like they are not one-off expenses. Until treated otherwise, the system will assume they are. When she finds one for $240k, she knows it’s likely a contract for a year or more, not just for January. She logs into a tool like Bill.com, or Ramp, or Brex, or Zip, or otherwise to find the original contract. She downloads the PDF.

She opens up the Prepaid Software Expenses Excel file that her team shares and keys in the details of the contract to one tab—the vendor, the start of the service, the end, the total amount, the department that incurred the expense, and more. Then, there is another tab to project the change in the asset’s value over time. That tab contains a formula that looks something like this:

This formula drives the math for how they amortize, producing the change in each prepaid software contract per month. It will have hundreds or thousands of contracts represented (both present and past).

She notices the row hasn’t been picked up and realizes she needs to click and drag a cell down one row to get it to include the newest row in the calculations. Once she’s done that, she goes to the “Export” tab which adds up all the deltas across every contract to produce a single number for the month: $117,320.29, representing the total usage of paid-upfront software services at the company. Later, once all such contracts have been entered, she’ll export the CSV to then import into their accounting software (e.g. Quickbooks or NetSuite). This simplified, aggregate number represents the ending result of this process. If something new comes in, she’ll delete the transaction, fetch the contract, update the spreadsheet, check the amortization, and upload a new CSV with the latest total. And if there is an error, it’s likely to burn days of her time as she hunts down the cause through the gargantuan file.

In the absence of a better system, these types of Excel files serve in place of a full software stack. In this instance, the file is the database for this contract’s structured data. It serves as the business logic and handles transformation of the values. It serves as an integration, producing a CSV for export. Teams will have various methods for version control of the file and some light checks for correctness. Unfortunately, this creates immense manual work and innumerable errors due to subtle mistakes, lack of tests, denormalized data, and out-of-sync state.

This tedium is not just performed for prepaid software. Next, Angela will move on to the file titled “Lease Schedules”, which contains the upfront paid asset representing their right to their office spaces, and the amortization math to use the space over the length of the lease. Physical assets, like their employee laptops, will also depreciate in a remarkably predictable fashion, yet those spreadsheets will require a manual export each month as well. Their revenue may look similar—just imagine the EC2 scenario from AWS’s point of view. If they have loans with banks, what they really have is a lump sum obligation and a very predictable schedule on which it will be amortized to zero. And so on and so forth.

Toward the end of all this, error checks and cross-referencing are done by the team to spot mistakes and missing information. When transactions are erroneous or incomplete, the cost to address the issues will heavily depend on how quickly (Days? Weeks? Months? Years?) they identified it. Meanwhile, the CFO, the CTO, the finance team, budget holders, and possibly investors are awaiting the results because the output of this careful dance is the financial data of the business. There are decisions, adjustments, and insights to be gleaned from this data.

This is a universal, though hardly comprehensive, story about how accounting is done in companies big and small. Manual work is immense, and accountants spend the majority of their working lives collecting information, moving data, running calculations, and uploading CSVs. Spreadsheets power this world. It’s a lot of data work, and the accounting role can be a draining job in a constant state of catch-up—most acutely observed during the month-end close.

If you ask the team, they may say their hardest problem is hiring—the field of accounting, after all, is not growing. In fact, the talent pool hasn’t kept pace while challenges have mounted. As the volume of data, the number of systems of information, and the scale of the business increase, things inevitably become more complex. Part of this growing pain is due to the explosion of data and systems since the turn of the millennium (which their accounting software predates), and another part stems from the expansion of regulations like Sarbanes-Oxley (2002) and the Accounting Standards Codification (2008), both created in response to catastrophic fraud and error. The job for many accountants is unrewarding and the field can be a difficult one to enter, leading to the state of under-supply today.

So if you ask what the team needs, they may say more accountants. At Numeric, we’d say they need a proper data platform.

Our direction as a company has been heavily informed by a few strong beliefs. First, when you have manual, repeated work, errors are inevitably entering the system and creating bad data. Second, if you have a data problem, it’s usually a bad idea to try and patch said problem downstream. Such issues proliferate in a way that can be exponentially painful, and building on top of bad data leads to predictable outcomes. If you can fix it at the source, you should. Third, accounting is sitting on a massive data problem and the situation cries out for good engineering and product.

We believe the future of accounting is one in which we’ve been able to effectively lift everyone’s role one or two layers of abstraction up from where it is today. The integration, movement, and matching of data should be done by computers. The math, projection, data pipelining, simple analysis, and error detection should be done by computers. Even the interpretation of the events, and the first take on the correct accounting treatment of things can now be done with computers. The current state is one in which the team building and owning the dataset—the accounting department—is so busy and undersupported that they are always playing catch-up. Meanwhile, leadership and decision-makers only gain access to a fairly shallow data set, limited in its usefulness because its accuracy is questionable, its depth is limited, and the tools available to use it are disappointing.

By freeing people from moving data, manually error checking, spot-testing Excel files, and more, we can raise the ceiling for how good outcomes can be. Getting the information and producing trustworthy accounting books should be just the first step toward an overall operation that uses the financial data of the business to drive strategy. These problems are holding back companies at large. They make life hell for accountants. And they are solvable. That’s why we’re building Numeric.

Why Runtime Type Checking Matters in TypeScript

TypeScript’s static type system is effective, but runtime validation remains necessary when dealing with external data sources. Without runtime checks, compile-time types for external data are meaningless. They create a false sense of security that lets subtle data inconsistencies spread through your system.

What is Zod?

Zod is a TypeScript-first validation library that ensures runtime data matches expected types. Developers define schemas that describe the expected structure and constraints of data, and Zod then validates inputs against those schemas. It also eliminates redundant type declarations by inferring static TypeScript types directly from the schemas.

Beyond type checking, Zod offers features such as:

• Transforms: Modify data while validating it

• Pipes: Chain multiple validation steps

• Coercion: Convert values (e.g., strings to numbers) during validation

While these features enhance developer experience, they introduce performance overhead and require a validation approach that can impact scalability.

Our primary use cases for Zod include:

• Validating database query responses

• Enforcing API contracts between frontend and backend

• Verifying data from third-party integrations

Given these use cases, our goal was to enforce strict type checking with minimal processing overhead. We sought surgical optimizations to improve performance while maintaining Zod’s API for an easy migration path.

The Bottleneck: Overhead from Deep Copying

By default, Zod validates data immutably—it returns a new object instead of mutating inputs. While this aligns with functional programming principles, it introduces significant overhead when processing large datasets.

Symptoms

In one real-world scenario, parsing 500,000 account objects took around 2 seconds using standard Zod validation. The performance overhead caused noticeable event loop delays and, in some cases, server OOM crashes due to excessive memory allocations (as well as overly nested promises when using async function variants).

A visualization of Zod parsing taking the majority of the CPU time it takes to run queries against our databases.

For the sake of reproducibility, here’s a simplified version of one of the schemas we benchmarked. We’ll use this naive benchmark of the time to parse an array of 500,000 account objects as a proxy for general library performance and improvements; it’s simple and easy to reproduce with some fake data. However, during experimentation and implementation, we augmented this with other benchmarks based on our production usage, as well as more default profiling.

The situation became dire enough that we introduced a configuration flag to disable type checking for certain high-throughput workloads—a clear signal that something needed fixing.

The Optimization: Bye-Bye, Deep Copies

We modified Zod’s validation logic to return the original object when validation succeeds, instead of creating a deep copy. This drastically cut down CPU and memory usage.

To enable this optimization, we had to remove features that rely on returning a new object, including:

• catch

• coerce

• default

• intersection/and (in favor of merge)

• pipe

• preprocess

• transform

For many users of the library, these are core features, which is why Zod itself can’t support something like this with minimal changes. But for us, our system already separates transformation logic from validation, so removing these features was a reasonable trade-off.

Zod’s internal functionality must be understood to understand why this optimization can be implemented in an elegant and contained manner. At its core, Zod’s validation logic is really just casting any to stronger types, with a bunch of checking along the way. The logic is illustrated in this simplified example:

As long as the validation function ensures type correctness of the input object, there’s no strict need to return a cloned object. Eliminating deep copying doesn’t change how TypeScript will enforce the types of the returned value downstream.

(Clever readers may interject here that a proper in-place validation function should probably be using the asserts operator. While relying on type narrowing via asserts would be great, the implementation would require much deeper changes in Zod’s plumbing. We’re hoping to see something like this strategy come out in Zod 4, perhaps!)

Implementation Details: Optimizing _parse

Our optimization focused on ZodObject#_parse, the function responsible for validating and processing objects against schemas.

Key Changes:

The macro-optimization here is validating data in place and then returning the input object itself if validation passes. This gives us around a 1.5x speed boost. Getting it up to the titular 2x required a few more micro-optimizations such as:

• Use direct key lookups instead of iterating through properties, reducing CPU cycles.

• Handle excess properties efficiently, stripping or reporting unknown keys without redundant processing.

With these changes, we saw a 2x validation speed improvement across our benchmarks. Check out the forked source code on Github.

Trade-offs

This approach allows us a fairly surgical implementation (besides the removal of some features en masse). However, this comes with a good number of trade-offs that may only make sense for our specific use cases. Otherwise, we would have just PR’d to the main repository 🙂.

• Directly modifying input data in strip mode: extra keys are removed in place rather than on a cloned object. This is probably the biggest footgun introduced here. Optimally, we’d default to passthrough mode rather than strip to match Typescript’s default behavior (without excess property checking), but changing such a default would be a much more in-depth and dangerous change.

• The input data itself is not type-checked: the returned value must be reassigned to enforce strict typing. Ideally, TypeScript’s asserts operator would be used, but that, too, would require more intrusive changes. This trade-off is not too bad, given it matches Zod’s own API. As an aside, a piece of essential reading for this subject matter is Alexis King’s article “Parse, don’t validate”.

• ZodIntersection behavior changes: previously, intersection validated both schemas and merged results. With deep copying removed leading to the above strip behavior, intersection can lead to unexpected key deletions. Rather than get too clever here, we instead fully removed intersection with the recommendation to use ZodObject#merge. For our use cases of only ever intersecting object types, the minutiae lost in the differences between merge and intersection are insignificant.

A massive kudos goes to Zod’s comprehensive test suite; with it, we caught and addressed these edge cases early in our implementation.

Rolling Out to Production

We tested our fork extensively using internal benchmarks on production servers. The results confirmed a 2x validation speed improvement on large datasets.

Migration was straightforward—since our fork is a strict subset of Zod’s API, the primary change involved replacing our few remaining .transform() calls with a separate transformation step. Other validations continued to work as expected, with dramatically improved performance.

Looking Forward: Exploring ArkType

While Zod has served us well, we’re extremely excited about ArkType, a newer validation library leveraging JIT compilation. Based on the type definition, ArkType creates a function using the new Function(...) syntax that avoids a lot of the overhead from the deep recursive call stack that belabors libraries like Zod. ArkType consistently outperforms Zod—even our optimized fork—by a wide margin. The base Zod library benchmarked at around 40x slower than ArkType on the same set of 500K accounts, and our optimizations brought it down to 20x. ArkType remains the clear winner on speed and memory usage.

Given these numbers, why haven’t we switched yet?

1. Stability: Zod is battle-tested and well-supported. ArkType, while promising, is still maturing.

2. Developer Experience: We love the Zod API and have found ArkType’s ergonomics lacking in some areas.

3. Clear Use Cases: We adopt new tools when the need is clear and the benefits outweigh the migration effort. ArkType shows promise, but we need further validation before committing.

For now, our optimized Zod fork meets our production needs, but we’re actively testing ArkType for R&D projects.

Final Thoughts

In the JavaScript ecosystem, it’s almost too normalized to use a package for everything. This experience reinforced an important engineering principle: general-purpose tools don’t always scale perfectly for specific workloads.

Zod is an excellent validation library, especially for form inputs or simple API contracts, but its default immutability strategy can be a performance bottleneck in high-throughput applications. When we found ourselves working around these constraints, we took a deeper look and modified the tool to fit our needs. By eliminating redundant object allocations, we doubled validation speed while preserving most of Zod’s stability.

Our Engineering Philosophy

We believe in the ability to peer into abstractions and modify them when necessary. Libraries should serve our needs—not the other way around. By understanding and optimizing Zod, we unlocked significant gains without sacrificing maintainability.

If you’re running into similar performance issues, take a step back. Rather than blindly accepting defaults, challenge abstractions and consider whether they serve your requirements.

Most anyone understands the benefits to a successful onboarding: you get a chance to lay the groundwork for long-term success by building strong relationships with your team and gaining a holistic understanding of your new company's systems and culture. That said, for many engineers, onboarding is synonymous with frustration. The pains are numerous – setting up a new dev environment, setting up multiple new accounts, etc; even pushing a simple pull request can consume many annoying hours.

Add to that the fact that many companies measure early success by how quickly you can ship code, you may be tempted to skip essential foundational learning for rapid output. In my view, that approach is short-sighted.

An onboarding period is a terrible thing to waste: the first fateful domino in your tenure at a company. As such, I’ve outlined a set of principles and practical tips for the optimal ramp-up. With the right mindset and preparation, you can establish a solid foundation for long-term impact.

The principles

The larger the company (and codebase), the longer it will take you to be effective in writing code.

While this might seem obvious, it’s rarely acknowledged. New engineers often feel pressured—by themselves or their colleagues—to match the speed of their previous roles within days or weeks. However, the simple truth is that larger codebases require more time for one to build the institutional knowledge necessary for effective development.

Optimize for building context

With principle 1 in mind, one should optimize for building context – this is typically pretty hard since many company’s incentives serve as reward to those who churn out code, and one’s early success often is defined (incorrectly in my opinion) by how quickly you can start producing code. If you find this to be the case, talk with your manager about wanting to prioritize learning/building context; you can even map out the things you plan to learn to demonstrate that you are productively spending your time even if you aren’t producing code quickly. While this proactiveness will pay massive dividends in the long run, it can be seen as counterintuitive early on because you may feel pressured to provide value as quickly as possible.

You still can have massive impact from day 1

The first two principles might seem to imply that you cannot provide value to your company early on - after all, if you can’t develop effectively within your first weeks/months as an engineer at a new job, then what value can you provide? As it turns out, there's plenty:

• Take notes on what went well during onboarding and what can be improved Use this to improve the onboarding process for future engineers. This is arguably the highest leverage activity you can do within your first 2 months at a new company.

• Improve or create new documentation
  The more institutional knowledge an organization can take from the minds of engineers and put into concise documentation, the better the organization will operate over time. Improving the company’s documentation will not only help new engineers onboard, but also assist in ongoing knowledge transfers, etc. Onboarding is often the best time to improve documentation before you are mired with the demands of the work of a fully ramped engineer.

• Share what worked well from your last job
  Were there any tools/processes/systems in place at your old company that could augment what your new company is doing?

• Leverage your fresh perspective
  One of the most valuable resources for any tech company is the fresh set of eyes that come with every new engineering hire - you aren’t saddled with the assumptions/biases that are inevitably present in everyone currently working at the company. To that end, you provide a perspective that can potentially help drive the company towards the optimal solution for its current problems. Don't assume that your perspectives are automatically novel and that no one else has considered what you're seeing. At the very least however, questioning everything will help accelerate your learning.

By taking these principles into consideration as you onboard, you stand to provide immense value to the company up-front which will afford you ample time to build context and learn your codebase/stack.

With these principles in mind, here are some practical tips that will help you accelerate your time-to-productivity as an engineer:

Practical tips

Use the product as much as possible

While this point may seem obvious, it is by far the most overlooked part of the engineering onboarding process. No matter where you operate on the stack, developing an understanding of the product that you are building from the perspective of the user will help you be more effective as an engineer. Adopting this POV is especially critical with B2B products that you may not use day-to-day. Using the product will help you understand how the codebase works at a system level, for understanding how each code module maps to the product is critical to understanding why that code exists.

Pair Program

Pair programming enables engineers to share best practices, improves the odds of reaching the optimal implementation, and helps create code that is more consistent and readable. Pair with every engineer on your team: first, by asking them to shadow you as you implement your first set of tasks and secondly, by shadowing them as a means to learn about the codebase and the set of coding practices your team/company follows.

Shadow on-call engineers

Taking the spirit of pair programming a step further, consider shadowing your on-call engineer as they debug issues or to chat at the end of their shift to go over the most interesting problems they solved. This understudy will help in the following ways:

1. You learn about all the internal tools used by your team

2. You gain additional understanding of the data models in your team’s domain

3. You gain insight into how the customer-facing product maps to the code base

4. You gain perspective on the code-base from a systems perspective, as many bugs often span multiple layers of the stack or multiple services

5. You develop better relations with everyone you shadow

Follow requests along the full stack

Whether you are a front-end, back-end, or full-stack engineer, you should follow a request from the client along the entire stack. Doing so will help you understand the overall system design, which in turn will help you navigate the codebase faster. When tracing through the stack, ask yourself the following:

• What is the purpose of this layer, and why does it exist? Does it handle auth, validation, serialization, DB reads/writes, etc?

• Who owns each layer?

• Are there code patterns unique to each layer?

• Where is each layer found in the directory structure?

• Are there naming conventions to each layer that will help you find new modules/code in the future?

In following requests along the full stack, use this time as a chance to get familiar with your IDE’s debugger if you haven't already. Additionally, try using Cursor—our go-to internal IDE—which is helpful at answering questions about your codebase.

Ask an engineer to walk you through the data models

There are several important sets of knowledge that cannot be discovered through reading code and must be absorbed via talking to someone with historical context of the codebase:

• How has the database schema changed over time? Having this set of knowledge gives more context as to why the database exists as it does today

• What were the trade-offs made in picking the current db schema? For example, for tracking updates made to table foo, why was a separate foo_updates table made instead of directly updating the foo table itself?

• What are the current faults in the current database-schema? If given more time, would the team like to perform any migrations?

Ask why major engineering decision were made

In general, it is rarely enough for a new engineer to just read the company codebase to learn about the system. How so? Because engineering is always about tradeoffs. The current state of the codebase is always a function of how the set of product requirements changed over time, how the engineering team adapted the system to these requirements, and how much time was available for making these changes (a team often foregoes implementing the optimal solution due to time constraints).

Asking experienced engineers about the trade-offs they considered when developing the current system helps you understand why the system is the way it is today; more importantly, those conversations give you insight into where improvements can be made going forward. It also helps you understand how the product itself has evolved overtime as client needs have changed/evolved.

Dedicate time to understanding the dev tooling

By the end of your first month, you should be intimately familiar with your entire tool stack, across alerting/observability (eg. Datadog), user session tracking (ie. Fullstory), analytics (ie. Segments), internal tooling (ie. Retool), database IDE (ie. Datagrip), IDE (if a new one is mandated by the company), etc.

Optimize for breadth over depth by touching as much of the stack as possible

Following principle 2 (optimize for context), in your first few months at a new company, you should try to work on many small tickets that touch as much of your team’s domain as possible. This work will be a forcing function for optimized learning over raw output. Of course, this may not align pragmatically with your team’s roadmap, or there may not be tickets that touch all parts of your team’s code. If so, I recommend telling your manager that this is a priority of yours and ask if they are willing to help optimize for breadth initially.

After you have closed out a few smaller tasks, I recommend asking your manager to help you find a project that touches multiple layers/services/domains that your team owns. Working on a project of this kind will help you to build a more cohesive understanding of the codebase from a systems perspective, as the project will illuminate how different parts of the codebase interact in practice.

Shadow Calls with the Customer

Reach out to CX/Sales/Product – whoever directly interacts with the customer – and ask if you can shadow several calls with them. Doing so will help you build empathy for the customer you are serving and help you understand the customer’s main pain points.

Meet as many people as possible

When joining a new company, aim to build relationships. That goes as advice in and of itself, but also will serve you well in advance of needing to ask people for PR reviews, meeting time, or help. I recommend figuring out which teams are adjacent to yours (both engineering and otherwise), and meeting everyone 1-on-1 within your first month at the company. While that might sound exhausting, especially for the introverts among us , you will begin to build meaningful relationships at the company that will in turn make your work more enjoyable. And as a helpful aside, people are always more willing to help those they already have met personally.

More tactically, ask about the objectives of their role, how they collaborate with other teams, the challenges they face, and any advice they have for navigating the company. This insight will help you understand your place within the broader organization and may even highlight opportunities to improve internal systems and communication.

When we onboard new engineers to the Numeric team, we keep these principles and pieces of advice top of mind. We consider the process successful after two months if the new engineer has developed informed opinions on the codebase, product, team practices, and/or overall strategy—something that’s only possible with the right knowledge and context from the start.

To build that context quickly, we've streamlined our onboarding documentation and local development setup so engineers can have the app running on day one and submit their first pull request by the end of that day. This efficiency lets them focus on onboarding tasks that span many aspects of our product and domain without having to waste time burning brain cells trying to get a dev environment properly setup.

We also integrate context-building activities from the very beginning. New engineers join customer and sales calls during their first few weeks, meet colleagues across every department, shadow on-call engineers, and engage in in-depth discussions with team members about past projects. Combined with other effective practices, this approach enables us to ramp up engineers quickly while ensuring they have the comprehensive context needed for long-term success.

If these practices interest you, we are hiring for more talented, product-oriented, full-stack generalist engineers to join the team. Here is a one-pager that gives more context on who we are, what we are building, and why we are building it. Please reach out if interested: ben@numeric.io

So it’s valuable to know what may trigger distraction or frustration in the course of work. In some cases, these can be wholly negative experiences. Things like being interrupted out of focus mode or hitting a significant unanticipated problem always feels bad in a way that can disrupt progress on a project. We learn to recognize such experiences so that we can consider how to prevent or navigate around them.

But there are more complex cases: those experiences that can be welcome in one context and unpleasant in another. There are many of these, but one such dynamic I’ve been pondering lately is the relationship between toil and creativity. I believe there is fundamental tension between two sorts of work, where each can be satisfying and rewarding in their own rite, yet they feel horrible to do at the same time.

Toil, for the purposes of this line of thinking, is work which just needs to get done. When you have a task, you work away at it, and progress is made. Other work involves thinking creatively about what to do and how to do it. This work is more creatively demanding and more unpredictable in its progress. Most white collar jobs have aspects of both, and engineering is no exception: there is a side of our work that feels like inventing and architecting, and there is a side of it that feels like digging holes.

Everyone knows that engineers enjoy the creative challenges of the job, whereas to toil almost implies a loss of agency or humanity. But I was painting shelves recently and it struck me how enjoyable the work actually was. There was a feeling of steady progress, a feeling of industriousness. It’s not that we don’t enjoy toil. As long as you have conviction you’re working on the right thing, toil can feel like the incarnation of getting shit done. As a programmer, these may even be the periods when the most lines of code are written. I like this feeling of executing, this sense of being automatic.

I was on a project and working in this mode when I encountered an important question about product behavior which I hadn’t considered ahead of time, and seeing it created a moment of dread. But why did I experience that dread? Considering product behavior, making strategic and user-facing decisions, and then planning how to build is the very creative work which I enjoy and take pride in. Nonetheless, my first feeling was frustration.

I realized later that the problem was not in one type of work or the other, but in their intermixing. I thought I was in the get-shit-done mode of toiling, and I got yanked right out of it. This is the fundamental tension, and it led me to wonder:

• Do other jobs deal with this internal conflict less frequently? If so, why? How?

• Does the nature of programming necessitate dealing with this frustration?

• What can a developer do about it?

Do other jobs deal with this?

In considering the other roles at our company, I don’t think they deal with the same degree of intermixing of toil and creativity that developers do, even though most knowledge work surely involves both. The sales team, for instance, has a lot of execution to do, and a lot of repetitions to sustain. They execute on a plan and maintain energy to work across many deals a day. Their creative work seems to come in the exceptions like making judgment calls about how to plan steps for a tricky deal, or in the systematic thinking like revisiting their demo playbook. In general, they do seem to not mix the work for the most part. When they’re on calls and sending follow-up notes, they’re very much not looking to rethink the plan and the playbook.

Recruiting has a similar dynamic. You hope to square away the creative judgment calls prior to the toil: What are the stages of our process? What are the formats of our interview? What are the criteria for evaluation? What should the content of this rejection email be? To the extent possible, we try to answer these things ahead of time so that we can efficiently execute within the system. Then, periodically, we take the observations from doing so and zoom back out on the creative aspect. Critically, much like sales, we save cognitive energy so that we are ready and able to home in on tricky cases and exceptions as they come up.

Why don’t software engineers do this more effectively? Why can’t we simply execute within a plan or system and save the refactors, the product planning, and more for later in the day or another day entirely? Maybe our work is not categorically different, but the degree of the challenge does seem to be distinct.

Is it fundamental to software?

A fundamental trait of software engineering as a practice is the unpredictability that comes as a consequence of novelty. Software is free to copy and to reuse. In most cases, when something we need is perfectly solved by an existing library, tool, or product, we simply install it–we don’t write it anew. If software engineers are involved, there usually must be something particular about the goals or the context that isn’t already solved. Moreover, the challenge of software is rarely simply one of implementing the answer to a question–it’s usually figuring out what the answer is, what the precise intention is. We are almost always, in some way or another, working under conditions of novelty.

Contrast this with recruiting. Even if your process were exactly identical to another company’s, you’d still have to do the work. You can’t just import a library and call a function, even if it’s been perfectly solved. You have to send the email, you have to get on the call, you have to book the hotel.1

So I do think there is a fundamental trait of our work which leads to unpredictability. But what is the connection between unpredictability and the creativity/toil association?

Put simply, the ability to separate the two (and thus avoid the tension) comes from the ability to toil consistently–to have a plan and to execute against it without disruption. This only works as long as the plan stays intact. For developers, it’s a fool’s errand to expect plans to stay intact. As a consequence, we don’t get to settle into a rhythm of getting shit done; we stay vigilant, paranoid even, for unforeseen problems and risks. It’s cognitively demanding in a way that can be very rewarding, but it’s also draining and leaves you occasionally wishing to have a simpler job.

So what do I do about it?

To be honest, I don’t think there is a silver bullet here. The best ideas I can offer are these:

Avoid it where you can

If you do know you have some high-precision focus work to execute on, and some creative planning or tricky architecture design to do, separate them. My point in this writing is that we simply cannot always do that, but in cases where you have the ability to separate the toil you should do so. Don’t make things harder than they have to be.

Reduce the demands of the toil

Another defining trait of software engineering is the level of depth and precision required in order to do the job. While we take pride in our ability and willingness to think precisely at low levels of abstraction, I also believe it is massive cognitive drain which makes it challenging to take on other items.

I recommend, wherever possible, to reduce the amount of brainpower required to toil. Break things down into smaller pieces, use reliable technologies and abstractions, and use any tooling that can help. Some tools, like programming languages, help to ease the challenge by raising the lowest level of abstraction you have to deal with. Even if you’re an expert with C, using Python can still free up your brain and your energy to be more prepared for the unexpected by raising the floor of abstraction at which you have to think. Just because you can do it all doesn’t mean you should. I believe AI copilots suit this purpose as well–one of their great benefits is not that they can write code that you wouldn’t be able to, but rather that you simply do not have to do it and can thus save your cognitive energy. For me personally, there is an amount of gas that stays in the tank by getting to offload some of the precise details of coding even in systems where I am perfectly capable of executing on the details.

Be mindful

Lastly, there is power in knowing something is coming even if you’re unable to prevent it. There will be moments of frustration and disruption. If you can be mindful of the situation and the impact it has on you, just knowing this can help you to recover and make progress. Perhaps it’s unsatisfying, but knowing one’s self is itself an important tool in dealing with such challenges, and the challenges will continue to come. In these cases, I recommend taking a moment to acknowledge the disruption and even planning to go for a walk or take a break to help smooth over the disruption.

Today, it’s still a joy to work with but this does not happen by default–Javascript and Typescript are flexible enough that you can turn them into whatever you want. The language and ecosystem do not come with batteries included, and unlike some languages (e.g. Golang) there is no common convention of good practices. You have to choose your own style & tools and stick with them in order to have a consistent and pleasant experience.

For us, success has come from choosing our style preferences, building our own idioms and patterns, and avoiding some parts of Javascript entirely.

Some JS things to simply avoid

There are a handful of Javascript things we actively avoid using. Many of them are caught by linting.

Null-ish ambiguity

In JS, you can check the boolean value of anything. This means you can use the empty string, zero, null, or undefined to represent nothing if you so choose. We avoid this ambiguity by using null to mean nothing. To that end:

• Don’t use undefined as a value. Treat it as identical to “nothing was passed in/set”

• Don’t use anything other than null to explicitly mean “nothing”

  • Empty strings are probably the worst culprit, but 0 is pretty bad too.

• Do not use || to coalesce values. Given the above rule of using null to mean nothing, we use ??.

Bad iterators

We use a regular for (const x of … ) loop for most iteration needs. It’s less error prone and more readable than an indexing loop. We also:

• Avoid forEach()

  • If an await is called inside the closure, it will not block–the iteration will proceed. It’s not a common case, but if you make this mistake the ensuing bugs are tricky. There really aren’t benefits over the regular loop, so we avoid it.

• Avoid reduce()

  • Similar to forEach(), it adds nothing and occasionally creates subtle bugs.

• Use .map() in a functional manner, where a new value is produced for each element of the list without modifying anything in the list.

The 'in' keyword

Avoid it. If you need to check whether something is in a collection, access it and check the result. The in keyword is confusing and easy to mistake for functionality which it does not offer, as it behaves differently depending on whether you’re accessing an object, an Array, a Map, or a Set.

Ambiguous function calls

In Javascript, you can declare a function like this:

This means both arguments are optional. What if I want to pass in a value for arg2 but not for arg1? The code would look like this:

In fact, even if they weren’t optional arguments, it’s easy to mistakenly pass arguments in the wrong order:

For any case where we have multiple arguments of the same type or multiple optional arguments, we prefer the safety and readability that comes from using a structured object instead:

This makes it materially harder to accidentally pass in arguments incorrectly.

Date object functionality

The Javascript Date object is pretty unhelpful, especially when dealing with time zones. Attempting to do math with a Date or to render it in a certain way is tedious and error-prone. This matters for us as software in the domain of accounting must make regular use of concepts around time. Beyond that, we have two concepts of time: real time (moments denoted usually in milliseconds UTC) and the accounting timeline (day’s resolution without any time zone associated). To that end:

• We use libraries for operations involving manipulations of Date and keep all such operations in a single, unit-tested utility file.

• We have our own CalendarDay type to represent the YYYY-MM-DD type which makes it clear which time concept is being used and which implements common operations.

There is an ECMA proposal to add a new namespace “Temporal” to core Javascript which we’re excited about. It offers improved tools for working with dates and times by applying learnings from the Date object and by separating distinct use cases; it would solve both of these needs out of the box.

Tooling and missing pieces

There are some components we’ve built ourselves to create an ergonomic environment for Typescript development.

Object validation and type safety off the wire

Everything in our backend code is typed. When data is coming in from some external place (the database, responses to API requests, request bodies from our own app) we validate it using a library called Zod. This serves a few purposes.

The obvious function is to check the data coming in to catch all classes of error involving unexpected data. This is especially important for getting data from 3rd parties. Validation can also catch bad requests from the front end or mismatches between the database and the code’s expectations of the result from a query. The alternative would be to either optimistically cast the data to the intended type (opening the door to various type errors) or to check for properties where they’re used, which would lead to type-validation code spreading throughout the code base. We prefer to enforce the expectations at the door.

The second purpose is to allow us to make better use of Typescript; by having an object to represent the type, we can use generics where types are inferred from the object as an argument to the function.

Lastly, we can minimize repetitive logic to enforce expectations. Without a validation library, our code might look like this:

In terms of the choice of library, Zod has excellent developer experience and depth of parity with the Typescript type system. With that said, it’s focused on parsing, meaning Zod copies the full object and can potentially transform the contents and type of the input object. This is useful for avoiding boilerplate logic in transformations but harmful when dealing with large volumes of data, as it is not as performant as libraries which only validate types without transforming the data.

Our Result type: why we don’t throw errors

In Javascript, errors are traditionally raised by calling throw new Error(...).

This creates implicit behavior, where the potential return types of a function are not readable by its signature. We want functions to have their return types annotated, and the error case is part of the return type; it’s a result from calling the function.

Thus we do not throw errors. Instead, we have a special type to represent the result of some fallible computation.

Result<T>

The result type represents a potentially-failed return type of T, and we make heavy use of it in the backend. This pattern exists in other languages and was fairly easy to build into Typescript. At its core, the basic idea looks like this:

The caller then calls a function:

This approach makes code more explicit and encourages engineers to consider failure modes and avoid “happy path” coding.

In practice, both the Failed and Success cases are classes we've built, and we also have a static object Results to serve as a namespace for instantiating errors like this:

These classes contain fields and methods we’ve added over time for various features like:

• Capturing stack traces

• Storing context data alongside an error, usually to be logged out at the top

• Prefixing or wrapping an error in the caller with additional context

• Setting content to be bubbled up to the API response, including an HTTP status code or a user-friendly message

• Formatting logging of these objects

Style preferences

Ultimately, consistency is critical so you should identify and commit to your team’s style preferences. I want to call out a few of Numeric’s preferences for style, not to serve as any sort of comprehensive style guide but because these key points help explain and inform the choices described above.

Explicit, readable. Avoid magic.

An engineer should be able to read the vast majority of our code base without having Javascript-specific expertise.

Implicit behaviors should be avoided, and one should be able to “follow” the code in order to see what it does. Anything which breaks this rule should be done for a good reason, and done only where future contributions are expected to be rare. It’s a bit harder to satisfy this target in the front end, but the principle holds. We avoid anything that seems to favor density or write-time pleasantness if it comes at the cost of readability.

Functional functions

Functions should take arguments and return outputs. They should not mutate the arguments.

The answer to the question “What does this function do?” should be answered by the function’s signature: the name, the arguments, and the return type should reasonably summarize the story. All functions should have the return type annotated.

More generally, we aim to have the function signatures and the involved types do a good job of telling the story of what’s happening in an area of the code.

Types as domain language

A last idea worth pointing out is that you can express a lot with Typescript types. We define and reuse named types across the code base, including the front end. This has led to a gradual defining of the domain via types and their names. For new engineers to the team these types can serve as hooks by which unfamiliar concepts are identified.

Because Typescript has such flexibility and simplicity, it is easy to express ideas and types and then proceed from there. Personally, I lean toward a sort of type-first programming approach where I define types and think about their transformations prior to coding any control flow logic. Strong, consistent typing means refactors are substantially helped by the compiler, and changes can be made with this in mind. Additionally, an accidental but pleasant consequence of this approach is that coding copilots like Cursor also seem to do quite well with well-defined types, and show a strong ability to connect the dots between them.

Because we work on accounting–a fairly deep domain with which software engineers are generally unfamiliar–this trait of Typescript has been instrumental. Much of what we do is evolve concepts and ideas, making the language in which we express our ideas quite important. To date we’ve been quite happy with the language, and the warts of Javascript and its ecosystem have been acceptable drawbacks for working with Typescript.

At Numeric, we made clear, intentional decisions of what not to build which allowed us to make great progress with a small team and ultimately gain traction with our audience. Our velocity was driven substantially by the things we did not do. It's important as product builders to identify those asks and ideas which might slow progress on core value to users. To that end, here are a few of those things which we avoided at Numeric and have been generally happy to have done so.

For context, we are a B2B SaaS company. Our users are finance & accounting teams who use our platform to automate & analyze their financial data as well as to collaborate on closing their books each month.

Dashboards

People love a dashboard. Or rather, people love the idea of a dashboard.

A splashy top-down view with charts, progress, indicators, statuses, and more looks great in a sales demo. It helps paint the picture of what success looks after engaging on your product. The reality, however, is that these dashboards can be of limited value and difficult to maintain in the early days.

To be clear: I'm referring to dashboards of your own, first-party data. For Numeric, that looks like this:

But we held off on building this for a long time, and had dozens of companies using our platform before we finally put the overview page in place.

This is because for a while user engagement wasn't excellent. We hadn't provided enough core value to get people consistently engaged and coming back. Any dashboards would have been fairly empty. And while a dashboard is good for a sales demo, it won't drive usage.

In short, a dashboard of your own app's data is what I'd call a "2nd degree feature"–its value is derived and dependent on other features of your product being used. It's not a good place to dedicate your early efforts. Put simply, if feature B depends on successful feature A, make A successful first.

Other 2nd-degree features

Sharing functionality

Is there something to share yet? Instagram started first by being a great app for taking and modifying photos. The sharing of photos drove its growth, but only after they had built a reason for people to be taking photos there in the first place.

In B2B software, this can look like sharing reports, views, or exports to other people or parts of the company.

As with dashboards, ask: is the content already there? Is there something worth sharing yet?

Preferences and configuration

When do you want your notifications? Through email, slack, daily, in-time, …? Do you want a dark mode?

Beware user input on this front: in research calls, users will happily surface "blockers" or "needs" along these lines. What they're doing is imagining that they're already onboarded to your product, and contriving what problems they might run into at some point. They're doing this both to be helpful and to make sure they don't go through the effort to switch and learn to use your product only to later run into deal-breakers.

It's important to realize that while these proposals may be accurate, they're still second-degree features. Make sure your users know that you understand their perspective, and meticulously keep track of what you're hearing. But don't put the cart before the horse. These features don't drive adoption.

You won't win users by eliminating reasons not to use your product–you have to have win them by giving them a good reason for using it. You'll even be surprised how many of these objections can be delayed into the future or forgotten entirely if the core value is substantial.

Table-stakes: billing, user management, etc.

There are a lot of things that may seem to fall into a category of “table-stakes”–things that users just expect a software product to have. Examples include:

• User management (invite & remove users, avatars)

• Notification preferences

• Billing settings (change credit card)

• Plan / tier selection

• UI themes, dark mode

Psychologically, these feel like safe things to do. They're easy to design, hard to argue with, and feel like progress. But these can be built later as they're needed. Instead, I recommend you handle these things manually (e.g. changing a credit card) until the burden to do so becomes significant.

Until then, stay focused on things that help you learn about your users.

Coding always takes longer than you expect so don't spend precious time on any tables stakes if you can get away with not including them. And don't assume what your audience will need, as it may be less than you think.

Permissions

Permissions are messy. They define rules based on the attributes of domain objects, the roles of users, and relationships among these. This article does a great job of outlining this complexity, and rightly points out that most real applications will have a model which uses multiple types of authorization to meet their needs.

When your product is still early, things are in flux. Features are being built, re-built, removed, and refactored in response to new learnings all the time. This is not ideal when it comes to defining your permissions rules.

At Numeric, we avoided authorization for this exact reason. We knew the changes in the data model were too frequent, and introducing permissions too early would be a disproportionate headache to build, evolve, and maintain.

By the time we did add a permissions model, the model was almost obvious. Our platform's design and data model had coalesced around a few primitives like workspaces, reports, and tasks. With the help of Oso (both their software and their team), we were able to define a permissions model which was straight-forward enough that non-engineers can understand and discuss our user needs, and what we've built for authorization has been stable and long-lasting.

But I want to reiterate: it was not obvious what these primitives were going to be prior. In retrospect they seem obvious, but at times it looked like abstractions were going to develop in a very different way. Had we introduced permissions too early, it might have artificially tied our plans and our minds to a worse model for the platform.

Mileage may vary

For all of these points, you need to understand and evaluate what makes sense for your business. Focus on what is distinct about your product and your audience. If something I’ve listed above is necessary or part of the core value proposition to your users, don’t skip it.

All of these examples illustrate the same general theme: in a startup, learn about your users and your domain deeply, and stay aggressively focused on learning more and progressing toward product-market fit. It sounds simple, but in the fog of actually building a company it can be surprisingly hard and subtle to apply the idea. It's difficult, but alongside a tight-knit team and a fast iteration cycle this allows you to accomplish great things.

The answer, of course, is that many different things must come together to make this possible. For us, one particularly important component has been how we approach discovery and product development, which depends critically on our belief in an “80/20 rule” for new feature development.

Consider a “traditional” approach to product development:

1. Pain point is identified and information is gathered (led by product managers)

2. Design and feedback process (designers are now brought in the process)

3. Documentation and requirements are formalized

4. The project is handed off to engineering, who have their own approach for building

‍

For a lot of reasons, teams tend to operate in this model even if they didn't start this way. In many teams which claim to be "agile", the process will be largely the same but just repeated on smaller pieces. Or, in some cases, the "agile" practice only exists within the execution of step 4.

‍

At Numeric, we hold a few beliefs which reveal problems with the above approach:

1. There is more than one way to solve a problem, and both product and technical insights can introduce new ways of looking at a problem.

2. Identifying which details and requirements are valuable (or essential) requires deep understanding of the audience.

3. It's notoriously difficult for non-engineers to know the relative difficulty of technical tasks, and often small details and non-critical requirements drive disproportionate effort and cost.

‍

Taken together, these lead to a conclusion:

For most product goals or pain points, there exists some solution that achieves 80% of the value with 20% of the effort, but finding it requires combining deep understanding of engineering, product, and users.

‍

The problem with the "traditional" approach then becomes obvious–if engineering is only brought in after requirements are formalized, we've lost the ability to leverage this flexibility in defining the solution.

Once the "define the solution" phase has been solved and documented, the core shape and definition of the solution is largely set. Engineering may push back on aspects at the fringes but it's unlikely the plan will be dramatically reoriented. Not only have we missed the possibility of a more optimal solution, but this pattern creates a frustrating and unsatisfying role for engineering to occupy.

Alternatively, we can work to combine customer insight, product understanding, and technical knowledge at every stage of development. Engineers provide insight into what's difficult, what's easy, what's possible and what's impossible. The product manager (or anyone with insight into the customer) can elucidate the goals: who are we are serving, what's necessary or nice-to-have, what's certain or experimental. And the designer can synthesize these ideas into a concrete, usable proposal. Together, these constraints encourage the kind of creative problem-solving that yields a great product which can be quite different from the first proposal and delivered in a fraction of the time.

This approach vastly shortens the timeline to learn more from customers after launching. And for early startups, this makes the difference between success and non-existence.

It's not easy to do this. The domain, the customers, the company size, the members of the team and other variables can help or hinder the effort. But when done right, the result is a fast-moving and collaborative process with impressive results to show for it.