The client project that almost broke the team, and the tool I built because of it
Seven months. That's how long it took for a client project to go from “this is going to be great” to “our jobs are on the line.”
I lead product design at a company that builds for enterprise clients: products, automations, AI systems. We took on a compliance automation platform for a cybersecurity agency. The brief was ambitious but clear: build a GRC tool that automates their entire compliance workflow across six international standards. Think Vanta or Drata, but tailored for their specific consulting process.
We had a team. We had a stack. We had a plan. What we didn't have was a system to protect us from the slow, invisible collapse that happens when a client engagement goes wrong in ways nobody sees coming.
How It Started
The first meeting was electric. The client walked us through their pain points: mountains of documentation, endless back-and-forth on risk registers, evidence collection that consumed entire weeks. They wanted a platform that would cut their compliance lifecycle from months to weeks.
We dove in. I led the product design. We shipped features fast: onboarding flows, assessment modules, risk registers with AI-generated scenarios, evidence upload systems, gap trackers, document versioning. The app was taking shape. For the first two months, things moved.
Then the drift started.
What Actually Went Wrong
If I had to pin it down to one sentence: nobody locked anything. Requirements kept shifting, not dramatically, but consistently. A new standard added here. A module scope expanded there. Features that were post-MVP quietly became assumptions. Meeting notes existed, but nothing was formally acknowledged. Nobody signed off on anything.
The Real Problem Wasn't Technical
I could list the technical challenges: broken modules, missing API integrations, AI features that needed prompt engineering. But those weren't what almost killed the project. The real failures were structural.
No locked requirements
At no point in seven months did anyone produce a document the client formally agreed to. Requirements lived in meeting notes, WhatsApp threads, and verbal conversations. When the client said 'we told you this from the beginning,' there was no way to prove otherwise.
No demo-to-approval loop
We showed things. We demonstrated features. But showing isn't approving. The client could always say 'we saw it but never accepted it.' There was no mechanism to turn a demo into a sign-off.
Silence was treated as progress
When the client went quiet for two weeks, we kept building. But silence wasn't approval. It was either indifference or brewing dissatisfaction that would surface later as 'you didn't build what we asked for.'
Scope changes were invisible
Every new request was absorbed into the existing timeline. Nobody said 'this is new scope, it adds time.' Three weeks of unplanned work crept in incrementally, invisibly, with no paper trail.
Payment was decoupled from milestones
No milestone, no invoice trigger. Payment became a negotiation instead of a contractual obligation tied to delivered work.
The Moment It Clicked
During the crisis period, while I was heads-down trying to figure out how to deliver everything in four weeks, I realized something. Every single problem I was dealing with was a documentation problem. Not a code problem. Not a design problem. A documentation problem.
If I had a system that made the client formally acknowledge what we were building, turned every demo into an approval checkpoint, and flagged every new request as a scope change with a timeline impact, none of this would have happened.
That's when I started building ShipLock.
What ShipLock Is
ShipLock is a client delivery protection system. Not a project management tool. Not a CRM. Not a document management system. It answers one question: can the client deny that we built what they asked for?
If the answer is ever “yes,” ShipLock has failed. It sits on top of your existing workflow and enforces one principle: nothing exists unless it is documented, acknowledged, and traceable.
The Core Mechanics
Upload the client's requirements document. AI extracts every individual requirement and turns each one into a trackable item with a unique ID. The client has to explicitly approve or dispute each one.
48-hour rule: if the client doesn't respond, the requirement is auto-approved. Their silence becomes consent.
Record a demo for any feature. Send it to the client. They watch, comment, approve or reject. Same 48-hour rule applies. 'We demonstrated it' becomes a documented fact with a timestamp and an approval record, not a he-said-she-said.
When a new request comes in that isn't in the approved requirements, the system flags it as a scope change and forces a timeline impact estimate. The client has to acknowledge that impact before work begins.
Paste any meeting notes or emails. AI scans for drift and flags anything that doesn't match the approved scope.
Every time something is sent to the client, a timer starts. Green for the first 24 hours, yellow at 24, red at 48, auto-escalation at 72. This creates a visual record of client responsiveness visible to everyone on the project.
Real-time view of what's blocked and by whom. The 'Blocked by Client' indicator isn't accusatory, it's factual. When an executive asks why the project is delayed, the answer is on a dashboard, not in someone's memory.
The First Project It Protected
I loaded the project into ShipLock: 31 requirements extracted from the client's 40-page document, 55 tasks across a four-week sprint. When I opened the dashboard, I could see the story of the project in a way I never could during the actual engagement.
31
Requirements extracted
55
Tasks across 4 weeks
3 wks
Unplanned scope added
7
Undocumented scope changes
22 of 31 requirements were MVP scope. 9 were post-kickoff additions the client pushed for. Those 9 additions added roughly three weeks of unplanned work — quietly absorbed into the existing timeline without a single scope change record.
Having all of this in one place, with timestamps and impact assessments, changed the conversation entirely. It went from “you didn't deliver” to “here's what was agreed, here's what was added, here's the impact, here's what we shipped.”
What I'd Do Differently
Lock the requirements on day one
Not in a Google Doc that gets edited 47 times. In a system where each requirement has a status, an owner, and a timestamp, and the client has to click Approved or Disputed on every item.
Make silence expensive
The 48-hour auto-approval rule is the single most important mechanic. It flips the default from 'nothing is agreed until the client says yes' to 'everything is agreed unless the client says no.' This one change would have prevented the entire 'we never approved this' situation.
Track scope changes from the first meeting
Every new request, no matter how small, should trigger a scope change record with a timeline impact. Not to say no, but to make the expansion visible. When a project is three months late, the answer should be on a dashboard, not in someone's memory.
Why This Matters Beyond My Project
Every team that builds for enterprise clients has this problem. The specifics vary: maybe it's a redesign, maybe it's a mobile app, but the pattern is identical: vague requirements, silent feedback, invisible scope expansion, and blame that falls on the people doing the work.
This isn't a people problem. I liked my client. Their team was knowledgeable, their domain expertise was deep, and their vision was legitimate. The problem was structural. There was no system enforcing alignment between what was agreed and what was expected. ShipLock is that system.
The lesson
Building the right thing isn't enough. You have to prove you built the right thing. And you have to make that proof impossible to deny.
ShipLock is being built on Next.js, TypeScript, PostgreSQL, and Tailwind. The first version is an internal tool for the projects I lead. If it works, and I think it will because it was built from real pain not imagined problems, it becomes a product.
Every team that's ever had a client say “that's not what we asked for” needs this. Every design lead managing a dev team across a long engagement. Every product manager who's watched scope expand invisibly while the deadline stayed fixed.
I learned the hard way that building the right thing isn't enough. You have to prove you built the right thing.