I spent three weeks building a custom calendar sync feature for a HubSpot integration project back in 2019. It was beautiful. Two way sync, conflict resolution, timezone handling, the works. I even added a smart scheduling algorithm that predicted optimal meeting times based on past behaviour.

Usage in the first month: zero. Second month: one user, who turned it off after two days.

What I built versus what they needed

The client had asked for better calendar integration. I heard that and immediately thought about all the edge cases. What if someone edits an event in both systems? What about recurring meetings? Different timezones?

I built solutions for problems that existed in my head, not in their actual workflow.

Turns out they just wanted to see their HubSpot tasks in Google Calendar. That's it. A simple one way sync would have taken four days. I spent three weeks because I was building for an imaginary power user.

The part that stung: I had checked in with the client twice during development. Both times I demoed the complex features. Both times they nodded and said it looked great. Nobody wants to tell you that you're overbuilding when you seem excited about it.

The discipline I should have had

Shipping something people actually use requires a different muscle than shipping something technically impressive. Here's what changed in how I scope features now:

  • I write down the simplest possible version that solves the stated problem. Not the implied problem. Not the future problem. The one they said out loud.
  • I put a complexity budget on every feature. If my first pass exceeds it by more than 30 percent, I stop and verify scope before writing more code.
  • I ship the basic version to at least three real users before adding enhancements. Not a demo. Actual usage in their workflow for at least a week.
  • I track one metric that proves the feature solves the problem. For that calendar sync, it should have been "percentage of tasks that get completed on time." I didn't track anything.

This approach has killed features I was excited about. Last year I wanted to add AI powered lead scoring to a GoHighLevel setup. Spent two days on a prototype. Put it in front of users. They didn't understand what the score meant or how to act on it. Saved myself two weeks by validating early.

The thing that still does not work

I still struggle with this on internal tools. When I'm building something for my own workflow, I add every bell and whistle. My current time tracking script has 847 lines of Python and generates reports nobody asked for, including myself.

Apparently I need external accountability to ship lean. Building in public helps with that.

What shipping actually means

Shipping is not about pushing code to production. It's about putting something in front of people who have the problem you think you're solving, then watching what they do with it.

The calendar sync taught me that being proud of your work and building something useful are related but different goals. You can feel both. But if you only feel one, make sure it's the second one.

Practical takeaway: Before you build the thing, write one sentence describing how you'll know it worked. If you can't measure it or observe it in user behaviour, you're not ready to build it yet.