What an agency cannot ship, no matter how clean the code, is a group of people who, over time, become part of the problem with you. That is what the title “founding engineer” aims to capture, and it is the part of the job hardest to explain to engineers considering making the same move.

When I moved from running an agency to a founding engineer role at a consumer AI startup, the work looked the same on paper. Code, features, production. But something shifted in what you’re allowed to ignore. The shift sits somewhere harder to point at, in what you start noticing during the day and what you no longer allow yourself to walk past without comment.

The onboarding flow that taught me the difference

A few months into the role, I built a new onboarding flow for our product: design, code, ship. The flow worked as intended. Then we launched it, and as the numbers came in, the ad bringing users into that onboarding was clearly underperforming, for reasons unrelated to the flow itself.

Inside an agency, that observation would have stayed in my head, because the ad was not part of the brief I had been hired against. Pointing it out would have meant overstepping a boundary that exists for good reasons. Inside a product company, staying quiet about something I could see was hurting the product, which would have been a small but real failure. So I raised it with the team, we tried a different ad, and the numbers moved.

Caring about the parts you did not build

The lesson has little to do with my advertising judgment and a great deal to do with which observations you treat as relevant to your job. If you picture the product as a sequence of steps a user moves through, from first seeing an ad to becoming a paying customer, agency work asks you to be excellent at your step and largely indifferent to the others. Founding engineering asks you to care about the neighboring steps, because how they perform changes what your own work is worth. The difficulty here is not technical. It comes from how the two roles are paid and measured, which pulls your attention in opposite directions over time.

Why do the reward structures point you in opposite directions

Agency work pays you to finish projects on schedule and find new clients to fill the pipeline behind them. Once the brief is met, the project’s future life becomes interesting to you mostly as a question of craft, and whether the thing you built gets used or quietly shelved is the client’s problem. There is nothing dishonest about that mode of operation, because the contract is clear, and it is what you are paid against.

Founding engineering inverts that arrangement. The product’s trajectory and your own work become the same variable, meaning that if the company does not grow at the rate it needs to, your work was part of what prevented it from growing. There is no clean boundary between the quality of what you shipped last month and what happened to the business afterward.

The cost the pitch leaves out

Ownership in practice means caring about outcomes you cannot fully control. Markets move in ways nobody predicted, users behave differently than your model suggests, and a competitor ships something on a Tuesday that resets the conversation everyone was having on Monday. You do work you are proud of, you watch what happens next, and that next part is still yours to carry.

A quiet question tends to sit at the back of your head during those stretches: did I give enough input, could I have pushed harder on the advertising, the pricing, or the flow? You do not get a clean answer. The founding engineer’s pitch usually emphasizes the scope of touching the whole product, and that part is real. What gets left out is the psychological cost of never finishing a project the way you used to.

A note on voice versus authority

Formal authority is not the mechanism that lets you contribute outside your stated scope. You will not be the product owner, and someone else on the team will have judgment on product calls that outweighs yours when the two of you disagree. The change is that your voice is in the room when decisions are being made, and when you flag an ad that isn’t working or a step in the product where users are dropping off, the team takes it seriously because you are part of the problem alongside them.

The work itself is largely the same in terms of what you spend your hours doing at a keyboard. What changes is whose problem the outcome becomes once the code is in production. If that trade appeals to you, the role is worth pursuing.

About the author: Pavel Shchekotov is a founding engineer focused on building AI-native consumer products, including conversational AI systems and generative AI tools for product growth and user engagement.

Read the full article →