Shipping version one is the only version

I had a whiteboard in my office when I was building BoardSnap that was full of features I wanted to ship in v1. Features I thought were essential. Features that made intuitive sense.

The shipped version of BoardSnap v1 had about 40% of those features.

Here's what I cut, why, and what shipping without them taught me.

### Cut 1: Team collaboration

The original design had real-time board sharing — multiple users in a Project, see each other's edits to action items live. Like a collaborative document.

I cut it because: the infrastructure cost was high, the design complexity was high, and I had zero evidence that the first hundred users would need it. Most of my beta users were individual contributors using BoardSnap personally.

What shipping without it taught me: the first version of "sharing" users actually wanted wasn't real-time collaboration — it was one-tap sharing of the summary to Slack. That's a 30-minute feature, not a 4-week feature. I shipped it in week 3.

### Cut 2: Jira and Linear integration

I had the integrations half-built. Users could push action items directly to Jira or Linear with ownership and due dates mapped.

I cut it because: OAuth integration complexity was delaying the launch by three weeks, and I had no data on whether users wanted push-to-Jira or just copy-to-clipboard.

What shipping without it taught me: most users copy to clipboard and paste. A few users are asking for native integration. But the few who are asking are Pro users — high-value, high-signal. I'm building the integration now, with real usage data to spec it correctly.

### Cut 3: Board templates

Pre-built board templates — sprint retro, standup, brainstorm — that would guide teams in setting up the physical board before the session. The template would suggest column headers, recommend a time per section, etc.

I cut it because: BoardSnap reads boards, it doesn't create them. Getting into the "how to run a session" business was adjacent to my core value but not core. I was adding scope to solve a problem I wasn't sure users had.

What shipping without it taught me: nobody has asked for templates. The use case I imagined — users consulting BoardSnap to set up a board before the meeting — isn't how people use it. They're using it after. The templates would have been unused.

### Cut 4: Multi-board synthesis

A feature to synthesize across multiple boards in a project — "summarize everything that happened this week" or "what are the open items across all this month's boards?"

I cut it because: it required users to have enough boards to make it useful, and no user had that volume at launch. Building for a future state that required substantial usage history was premature.

What shipping without it taught me: the AI chat already does this informally. Users are typing "what are the open items across this project?" into the chat, and it works. The formal feature I imagined is less necessary than I thought because the chat interface is a natural language interface to the same data.

### The pattern

Looking at these four cuts: in every case, shipping without the feature taught me something that changed the spec of whether or how to build it later. In two cases (templates, multi-board synthesis), I learned the feature wasn't needed. In two cases (integrations, collaboration), I learned what form the feature should actually take.

The version I never ship teaches me nothing. The version I ship gives me the data to build the right things next.

Ship the core. Cut the theoretical. Listen to what users actually do.