We run 4 locations and the real struggle was always visibility. Waiting on GM reports spend for days or weeks. It's relieving to not be anxious about that part first of all but also having cards with spend controls is also a big plus which is needed for all franchises, each location is staying within limits. It also makes it easier to hold people accountable without constant follow ups.
We're a startup CM/GC, on Ramp since October. Overall it's worked well — a few sync errors, but manageable.
Our stack:
We recently turned on the Autodesk ↔ QBO integration, which shuffles costs between the two. Our budgets use CSI Masterformat — about 1,000 possible line items, of which any given project uses 40–150. Those live in QBO as Products & Services (not the Chart of Accounts) since they roll up to ~5 COA lines and would otherwise pollute the COA.
Before the integration, we just coded credit card and reimbursement expenses to a COA line, then manually re-allocated them to the right CSI code in Autodesk each month. With the integration live, expenses need to be coded directly to a Product & Service.
We can do this in Bill Pay, but not in Expenses. Ramp support told me today they don't think it's possible and are looking into it. That makes no sense to me:
Anyone else running Ramp + QBO Products & Services this way? Is there a workaround I'm missing?
If not and we are required to manually allocated these Ramp becomes essentially useless for expense management.
l'm looking into Ramp's AI Token Spend Intelligence and the automatic classification into COGS vs OpEx seems interesting but how does it determine which category token spend falls into like is it based on the provider or something you configure manually?
Last week Seb shared how we built every employee at Ramp their own AI coworker. The response was overwhelming: nearly a million views, hundreds of messages, and one question that kept coming up. How did you actually build this?
The honest answer is stranger than most people expect. Glass was predominantly vibe coded by a three-person core team (a product manager, an engineer, and an IT engineer) and the story of how we went from a messy prototype to a product used by half the company is, I think, the more interesting thing to talk about. The real lesson isn't that vibe coding works. It's that vibe coding is a skill, and like any skill, there's a version that produces great results and a version that produces a mess. We learned the difference the hard way.
Jay Sobel kicked things off as a weekend project. He wanted to see if wrapping a coding agent in a desktop app could make it useful for people who'd never open a terminal, while still giving engineers something better than a raw CLI.
A month later Seb picked it up because he saw the potential for non-engineers. He's a PM with an engineering background, and he had a theory: the reason AI adoption had stalled at Ramp wasn't the models, it was the environment. People needed a preconfigured workspace, not a tutorial. So he started vibe coding and built out core integrations to things like Slack and Notion, connected Dojo, and polished the core chat UX. Within a few weeks Glass had about 20 daily users asking for more.
The demand came first. People were already using it, and we had to keep up. Glass had users before it had a team.
As Glass gained traction, Seb pulled me in to help build faster. And this is where it got interesting.
The codebase was growing quickly, but it was growing outward. Every new feature in its own file, its own patterns, its own styling approach. Components doing almost the same thing in slightly different ways. Utility functions reimplemented because the agent didn't know they already existed somewhere else. No shared design system, so each feature looked a little different from the last. Documentation hadn't kept up, so the agent couldn't even reference what the product already did.
The product still worked. But things were slowing down. Bugs showed up at the seams between features. PRs got harder to review because you couldn't tell whether code was intentionally different or just inconsistently generated. The codebase was getting bigger faster than it was getting more coherent.
None of this is unique to vibe coding, by the way. It's the same entropy that hits any fast-moving team. It just happens faster when the AI can write code faster than anyone can keep track of the whole.
We could have stopped and rewritten everything. But we had users who needed the product to keep getting better, and there were only three of us on the core team: Seb, me, and Cam. So instead of fighting the vibe coding, we figured out how to do it better.
Teaching the codebase to maintain itself.
None of this is fancy. It's just normal software engineering, pointed at a vibe-coded codebase. But that's kind of the whole point: the engineering discipline doesn't go away just because the AI is writing the code. If anything, you need more of it.
Connections That Don't Make You Wait
Glass connects to Slack, Salesforce, Notion, Linear, Gong, Datadog, and a dozen other tools through MCP servers. The straightforward approach is connecting to each one when you open a chat. With 13+ integrations, that's about 45 seconds of handshake latency before you can send your first message.
I built a proxy layer that connects to all external services once at app launch and keeps those connections alive. Each chat session gets a fresh lightweight wrapper around the shared connection. One persistent pipe per service, unlimited sessions on top. Startup went from 45 seconds to about 2.
Dojo: A Git Repo That Non-Engineers Can Contribute To
Dojo, our skill marketplace, is backed by a Git repo. Skills are markdown files. No code, no deployment pipeline, no infrastructure. When someone creates a skill in Glass, it writes a markdown file. When they publish it, Glass handles the Git commit, the pull request, and the review workflow behind the scenes. The user never sees GitHub.
We needed non-technical people to contribute their expertise without learning version control. A CX lead who builds a Zendesk investigation workflow shouldn't need to know what a pull request is. But we also needed skills to be versioned, reviewable, and auditable, which meant Git was the right backend.
The trick is making Git invisible. Glass creates the branch, writes the file, opens the PR, and handles the merge once it's approved. The contributor sees "publish" and "published." The engineering team sees a clean Git history with proper review trails. Over 350 skills have been shared this way.
Memory: A Cron Job That Builds Context
Glass's memory system runs as a background pipeline. Every 24 hours, it mines the user's previous sessions and connected integrations (Slack, Notion, Calendar) and synthesizes an updated profile: who they work with, what they're working on, which resources are relevant. Stale entries get cleaned up automatically.
We made memory write-once-read-many. The synthesis pipeline writes memory files. Every new session reads them at startup. The agent never modifies memory during a conversation, it just uses whatever context exists. You know exactly what the agent knows, because it's all in files you can inspect.
Integrations: Pre-Packaged and Self-Healing
Every Glass install comes with our internal CLIs pre-bundled (Ramp CLI, data tools, Google Workspace tooling) so the agent can use them without the user installing anything. MCP connections are configured centrally and authenticate through Okta SSO, so connecting to Slack or Salesforce is a single click, not a config file.
When integrations break (tokens expire, services go down) Glass detects the failure and either auto-refreshes or prompts the user to re-authenticate in plain language. A non-technical user should never see a cryptic error. The system either fixes itself or tells you exactly what to do.
Distribution and Auth: Harder Than It Sounds
Getting Glass onto everyone's machine and keeping them logged in turned out to be one of the hardest problems. Okta SSO, certificate management, auto-updates across a managed fleet, MCP token refresh flows that don't break mid-session. Cameron Leavenworth owned this, and most users have no idea how much invisible work keeps their "single click to connect" actually working. Stay tuned. Cam's writing the deep dive on that one next.
Here's what building Glass looks like now:
Someone identifies a need. User feedback, a Slack message, something they noticed using the product themselves. They describe the feature in Glass. Glass builds it, referencing the design system, reusing existing components, following established patterns because the documentation tells it what's already there. The PR goes through automated validation: defrag checks, type checking, doc completeness. A human reviews the diff. It ships.
We go from idea to production in hours. Not because we're skipping steps, but because Glass automates the ones that used to be manual. The agent writes the code. The pipeline checks the quality. The human makes the call: is this the right thing to build, and does it actually work?
Jay, who started the repo as that original weekend project, joined us later and said he was "shook by how much we shipped and the relatively fewer bugs." Honestly, it's not because we're that good. The system just catches its own mistakes before they pile up.
We're pushing Glass further.
The pattern we keep seeing is that every form, every settings panel, every modal in the app can become a conversation. Why click through a connection setup when you can just say "connect my Notion"? Why navigate to settings when you can say "turn on dark mode"? Why fill out a bug report when Glass can notice you're stuck, offer to file it for you, and spin up an agent to start investigating?
We're building toward something where the UI is a reference, not a requirement. Everything you can do through a menu, you can do through a message. And Glass keeps getting better at it because it can read its own blueprint, it has tools to modify itself, and it knows your role, your tools, and the organization around you.
Yeah, kind of. And I get why that makes people uncomfortable.
There's a narrative in tech right now that vibe coding is either the future of software or a toy that produces garbage. Both are wrong. Vibe coding is a skill. Like any skill, you can do it well or you can do it poorly, and the difference isn't talent, it's discipline.
The model still writes the code. But now the codebase teaches the model how to write it well, and catches it when it doesn't.
I don't know if that's "the future of software" or whatever. But the teams that figure out the meta-game, not "how do I get the model to write good code" but "how do I keep the codebase healthy as the model writes a lot of code very fast," are going to build things that weren't possible before. We stumbled into it, and I think more teams will too.
Ive been using Ramps chrome extension lately to grab receipts automatically while shopping from my laptop and im not a lazy person but I don’t say no to anything that makes things easier for me at work. Initially I thought it would monitor when I make a purchase and add the receipts (I know wishful thinking lol) but even me uploading the receipt and it matching automatically with the transaction is a great addition!
