Shipping like a founder, even as an engineer

I’ve spent most of my career as an engineer at other people’s companies, and on the side I build products of my own — most recently PostKite, an AI-powered social media tool. People sometimes ask how the two modes differ. The honest answer: less than you’d think, if you bring a founder’s instincts to both.

“Think like a founder” has become a hollow phrase on job descriptions. Here’s what it actually means to me in day-to-day work.

Start from the user’s bad day, not the architecture

Engineers love starting from the system: what’s the schema, what’s the API, what’s the cleanest abstraction. Founders start from a person having a bad day and working backwards to the smallest thing that fixes it.

When I built PostKite’s scheduling flow, the architecture-first version would have been a beautiful generic job queue. The founder-first version was: a person has twelve posts and no time, and wants to set them and forget them. That reframing killed half the features I’d planned and made the other half obvious.

”Done” is a negotiation with reality

Engineering culture treats “done” as a fixed bar — tests pass, code reviewed, edge cases handled. Founders know “done” is whatever ships value without breaking trust. Those are different bars, and pretending they’re the same is how projects miss their window.

That doesn’t mean shipping garbage. It means being ruthless about which polish matters. The encryption in Datash had to be right — it’s a file-transfer tool, trust is the whole product. The animation on a settings toggle did not. Knowing the difference is the skill.

Own the whole line

The most founder-like thing an engineer can do is refuse to stop at the edge of their ticket. The database, the service, the UI, the deploy, the error someone hits at 2am — it’s all one line, and value only shows up when the whole line works. I’ve found my most useful contributions almost always live in the seams between layers that everyone assumed were “someone else’s part.”

You don’t need a title or a cap table to work this way. You just need to care about the outcome more than the boundary of your job.