The Founder Tension Between Persistence and Stubbornness

The difference between persistence and stubbornness is the direction of the founder’s gaze. Persistence is an unwavering focus on the problem you are solving; stubbornness is an unwavering focus on the specific way you initially thought you would solve it. One is a commitment to the mission, the other is a commitment to the ego. In the context of building software over a long time horizon, this distinction determines whether a product eventually arrives at growth or collapses under the weight of its own rigidity.

The Answer: Mission vs. Method

In the middle of the journey—the long, uncertain stretch I call The Long Build—the line between these two traits becomes dangerously thin. To build a product that survives the middle, you must be persistent. You must endure the "platform-changed-yesterday" inputs and the "this worked last week, why not now?" bugs. But if you are stubborn, you will ignore the signals that your current approach is failing. Persistence is staying in the game; stubbornness is refusing to change your play even when you are losing. This is closely tied to the tension between ambition and patience, where persistence provides the patience to endure the work, while stubbornness misdirects the ambition toward the wrong targets.

The Postly Reality: Persistence as Invisible Glue

The easiest lie in SaaS is the phrase "it just works." Users need that feeling, but founders live the opposite. By the time Postly had grown into a serious product, one publishing action was almost never one action. It was a chain of decisions, checks, transformations, and fallbacks hiding behind one button that the user understandably expected to feel simple. That is the real work of product-building. Not making the software do something once, but making it do the right thing repeatedly for the wrong input, the unexpected input, and the half-valid input.

Postly was not one small codebase with one narrow job. It was a working monorepo with a Flutter app, a Serverpod backend, shared models, a public server, and API surfaces. That alone tells part of the story. The real story is what those layers were trying to coordinate. We were not publishing to one social network. We were dealing with Facebook, Instagram, LinkedIn, YouTube, TikTok, X, Threads, Pinterest, Telegram, WhatsApp, Google Business Profile, WordPress, Reddit, Bluesky, and other workflow-specific surfaces. Each of them had different rules, different authentication flows, different media constraints, and different ideas about what "publish" actually meant.

Persistence was the willingness to build far more than a post editor. It meant building platform-specific previews and settings pages for every single network. It meant checking whether a reel required video, whether a YouTube post needed a title, or whether Pinterest alt text was missing. It meant building background publish jobs, retries, and locks to prevent duplicate dispatch. This "invisible glue"—the media proxies, link previews, and cloud storage—is where persistence lives. If I had been stubborn, I might have insisted that the product remain "simple" by ignoring these edge cases. But persistence recognized that the problem we were solving—making complexity survivable for creators—required us to embrace the unsimple systems underneath.

The Persistence vs. Stubbornness Framework

To navigate this tension, you must evaluate your decisions against the feedback loop. Persistence listens to the market and adapts the product to solve the core problem. Stubbornness blocks out the market to protect the original vision. You can test your current path by asking: "Am I holding onto this feature because it solves a user problem, or because I've already spent six months building it?" This is a critical part of how ambition and patience change during a long build. Your ambition must remain fixed on the outcome, but your patience must be applied to the process of iteration.

Failure Modes: When Persistence Curdles

There are two primary ways persistence turns into stubbornness. The first is the Sunk Cost Trap. In a monorepo like Postly’s, where so much work goes into handling exceptions and platform rules, it is easy to feel that you cannot change direction because you have invested too much in the "invisible glue." You begin to value the code more than the customer’s outcome. The second is Identity Fusion. This happens when a founder stops seeing themselves as a problem-solver and starts seeing themselves as the creator of a specific tool. When the tool is criticized or the platform changes (like a token becoming strangely unacceptable today), the stubborn founder takes it as a personal affront rather than a technical requirement.

Building a SaaS product is not mostly about coding features. It is about making complexity survivable for other people. If you find yourself resenting the complexity, you are likely slipping into stubbornness. Persistence finds respect for the software in the act of making it work despite the chaos of external APIs and changing media formats.

Field Notes for the Long Build

• Audit the "Invisible Glue": Regularly check if the systems you built to handle exceptions (retries, media proxies, validation) are still serving the user or if they are legacy weight.
• Separate Mission from Method: Write down the core problem you are solving. If a platform change makes your current method impossible, persistence dictates you find a new method to solve the same mission.
• Accept the Leadership Tax: In a small team, the cost of speed is often the complexity that arrives with growth. Persistence is paying that tax every day without complaining that the work is "too hard."

The middle of the journey is where most founders break while the product is actually starting to work. By choosing persistence over stubbornness, you ensure that you are building a system that can translate a creator's intention into reality without making them feel the pain of that translation. For more reflections on the founder journey and the reality of the long build, continue with the essays at GrowthDiary.

Follow via RSS: latest articles · full article archive