New Builders Spotlight: John Snow

In supporting the industry defining companies of the portfolio, we are fortunate to work with the brightest, most dedicated people in the world. As we look to identify the next generation of best-in-class entrepreneurs, we naturally turn to our network of peers and friends. ‍

Top engineers might be early in their career, but have often been obsessed with technology and innovation from a young age. They're also better attuned to who are the other top technical minds in their respective cohort! Many of the most important companies we’ve invested in or started won by attracting younger superstar engineers (Palantir, Oculus, Addepar, Qualia, Blend, Affinity, etc).

We’re excited to feature some of the most promising engineering and product talent we have the pleasure of collaborating with not only at 8VC, but within our broader network.

Today, we're thrilled to highlight Will Taft, Software Engineer at Mockup (8VC portfolio company). Will previously worked as an engineer at Composable Analytics after graduating from Yale University with a degree in Math and Philosophy.

What is Mockup? How did you learn about this opportunity and why were you excited to join?#

Mockup is simplifying freight audit and payments by transforming legacy processes with a tech-enabled approach.

I’ve been at Mockup since July 2022 – the two years prior I was at another startup called Composable Analytics. They are building a platform for data management, ingestion and analytics. I was interacting with businesses who have many different software products so we were automating ingestion from disparate data sources in a domain-agnostic fashion.

I quickly realized there’s significant business complexity that can’t be solved by merely automating ingestion in a generic way – the software needs to understand the business domain.

So for my next opportunity I wanted to tackle a specific domain of business complexity, simplifying, and modeling from first principles. I found that opportunity with Mockup. From the outset, Matt, Shu and I have been aligned on how Mockup can drive value by injecting technology into an area where dollars are lost because of mismanaged complexity.

Matt and Shu convinced me this was a particularly large problem in logistics, and particularly in payments, as 20% of invoices have errors. Those errors create a challenge in the current system: either shippers spend more time auditing their bills and deprive the carrier of working capital or the carrier gets paid faster and the shipper pays more than they should because of an accelerated audit. Carriers should get paid quickly and shippers should pay the right amount. We’re making that a reality.

What part of the Mockup platform do you work on? What does your day to day consist of?#

We have three engineering pods:

• Payments: Focused on moving money – ranging from paying an invoice to closing the transaction and moving money between accounts. 
• Platform: Domain-agnostic tools for generic business problems – document processing and information extraction & ingesting information from API endpoints.
• Transportation: Review existing domain complexity that exists in logistics for freight. We figure out how to model entities like payable invoices and shipments & create workflows to manage them.

I am part of the transportation pod. Recently, I’ve been working on automating invoice corrections. For example, a client might receive an invoice with an incorrect line item. Maybe they were charged detention but they have a pricing agreement that dictates detention can’t be charged. The carrier will send a new invoice without the charge. Mockup will automatically match the new invoice against the existing one and carry over results from the previous audit, invalidating results where applicable. We then reshare the updated amount to be paid. I’ve been working on this process and the visibility into this flow for users.

I enjoy our collaborative process with the business team for grappling with significant complexity, figuring out how to represent this complexity effectively, and building a product on top of it.

There's a significant amount of edge case analysis required in this domain specifically to understand how invoices get processed - oftentimes real world logistics directly impact what a structured invoice entails. How do you discover these edge cases and iterate on domain data modeling to encompass them?#

Our team is our most valuable asset as they boast incredible domain expertise – our customer success team is best-in-class and has been working in logistics for decades. They know all of the potential complexities & these folks are walking encyclopedias of edge cases that could occur with invoice corrections.

We like to develop strong frameworks, build quickly and release flexible products we can rapidly iterate on. For example, invoices were flowing through our system before we modeled out invoice correction. We started with a preliminary version that required engineering intervention and ultimately turned on an automated process to correct the invoice, invalidate the audit and communicate this to the user.

With all of this flexibility, do you have to manage a good amount of schema migrations with your databases? What tools do you use for schema migrations and how do you handle said complexity?#

We use PostgreSQL with a database tool called Prisma. This stack is working well for us and it makes it easy to translate our domain model into code. The hard part is coming up with the right domain model.

If you model things incorrectly and build a system around it, this can cause many downstream problems. You want to ensure you’re not making too many limiting assumptions around entity relationships. For example, two high-level entities are shipment jobs and payable invoices. You need to think carefully about the number of invoices for a shipment job and vice versa.

