Simon Tam on Produced With

Simon Tam's first job in software ended with him holding an Oscar. He was an intern at Alias Wavefront, the company behind the 3D animation software Maya, in the year it won the award. He had assumed cheap plastic. The statue turned out to be, in his words, "surprisingly really heavy."

Two decades on he is the co-founder and CTO of Saturation.io, which builds budgeting and payments software for the industry that hands those statues out. The route there ran through most of the commercial software business. Flight search came next, at Expedia. Then compilers at Microsoft, in the years C# 2.0 and 3.0 were shipping. At Yahoo he worked first on advertising systems and then on mobile apps, while Marissa Mayer pushed the company's mobile strategy. Big data at Splunk came after that.

He had reached Yahoo through a startup it acquired, which he called "a decent exit across the board." Saturation.io has since reached Top 10 in Ahrefs' Trending SaaS Startups for 2025. Film he arrived at from the outside, a newcomer from tech.

Roughly four years ago a friend introduced him to Jens Jacob as a prospective investor in a project shooting in Seattle, and Jacob talked him out of the film and into the company instead. Appearing on camera for the first time, on Produced With, Tam set out what he looks for in a co-founder, why Saturation shipped things standard startup advice says to skip, and what he thinks the age of AI actually changes.

How he vets values, ego and conflict

Tam and Jacob spent six to eight months getting to know one another before they formally started the company. That caution traces back to earlier attempts of his own that had not worked out. Three things decide it for him before he commits to anything this consuming.

First he looks for aligned values, and he judges them on evidence rather than on stated intent. Both men wanted a product that was aesthetically considered and genuinely usable, a combination rarer among engineers than outsiders assume. Wanting those two things is easy to say, so what he looks for is evidence that a partner has actually built that way. Most engineers, in his experience, care about the beauty and efficiency of the code rather than the user experience.

Second comes flexibility in thought, which is really a question about ego. Two founders can have a hundred or a thousand arguments, but if they cannot converge on an aligned decision the work comes with a lot of pain. The arguments are not the problem; the failure to converge is. Third is how conflict actually resolves between the two of them, and that is the item nobody can evaluate overnight.

Why Saturation shipped dark mode before product-market fit

Some of Saturation's early build decisions ran against standard startup advice. Dark mode shipped from the beginning and the collaborative foundations went in early. "It's like you're trying to build Google Sheets or Airtable from your first MVP," Tam said, conceding that this is not usually wise before a team knows it has product-market fit. A team in that position is normally told to find the fit first and build the foundations later.

A conventional SaaS shape, meaning APIs, CRUD operations and standard server to client communication, would have taken two or three weeks to bootstrap, and it would not have worked. The product had to run offline or semi-offline, feel highly interactive, and feel like people working in a shared space. Who Saturation was actually up against settled it. "We knew that we were competing with the desktop apps, not web apps, like Movie Magic," he said. The comparison was never with other web apps, and those desktop tools set the bar for interface quality.

Still testing an idea? Ship fast and ignore perfectionism. Genuinely convicted? Spend the effort on craftsmanship, because craft is what the conviction is for. A conviction assembled out of money alone, he warned, runs out early. His own came from Jacob's account of the problem: outdated tools, no shared source of truth, and security habits that alarmed a newcomer from tech.

The last 20 percent and the thousand little things

The familiar tradeoff came from Jacob: anyone can get a thing 80 percent of the way, and the remaining fifth costs as much again. Stopping at 80 percent is genuinely standard advice, and Tam accepts as much. Where he lands on it depends on what you are building: "50-50," he said. Anything people call great, though, had a lot of time spent on it. Apple's fine tuning is one example, and Notion is another, since its founder pivoted off a startup that was not working and went to Japan for two years to build the thing properly.

"What makes a good product is not the idea, it's all the little things that go to it. It's a hundred and a thousand little things," Tam said. In film, release is final. In software, release is where the iteration begins, and it begins in public.

Leadership is trust maintenance, not motivation

Most people want ownership of, and autonomy over, the work they were hired to do. That is where a small team's outsized output starts, and both failure modes are about signalling. Micromanaging communicates distrust. So does spelling out every step of a task. Both are messages about the person doing the work, whatever the intent behind them. "People can feel your lack of trust before your words," he said.

He took the method from sports psychology. Great coaches are not more talented than the Olympians they coach, and what they do is simple. Extend genuine trust, say it explicitly, and keep saying it over many cycles rather than once. Give real-time feedback that supplies a framework rather than a verdict.

When someone is off course, give guidance. Withholding it is not kindness: "being nice is actually doing a disservice to them too," he said. Be kind, but firm. Trust rarely fails at the flip of a switch, either; it erodes, slowly enough that nobody announces it. Self-reflection is the remedy, constant and unglamorous.

Four things would count as failure by his reckoning. A conflict can be left unresolved, or a team can devolve into ego battles rather than productive arguments. The software can fall below the standard finance work requires, which fails the customer. And the company can end up somewhere people stop wanting to grow.

The age of AI: from strict inputs to autonomous agents

Mainframes gave way to personal computers, the machine Steve Jobs called a bicycle for your mind. Then the internet, which Tam dates roughly 1995 to 2010, wired all those bicycles together and birthed social media. Mobile put one of those machines in every pocket, which solved distribution. AI was born out of all of it, because it needed both the data and the computational power those shifts produced.

A function or an API takes a strict input and returns a strict output. A neural network takes very wide, flexible input, anything from human language to code to art, and produces very broad output. Where a developer used to write APIs to supercharge a workflow, the model itself now does that work. The wiring a developer used to supply sits inside the thing being called. The next move is from generation to agents that operate tools, hold memory and sit inside a system like a co-worker, and he does not expect the pace to slow.

He and Jacob had both become fathers within roughly the past year, which makes raising children into this a live question for both of them. Tam calls himself an optimist, and puts AI's real power not in generation or efficiency but in the way it shapes your thinking. Learning will become more interactive than the rote model he grew up with.

It can be abused, he accepts, holding that technology is essentially neutral and that the good and the bad come from the interaction models humans build around it. He prefers to call it co-creation.

Key takeaways

• Vet a co-founder over months, not over meetings. Tam and Jacob spent six to eight months getting to know one another before the company formally existed, testing whether values showed up in evidence rather than talk, whether ego blocked a change of mind, and how a disagreement actually got settled.
• Let conviction, not funding, decide how much craft a feature gets. Still testing an idea? Ship fast and ignore perfectionism. Genuinely convicted? Pay for the craftsmanship, because a conviction assembled out of money alone runs out early.
• Know who you are actually competing with. Saturation was built against desktop tools like Movie Magic, which set the bar for interface quality rather than other web apps, so a conventional API and CRUD shape that could have been bootstrapped in two or three weeks was never going to do.
• Pay for the last 20 percent when you actually care. Tam is "50-50" on stopping at 80 percent depending on what you are building, but anything people call great had a lot of time spent on it: Apple's fine tuning, or Notion's founder going to Japan for two years to build the thing properly.
• Say the trust out loud and keep saying it, the way coaches no more talented than their Olympians do. Spelling out every step of someone's job signals the opposite: "People can feel your lack of trust before your words."
• Treat AI as something that shapes thinking, not a generator. A neural network takes input as wide as human language, code or art, where an API took a strict input and returned a strict output, and Tam does not expect the pace to slow.