How I F*****d Up My First Solo SaaS Project as a Project Manager
A first-time PM’s honest breakdown of scope creep, silence, and the cost of protecting a team’s image over a timeline.
A few years ago, I inherited a custom wealth management tool with an accompanying CRM. The design was supposedly finished, and the dev team had just started on the authentication flow when I stepped in.
The timeline: four months, April to July. We delivered in December. Five months late, more than double the original estimate.
Here’s how it happened, and what it taught me.
The Handover
I joined with almost no context. The only project tracking that existed was an Excel sheet someone had built epics into, and that became my source of truth by default, since nothing better existed.
My first move was to go through the client’s existing process documentation and the completed designs. Almost immediately, I started finding gaps. In our scrums, the developers flagged user flows that were missing entirely, flows that would break the system if we built around them as they stood.
So for the first two months, my entire job was: join the scrum, check the ticket board, track the Excel sheet, and hunt for gaps. I was thorough. I was also, in hindsight, solving the wrong problem.
Where I Went Wrong
I wanted to build something excellent. I believed that meant capturing everything the client could possibly need, not just what was documented. So when I discovered that a required report couldn’t be generated because we’d never captured the underlying data, I didn’t flag it as scope creep. I quietly got it added to the design and kept moving.
I had weekly calls with our partner and the end client to show progress. What I never said in those calls was the truth: we had missed requirements, and it wasn’t fully our fault, but I was more afraid of admitting the team had dropped the ball than I was of the risk building underneath the project. So I absorbed it instead of surfacing it.
That decision, more than anything else, is what cost us the timeline. The scope kept growing. The original estimate never got revised to match.
The Compounding
By month three, a significant chunk was done, but the report generation and wealth management core weren’t close. We pulled in a second frontend developer, on top of a team that was already lean: one designer, one QA, one frontend, one backend. This was before AI tooling existed to help absorb any of that load.
I was, to put it plainly, panicking quietly while telling everyone above me that we were “almost there.”
We pushed the client into parallel UAT to buy time. It worked, for a while. Both the end client and our partner were occupied enough that the illusion of progress held.
Then, right before the deadline, our team got pulled onto a different legacy product that was on fire and more urgent. August and September vanished into that fire drill. We didn’t return to the wealth management project until October.
Get Samitha’s stories in your inbox
Join Medium for free to get updates from this writer.
By then, the end client had already tested everything we’d shipped and was sitting on a pile of bugs and feedback we hadn’t touched in two months. Everything hit at once. It escalated. Our CTO got pulled in.
The Reckoning
At that point, I finally laid out the full picture: what was missing, what existed, where things actually stood. The whole team refocused on closing the gap we’d found.
We delivered by the end of November. December became the final UAT phase. From the client’s side, the project that was promised in July landed in November: four months late, full stop.
Internally, that delay broke down into two distinct failures:
- Two months lost to inadequate requirements and the scope creep that followed from trying to quietly fix them myself
- Two months lost when the team was pulled entirely onto a higher-priority project
What I Actually Learned
Know the scope before you touch anything else. Understand exactly what was promised to the client. Check the SOW, the MSA, the WBS, the PRD, whatever exists. If it doesn’t exist, get it from a stakeholder or your manager before you do anything else. This is the single most important thing a PM does at the start of a project.
Anything outside that scope is a negotiation, not a silent obligation. If the client pushes for extras, that’s a conversation to manage, not a gap to quietly absorb. Keep out-of-scope asks low priority and say so explicitly.
Deliver on time, at the agreed quality. That’s the job. Not “as much as I can perfect,” but what was promised, delivered when it was promised.
Align the team around one clear goal, broken into small pieces, and be available for them. Nothing ships without the team, and a team without direction defaults to whatever seems most urgent in the room.
Document risks the moment you see them. Not after they compound.
What Changed in How I Work
A few concrete process changes came out of this:
- PRDs became my actual source of truth, kept current by the design team, replacing the Excel sheet entirely.
- Sprint goals got documented explicitly, not implied.
- A fixed sprint structure: seven days of dev work (day one is planning), a code freeze on day seven, two days of QA on days eight and nine, and day ten reserved for production push and cleanup. Devs could release smaller chunks to QA early, but only QA-flagged bugs got fixed in the final two days.
- Risks go to the client in writing, always. Email chains, documented trails, no verbal-only risk flags that can get forgotten under pressure.
The core mistake wasn’t a skills gap. It was choosing to protect the team’s image in the short term over protecting the project’s timeline, and not realizing until month four that those were never actually in tension. The client would have respected an honest gap analysis in month one far more than a delayed, over-engineered delivery in month eleven.