We leverage a ton of entity-relationship diagrams – in the codebase there are well-defined module import rules to make sure our objects and relationships correspond with this domain model. A payable invoice can have payable invoice line items but maybe the line items shouldn’t be aware of the invoice. We carefully encapsulate the domains and enforce this to mitigate any coupling that would make those migrations difficult.

What has been the most surprising thing you've learned to date at Mockup and about the logistics space more broadly?#

I would reiterate the significant complexity associated with pricing agreements between different organizations within the logistics industry.

Invoices are always moving hands and the only way to determine if the invoice is correct is if you also reference many pricing agreements that exist between the organizations involved in that invoice.

It’s like if you went to buy a hamburger and they charge you for the hamburger, but you need to check if they charged the agreed-upon price of beef. You might have an agreement that’s tied to a particular beef index and offset from that index, so you need to double check they used the right index and offset. Now you also need to double check they didn’t charge you for mustard because you have an agreement that you get mustard for free. Now imagine you have agreements like this with every fast food chain which you have to cross check every time you buy a hamburger. That’s the complexity introduced by pricing agreements and contracts between organizations in freight billing.

This pricing complexity was totally new to me– carriers will charge for fuel, but the amount they charge for fuel is contingent upon an index for fuel price. When you get an invoice, you need to make sure the fuel surcharge matches the current price of fuel in the index you agreed to tie your pricing relationship to.

There’s the invoice and tons of pricing agreements that control what you can and can’t charge for and how much you can charge for it – they’re rarely generic, but tightly coupled to a specific shipper and carrier. It’s important to cross check the invoice against those pricing relationships.

On the one hand, we want to meet our clients where they are at with respect to this kind of complexity. But over time we hope to drive simplicity and new approaches that are better for all parties involved.

What are you looking forward to on the Mockup product roadmap?#

I’m excited about improving audit explainability. We’re doing audits on invoices to ensure they’re fully correct – you can see discrepancies and make decisions based on said discrepancies. The next step is introducing a better layer of explainability to the platform: Why is this number wrong? How could it have been calculated incorrectly?

We want to introduce similar explainability so you can see how fields are calculated and whether it’s reliant on stale data (e.g. an incorrect public tariff). We’re giving humans better visibility as well as the ability to manage escalations effectively.

The payments layer presents a very compelling opportunity as well. Soon we’ll be able to handle an invoice in a totally closed mockup - we’ll pull information from a TMS to generate an invoice for a carrier, receive the invoice on behalf of the shipper, and then pay the carrier. I’m really excited to see this and the corresponding efficiency gains.

With respect to explainability, are you using any tools for data lineage?#

Right now, most entities in our system are considered revisable. We track all revisions in a way that is extensible to new entities.

The platform pod created a generic system for automating small data processing tasks like pulling a shipper name off an invoice or normalizing an organization appearing on an invoice. Each of these tasks is represented with an input and output set of keys. You can drill down to see which tasks introduced which piece of data and what the effects were.

We need to be especially thoughtful here as a good amount of the platform is automated – we’re creating normalized entities based on a set of documents, which are an incomplete representation of the world. Our system might tag a PDF as an invoice and from that create a normalized invoice, shipment job, and initiate an audit. That judgment could be incorrect, so when a human does correct it, we automatically clean up anything downstream of the judgment. Our revision tracking allows us to introduce automation without making the system opaque or uncontrollable by users.

There's a stripe analogy here as you're building a horizontal platform enabling all logistics companies to manage payments. How do you anticipate this ecosystem evolving? Where does market pull come from?#

Two ways we’ll continue to expand and evolve;

First, there’s going to be more interest in Mockup managing more of the freight billing lifecycle, both on the payables side with shippers and the receivables side with brokers. We’ve started with audits and along the way built up a system for representing and managing invoices and shipments. A lot of that information can be leveraged again for cost allocation or GL coding. So we’ll start bringing those capabilities to Mockup.

Any hot takes on working at a startup?#

Boring is better. I’m bullish on translating messiness in the physical & operationally complex world – perhaps there’s a sector where there are hundreds of years of problems that weren’t tackled by computers. It’s a valuable craft to translate these problems into ones computers can solve.