Building in Public Studio: Weekly Portfolio Dispatch
A factual update from our building in public studio. We cover this week's product updates, technical shifts across the portfolio, and the reality of shipping with a small team.

Total Ventures operates differently than a traditional venture firm or a standard software house. We are a building in public studio. This means our work is not hidden behind non-disclosure agreements or multi-year stealth phases. We ship in the open, share our metrics, and document the technical decisions that shape our portfolio of media and software products.
Operating as a building in public studio requires a specific type of discipline. When your progress is visible to other founders and operators, there is no room for filler. You either ship or you don't. This week, we have several updates across the portfolio that highlight our focus on utility and performance.
This Week in the Portfolio
Our team focuses on high-leverage updates that improve the core experience of our products. We do not ship for the sake of activity; we ship to move the needle on specific product goals.
Product Update: Media Property Search
We shipped an update to the search functionality for our primary media portfolio company. Previously, the search results were prioritized by date alone. While this served a chronological purpose, it did not help users find the most relevant evergreen content. We have updated the logic to prioritize relevance based on keyword density and category matching. The result is a more intuitive discovery process for our readers. This was a necessary step as the content library has grown to a size where manual navigation is no longer efficient.
Product Update: Software Tool Billing Logic
For one of our software products, we updated the internal billing logic to handle edge cases in subscription transitions. We noticed that users moving between tiers occasionally experienced a delay in feature access. We refactored the entitlement check to be instantaneous upon the confirmation of the payment event. This removes friction for our most active users and reduces the support burden on our small team.
Lessons Shared: Moving to Unified Aggregates
One of the advantages of running a building in public studio is the ability to apply a single lesson across multiple products simultaneously. When we find a better way to handle data or infrastructure, we don't just apply it to one project; we move the entire portfolio forward.
This week, all 5 projects moved to Firestore aggregates. Previously, we were calculating certain metrics—like total user counts or aggregate engagement scores—by querying the entire collection or maintaining manual counters that were prone to falling out of sync. By moving to built-in aggregation queries, we have simplified our codebase and improved the reliability of our dashboards.
This shift highlights a core philosophy at Total Ventures: prefer built-in platform features over custom-built workarounds. Custom code is a liability. If the managed data layer provides a way to handle a task natively, we take it. This allows our small team to maintain a larger portfolio without increasing the maintenance overhead.
The Operational Reality of a Small Team
Managing a portfolio of purpose-built products requires a ruthless approach to time management. In our building in public studio, we do not have the luxury of dedicated teams for every product. The same people who are refining the CSS for a media site are the ones optimizing the database queries for a software tool.
To make this work, we rely on three principles:
- Standardization: We use a similar architectural pattern across the portfolio. This reduces the cognitive load when switching between projects. Whether we are working on a content site or a utility tool, the folder structure and deployment pipeline remain consistent.
- Shipping Weekly: We maintain momentum by ensuring something of value is shipped every week. If a feature is too large to ship within a week, it is broken down into smaller, functional components. This prevents the "stagnation trap" where a project sits idle for a month while a complex feature is being built.
- Public Accountability: Building in public acts as a forcing function. Knowing that our updates are read by a community of founders keeps us focused on shipping meaningful work rather than getting lost in minor optimizations that don't serve the user.
Why We Build in Public
Many ask why a studio would choose to be so transparent about its internal shifts and technical hurdles. The answer is simple: it attracts the right people. By sharing that we moved all 5 projects to Firestore aggregates, we aren't just documenting a change; we are signaling our technical standards to future collaborators and acquisitions.
We don't post for impressions. We post because a building in public studio is more resilient than a private one. The feedback we receive from the startup community often helps us identify blind spots in our approach before they become expensive problems. It also provides a clear record of our progress, which is more valuable than any pitch deck.
What is Next
Next week, our focus shifts toward improving the onboarding flow for our newest software acquisition. We have identified a drop-off point in the initial setup process and will be shipping a simplified configuration interface to address it. We will also be auditing the performance of the new search logic in our media portfolio to ensure it is meeting our internal benchmarks for speed.
Building in public is a long-term commitment to transparency and execution. We will continue to share these dispatches as we grow the portfolio, one ship at a time.
defaultCta: See the portfolio — totalventures.io
Builder resources
See the full library →
Playbooks, checklists, and tools from running Total Ventures.
Studio Update
What we're building, in your inbox.
Weekly notes on the brands, the stack, and the loop.

