What co-founding taught me about shipping

Before Paiv, I co-founded a startup called Prior and built its product end to end. I owned every technical decision from the frontend to the infrastructure — Next.js, TypeScript, Supabase, and a few things I'd never shipped before. The product's run has ended, but the lessons are some of the most useful I've carried forward.

Schema decisions are the ones you live with

The earliest decision with the longest shadow is your data model. I spent real time up front architecting a flexible relational schema, because I knew the product's data would evolve in ways I couldn't fully predict. That paid off: complex, changing requirements turned into normal feature work instead of painful migrations.

If I could give early-me one piece of advice, it's that the schema is where optimism goes to die. Design it so that "we need to also track X" is an additive change, not a rewrite.

Meet users where they already are

One of my favorite things I built was an interactive email experience using AMP for Email. Instead of a "click here to go to the app" link, recipients could take action directly inside their inbox. It's a small thing that changes the feel of a product — less friction, more "this just works."

It also forced me to learn a corner of the stack most engineers never touch, which is its own reward.

Shipping is a skill, separate from building

Here's the thing nobody tells you: writing the code is not the same as shipping the product. As a co-founder there was no one to escalate the hard calls to. You scope ruthlessly, you decide fast, you cut things you're attached to, and you put it in front of users before you feel ready.

That muscle — turning ambiguity into a deployed thing that real people use — is the part I kept. It's why I now reach for "what's the smallest version that's real?" on every project, including the ones I build just for me.