Open source can look irrational from the outside. A company spends months or years building software, then puts the code on GitHub for anyone to inspect, run, change, or fork. Theo's answer is that the code is rarely the whole product. It is one part of a larger strategy for earning adoption, trust, feedback, and eventually revenue. The mistake is to treat open source as either pure generosity or an automatic business model. It is neither.
There is no single level of open
Theo starts with his own products. T3 Chat is not fully open source, although he has shared substantial code and explained how it was built. UploadThing exposes the client-side packages people use, while keeping other pieces closed. Other work, including Create T3 App, is fully open. The decision is not a badge a startup earns once. It is a product, operations, and business decision that can differ across the same company.
PostHog sits toward the more open end of that range. As Theo describes it, much of its code and work is public, while some pieces use separate enterprise licensing and a full self-hosted setup still has real operational complexity. That complexity matters. Seeing source code is not the same as taking over every responsibility of running a service.
Open source gets a startup in front of the people who try new things first
Theo frames this through the technology-adoption curve. A young developer tool should not expect the late majority to switch first. Its earliest users are innovators and early adopters who enjoy testing new tools, breaking them, inspecting them, and making them fit their work. Open code is appealing to exactly that group because it lowers the feeling of risk. They can see the internals, check the direction, and keep some control if the company changes course.
That does not mean a product can stay with innovators forever. A business has to build a path from curious early users to customers who need simpler onboarding, familiar workflows, support, and less technical effort. Theo uses T3 Chat as an example. Features such as shareable gift subscriptions and a mobile app matter less to an experimenter than to someone trying to introduce the product to a less technical user.
Open source can be an effective starting point. It is not the whole route to a durable market.
- Give the innovators a reason to try the product and believe its claims.
- Learn what keeps those users engaged after the first experiment.
- Build the onboarding, reliability, and convenience that later users need.
- Charge for a service or outcome that remains more valuable than running the software alone.
Public code makes a company easier to trust
Developers are skeptical of vague product claims. Open source can turn a promise into something they can inspect. Instead of saying that a fix is coming, a company can link to an issue or pull request. Instead of making a buyer trust a sales pitch, it can show the code, the release cadence, pricing, and even parts of how the team works.
That transparency is especially helpful for a product that developers will place inside their own stack. They can audit behavior, understand an edge case, and answer some questions without waiting for support. Theo's view is blunt. If explaining what you are doing would destroy your advantage, the company may not have a durable advantage in the first place.
It also turns hiring into a two-way evaluation
A startup needs people who can change the outcome, not only fill a role. Open source creates a public record of how a contributor thinks, ships, reviews, and collaborates. That makes it easier for the company to notice strong people before an interview process begins. It also lets a potential hire see the codebase and working habits before accepting an offer.
Theo points to Create T3 App contributors who later became important parts of his team and community. PostHog's story includes a similar example, where an engineer found the project on GitHub, became interested in the problem, and eventually joined. The company gets signal. The contributor gets a way to show work that a resume cannot capture.
When a customer can see the work, comment on it, and contribute to it, the relationship changes from vendor and buyer into a shared effort to make the product better.
Feedback gets faster when the customer can participate
The video gives a concrete example from PostHog's AI wrapper. Theo's team needed support for a new version of the AI SDK and had run into edge cases. In a closed product, the exchange might be a ticket, a promise, and an unclear wait. With code and issues in public, the path can be more direct. The vendor can explain its plan, the customer can test or submit a pull request, and both sides can see what changed.
This helps more than support. A customer whose contribution is in the product becomes more invested in it. They are more likely to give feedback, recommend it, and stay involved. PostHog also makes room for contributions that are not code, including documentation and community work. That matters because the useful people around a product do not all have the time or skill to modify its source.
Openness creates obligations as well as goodwill
A company that calls itself open source creates an expectation of consistency. Theo notes that people can become more upset when an open product closes off parts of the stack than they would have been if it had started closed. The community has not only downloaded code. It has made decisions around a public promise.
That does not require every startup to publish every line. It does require a clear boundary. The license, the hosted service, the enterprise features, and the roadmap need to make sense together. PostHog's stated approach is to keep the company alive, explain how open source works, and maintain the same license as it grows.
The business model is usually convenience, not hidden code
Monetization is the hard part. According to the PostHog account Theo reads, the company tried enterprise plans, paid self-hosting, and cloud hosting before settling on the cloud. The source stays available, but most customers choose the hosted service because operating the system takes time, expertise, compliance work, and ongoing attention. A generous free tier can attract users while a smaller group pays for the convenience and scale of the managed product.
Theo brings up Convex as a useful extreme. Its founders work to make the product easier to deploy on other clouds, even though that makes self-hosting more viable. The bet is that many serious teams will still choose the hosted option because they would rather spend their time on their own product. Open code becomes a credibility advantage. The service remains the thing many customers prefer to buy.
Open source works when it gives users more confidence and control than it gives away in value.
For a developer startup, publishing code can be a strong way to reach early adopters, prove that the team is serious, recruit talented people, and turn feedback into product progress. It still needs a real business underneath it. The durable version is not "give it away and hope." It is to be clear about what people can run themselves, what the company will operate for them, and why the hosted product is worth paying for.