Hi, I’m Cassandra

Our first SDK had a launch date set by two things neither we nor our credit bureau partner could move alone: a major industry conference we’d both committed to as the announcement moment, and the six months of build time we needed just to reach production, where partners could start onboarding. That’s a different kind of pressure than a self-imposed target. The date belonged to both companies, and we couldn’t quietly slip it without disappointing the partner whose credibility we were building the whole platform on.

The original scope included employment verification. Partway through, a new vendor evaluation for that feature ran long: the delay was commercial, tied up in contract negotiation, not technical, and not something that could be accelerated.

The options on the table were to cut scope unilaterally and explain it later, or to ask the partner for more time and hope they said yes. I did neither. I went back to the credit bureau and proposed substituting a different report already in their product line, and moved employment verification to a later phase.

They agreed, and not just as a courtesy: the swap added a second one of their own products to the launch, so it made them better off. The SDK shipped on schedule, and employment verification followed in the next phase.

What I’d take from this: the date and the plan were two different commitments, and I stopped treating them as one. The date belonged to both companies and wasn’t mine to move. The plan was still mine to work with, which meant I could look for an alternative instead of forcing the vendor negotiation or quietly cutting the MVP to make the date.

One of our largest property management integrations started as a partnership with a middleware vendor, not a direct build. Property management software has no shared standard: every system uses its own schema and terms, which is exactly the gap a middleware vendor is built to fill. We picked one to standardize that connection for us.

I gave their engineer complete product requirements and detail up front, so that was never the issue. What followed was a pattern I couldn’t fix from my side: things broke often, I couldn’t get them to move at the pace we needed, and I rarely got an actual root cause. I was putting out fires without ever learning why they started. At one point, they deleted our project documentation entirely.

I didn’t wait for them to explain it or fix it. Delaying would have only pushed their own fix further out, and it would have cost us clients in the meantime. I rebuilt the mapping and documentation myself, immediately, so the integration kept working while the vendor relationship kept failing around it.

That crisis settled a question we had already been circling. Using a middleware vendor for this integration wasn’t sustainable, and around the same time, our own roadmap had already flagged direct property management system integrations as a priority: those are the systems enterprise property managers run on, and owning the connection directly was how we’d reach them. I judged this particular integration could be one of our most profitable, but only if we owned it outright instead of routing it through a vendor we couldn’t get a straight answer from.

So I made the case to rebuild it in-house. I rewrote the PRDs, scoped the framework, and handed engineering a direct build instead of another vendor relationship. Once it shipped, I planned and ran the client migration off the old integration, moved everyone over without disrupting them, and closed out the vendor relationship once nobody was left on it.

What I’d take from this: outsourcing a connection doesn’t outsource the risk sitting behind it. The moment a client felt the vendor’s failure, it became my problem anyway, so waiting for an explanation I was never going to get wasn’t actually protecting anything. The pattern itself was the case I needed. I stopped waiting on them to explain and put that time into building something I could stand behind.

Support tickets started arriving in a wave, and they were the kind that tell you something is wrong without telling you what. This was our consumer-side identity verification, the flow renters pass through when they apply to a property, not the housing-provider side I built to reduce fraudulent listings.

I could have worked the tickets one at a time, or handed the investigation to an engineer. I reprioritized my own work and took it myself. I instrumented FullStory so I could watch where users were actually going wrong, whether they were dropping out of the flow or submitting incorrect information, because the ticket descriptions were secondhand and all over the place.

What surfaced was an issue with an automation we had built, triggered by a constraint on the vendor’s side that was outside our control. But the automation had been a real product improvement. It had reduced time to submit.

So I scoped work that gave users guidance and transparency at the point where the automation could fail, and added a failsafe to catch whatever we hadn’t anticipated yet. I sized the rest of the fix to what engineering actually had capacity for that quarter, not as one large emergency rebuild.

What I’d take from this: finding the root cause protected more than the fix, it protected work that was already paying off. The easy move was to strip out the automation and call it solved. The better one was to keep what worked and fix the one thing that didn’t.