Context
During an internal hackathon at Zipy, I was paired with an intern to build a Node.js backend monitoring SDK — the server-side counterpart to our browser SDK.
The problem
The ask was the whole pipeline: the SDK, a producer, a consumer, a database schema, APIs and a frontend. In three days.
I did the math. All of that, from scratch, in three days, was only possible as a demo — something that works once on stage and nobody uses afterwards.
What I did
I went to the CTO. Not to say the deadline was unrealistic, and not with a bigger number I'd justify afterwards. I brought a breakdown of what was genuinely new versus what we could assemble from what we had:
- Producer and consumer already existed for the browser SDK. Reuse them, with one new Kafka topic for backend events.
- Database schema already existed. Reuse rather than redesign.
- Frontend goes to the intern — right-sized for his level and independently verifiable. I specified the schema and API shape up front so he had a fixed contract, not a moving target.
- The SDK itself was the one genuinely new component. I'd build it.
Sizing that one new piece is where "a week" came from.
Outcome
The CTO agreed. We shipped a Node.js SDK customers could actually plug into their own backends, with time left to test it properly.
What I learned
Pushing back well isn't declaring a deadline unrealistic. It's separating what's new from what's assemblable, and bringing that breakdown instead of a complaint. Had the answer been no, I'd have built the demo and been explicit that that's what it was — the failure I was avoiding was shipping something that looked finished and wasn't.