The Vendor Meeting That Saved Us 10X

Most vendor meetings are a waste of a calendar slot. Someone shows slides. Someone else nods. Nothing in production gets better. Our monthly meeting with SingleStore was not that meeting. It paid for itself many times over, and it taught me more about management than most management books have. I was Chief Technology Officer (CTO) at MonitorBase from October 2015 to February 2025, then VP of Development until April 2026. We served 10,000 clients and ran more than 7 million queries a month. I led a team of 12 or more developers. At that scale, your database vendor is not a line item. They are either part of how you ship, or they are a bill you resent paying. How we got there We did not pick SingleStore from a demo. We evaluated it against Snowflake and other real options, including search tools and staying on MySQL. We tested with our own workload. The test that mattered was ugly and real. A PHP process that worked through 10 to 15 million records with 8 joins took 24 to 48 hours. The same work in SQL on SingleStore took under 10 minutes. We also picked it in part because it fit Laravel. I have run Laravel in production for more than 10 years. If a platform fights your framework, you pay for that fight every single day. Picking the vendor was only the start. Keeping the value coming was a management job. What made the monthly meeting work First, we brought real problems, not status updates. Slow jobs, hard joins, the queries that hurt. If a dashboard was slow or a predictive run was dragging, it went on the list. Second, we brought numbers. Before and after, in plain language. Predictive algorithms went from 24 to 48 hours down to 15 minutes. Throughput went from 60 requests per minute to 1,000 requests per minute on Columnstore. We used Pipelines to bring in 100 million records. When you talk in numbers like that, nobody hides behind vague progress. Third, we treated the vendor like part of the team, and we expected the same back. That means engineers in the room, not just account people. It means they heard what was coming next in our roadmap, and we heard what was coming next in theirs. It also means we did our homework before the call. A good partner cannot fix a problem you describe badly. Fourth, we held our own lines. One rule never bent. Actual credit data was never cached, for compliance. It was always pulled directly from the database. Everything around it was cached in Redis, sessions, dashboards, and the rest of the site, so clients got near instant loads. A vendor can help you go faster. They do not get to move your compliance lines for you. That mix mattered. Trust, but with metrics. Openness, but with clear boundaries. Management is not just inside the building A lot of managers manage only their direct reports. The real job is wider. Vendors, partners, and contractors affect your uptime, your costs, and your team's week as much as anyone on the org chart. If you only call a vendor when something is broken, you get support ticket energy. If you meet monthly, with real work on the table, you get something different. You get early warnings. You get better ways to use tools you already pay for. Sometimes you get a fix that turns a two day job into a coffee break. I tried to bring the same habit to my own work outside that role. I published Laravel tooling for this stack on my GitHub, including a package for SingleStore full text MATCH against indexes. You can see it on GitHub. Good vendor management is not passive. You learn the platform well enough to build with it, not just buy it. That is still how I work, and GitHub is where a lot of that proof lives. The takeaway If you have a vendor that matters, do this one thing. Put a monthly meeting on the calendar, bring your three ugliest real problems with before and after numbers, get engineers from both sides in the room, and end with owned next steps. Do that for six months and you will know, with data, whether that vendor is a partner or just an invoice.