The useful contribution was a spike

In March 2026, we were working on bringing Bookerish into Whop. The main Bookerish application already worked. The integration was taking shape, but something about its architecture felt wrong.

Correcting that new work could easily become an invitation to rebuild everything around it. I was explicit about the constraint: protect the working application. Whatever we changed needed a clear boundary.

The architectural discussion involved GPT, material quoted from Cursor, and the live Cursor exchange. Several contributions went into the proposed separation between the main product and its embedded client. One suggestion in the live exchange was particularly useful: do a spike.

I said I was unfamiliar with the term. Cursor explained it as a short, bounded investigation of an uncertain assumption before committing to the next implementation step. We needed to establish whether the integration had access to the user context a planned connection would require.

I agreed to put the spike into the plan.

Later, when Cursor presented the possible next phases, I reaffirmed that we had agreed to do the spike first. The check already had a place in the plan. It still needed to determine what happened next.

Looking back, that distinction is the useful part for me. Agreeing to investigate an assumption and allowing the investigation to govern the sequence are separate decisions. The first puts a check on a list. The second gives its findings a chance to change the work.

Cursor subsequently reported that the expected context was absent in the environments it had tested. We used that reported finding to defer the planned connection and proceed with a narrower cleanup of how the embedded client obtained its data. I confirmed that the refactor was confined to that client before approving it.

The resulting code change removed the client's separate data-access path in favor of using the existing Bookerish backend. That was a concrete change we could inspect. It did not independently verify the spike's findings or establish that the whole integration was solved.

Further work on rendering and parity with the main application followed. Deferring the connection did not mean abandoning it permanently. The check had changed the immediate sequence; it had not eliminated the remaining integration work.

A spike is ordinary engineering practice. What mattered here was how it entered the collaboration. Cursor proposed the technique, I accepted it and reaffirmed its priority, and the reported finding affected the next decision. The broader architecture had several contributors. This particular procedural contribution could be identified without assigning the model credit for inventing the practice or solving the product.

There is no defensible number here for hours saved. The more modest result is visible: we investigated an assumption before agreeing to the dependent connection, then changed what we would do next. The existing application remained the boundary around the work we authorized.