Two layers in the back office. One is safe to vibe-code. The other has to be deterministic. How to tell them apart, and what breaks if you get it wrong.
Jared Henriques
Head of Sales
A while back I was talking to an operator at a fast-growing startup. Four months into the job with no engineering background, this operator was running their entire billing operation themselves.
Stripe was handling payments. DocuSign was handling contracts. An AI parser was pulling rate cards out of signed PDFs into a custom dashboard they'd built. The dashboard ran the subscription logic, the usage metering, the customer-by-customer rate calculation. The whole thing was stitched together. The whole thing was run by one person.
What they told me, more or less: it works for now, but they're watching for the day it doesn't.
They're right. It is working. They're also right to be watching.
This isn't a unique situation. I'm doing the same thing. Like every other person reading this in 2026, I've spent the last six months living in Claude Code, vibe-coding internal tooling for our team. Sales dashboards, prospect-research scripts, demo-prep tools. The amount of stuff a non-engineer can build in a weekend right now is actually mindblowing. The build instinct is correct. The energy is right.
What I want to talk about is which layer that energy belongs in.
There are two layers in the back office of a SaaS company.
The top layer is everything you build for your team. In other words, it's for internal use cases only. Dashboards, custom CPQ, internal AI tooling, payment reminders, customer portals, sales-stage automations. This is the layer where vibe-coding pays off the most. You know your business. You have the context. You know what your operators need to see. AI helps you ship a year of internal tools in a weekend, and when something is wrong, the cost of being wrong is small. Fix the prompt, fix the script, ship again.
The layer underneath is different. The contracts, the subscriptions, the deferred revenue schedule, the rev-rec entries, the commission triggers, the journal entries flowing into your accounting system: that's the data model your business runs on. Auditors look at it. Acquirers look at it. Your CFO has to defend it. It's deterministic, traceable, and unforgiving in a way the top layer isn't.
The mistake isn't building. The mistake is putting the build energy in the wrong layer.
Here's the part I see people miss when they're three months into vibe-coding their billing layer. The first 90 days look great. The system works. Invoices go out. Customers pay. Stripe collects. The dashboard is pretty. Everything's fine.
Then six things start happening and it looks like this:
A contract changes mid-cycle. A customer adds a seat, swaps a plan, changes a usage tier. The proration math has to flow into the current invoice, the rev-rec schedule, the commission posting, and the AR reconciliation. In a built system, this is one field change becoming a four-system manual update. In a deterministic data model, the cascade just runs.
A pricing model evolves. You add a new SKU. Your AI parser has never seen the new contract format. It still confidently produces a rate card from the PDF. The rate card is wrong. You don't notice for two months because the customer's invoice is roughly the right size.
Auditors ask for the deferred revenue schedule. The answer is in someone's spreadsheet, reconstructed from invoice dates. The auditor asks how the schedule changes when a contract is amended. There's a long silence. Nobody really knows for sure.
A pricing change requires re-stating commissions. The commission was paid against the old contract terms. The new terms change the calculation. You need to claw back, or top up, or both, and the audit trail of who got paid what against which contract version is in the dashboard's database, but only sort of.
Acquirer due diligence. The books need to be defensible to a buyer's accounting team. "Our AI parser extracts it from the PDF" is not an answer that survives that conversation. The clean-up is a six-figure exercise that the deal almost dies over.
The person who built it leaves. The prompts they wrote, the schema they shaped, the edge cases they fixed silently in their head: gone. The next person inherits a dashboard they don't understand, layered on a parser they didn't train, feeding accounts they can't reconcile.
These aren't day-1 problems. They're month-12 problems. The cost of getting them wrong scales with how successful you've been by the time they hit.
Our founder, Aswin, was employee number one at Rippling. He built their original billing infrastructure from scratch. The whole thing. Subscriptions, prorations, invoicing, revenue recognition, the data model.
He spent years on it. He started Measure because he watched what came after the build. The maintenance. The auditor questions. The reconciliation nightmare when sales sold something billing couldn't enforce. The rebuilds when pricing models changed. The realization that building billing isn't the hard part. Maintaining it is.
Measure exists because we already did this once and learned that the right move isn't to do it again. The right move is to make the data model into a clean, accessible primitive, and let companies build their actual product around it.
Here's how I tell prospects to think about it now.
Build your back office. Build the dashboards, the AI agents, the internal CPQ, the customer portal, whatever your team actually uses. That's where your business logic lives. That's where vibe-coding earns its keep.
Run the billing data model on Measure's API. The cascade (contract → subscription → invoice → rev rec → commission → journal entry) is deterministic, mapped cleanly into your accounting system, and accessible via clean endpoints (and an MCP server, if you're building agents). You don't have to log into our GUI if you don't want to. We care that the data underneath your business is right.
That's a buy-and-build move, not a buy-or-build one. You buy the layer that has to be right at year-end. You build the layer that makes you different from your competitors.
The pricing for that base layer starts at around $500/month. Two hours of senior engineering time, monthly, in exchange for not maintaining the layer that breaks loudly when you're not watching.
We're not anti-AI. Our team uses it constantly. Every Measure customer is using AI somewhere in their stack, and a lot of them are using it inside Measure's surfaces.
What we're against is AI inside the math.
The right place for AI is on top of clean data. Once your billing data model is correct and updates deterministically, you can ask interesting questions of it. Why did this customer's invoice grow 30% quarter-over-quarter? Which deals had usage spikes that should have triggered an upgrade conversation? Which renewals are at risk based on usage decay? What's next quarter's ARR given pipeline and historical conversion?
Those are questions where probability adds value. The model surfaces patterns a human wouldn't catch. It generates summaries that turn raw data into something a CFO can act on.
But every one of those queries depends on the underlying data being correct. AI on top of bad data produces bad insight, faster.
The point of clean infrastructure underneath is to make the AI layer above it useful.
I want to be specific about what we think you should build and what we think you shouldn't.
"Don't build the pipes, the data model, the deterministic cascade from contract through commission, and the accounting flow into your books. We've watched too many companies build that layer themselves, and we've watched the same things break in roughly the same order. I built it once at Rippling. We built it again at Measure because there was a better version. The point isn't to do it again." - Aswin, CEO and co-founder
What we think we are, in product terms, is clean, composable billing data. The deterministic engine is the thing we obsess over, not an afterthought. We're constantly looking for new ways to add value around it. New surfaces. New agent capabilities. New ways AI fits inside a product where the floor stays correct.
What we think you should build is the layer where your business is actually different. How you want to see this data. The reports your team uses to make decisions. The internal CPQ that fits your sales motion. The AI agent that knows your workflow. The customer portal shaped to your relationship with your buyers.
If you have clear ideas about how you want billing data organized, filtered, and surfaced for your team, build that. Use our API to bring the right information where you need it, without risking the data falling out of flow with your finance and accounting logic. The pipes stay correct. The surface is yours.
The biggest operational gap at growing B2B SaaS companies isn't billing software. It's the connection between the go-to-market team and the finance team.
Sales negotiates a custom term. Finance discovers it in month-end. Reconciliation eats three days. Trust erodes. The system that should let the business run at full speed becomes the bottleneck that slows it down.
When the contract, the subscription, the invoice, the rev-rec schedule, and the commission event all share one data model, that gap closes automatically. Not because someone's pressing a sync button. Because the system knows.
That's what we built. It's deterministic underneath, accessible via API, and the GUI is one of many ways to look at it.
Build your back office. Build the dashboards and the AI tools and the things that make your team faster. Use Measure for the layer underneath that has to be right at year-end.
The infrastructure has to be boring and right before anything sitting on it can be interesting and useful.
That's the bet.
If you're three months into building your own billing system and starting to see the cracks, or if you're about to start and want to know what you're getting into, we'd rather be a resource than a pitch.
→ Book a demo and walk through what your data looks like on Measure
Billing and revenue automation that handles contracts, invoicing, revenue recognition, and commissions in one connected system. Book a demo to see how Measure works.
