Overview

I didn't join Framelabs to design products. I joined to design how the studio itself works. As a founding member, my job was to build the operational, strategic, and creative infrastructure that a young creative VC studio needs to function with discipline and move with speed. Before we could build anything for the market, we needed to know how we'd price work, manage capacity, forecast health, and make decisions without guessing.

So I built that first. Then I built six programs on top of it. All within the span of months. This isn't a story about scaling to millions of users. That's Hexorial. This is a story about designing the operating system of a studio, and then proving it works by shipping from it, fast.

My Role & Leadership Impact

→ Own design P&L impact for Framelabs. Built Vector, the studio's internal operational margin system from scratch, governing pricing, scope, capacity, and forecasting across a single connected architecture. Turned operational discipline from a manual effort into a structural feature. Reduced operational costs by 40%, increased project capacity by 2x, and contributed to 70% growth in inbound partnerships, without scaling team size.

→ Conceived, built, and launched seven initiatives from 0 to 1 in under a year. Designed and shipped Vector internally, then built six market-facing programs: Brand OS, Buildl, RoastStar, Boostara, Pitchiva, and Execova. End-to-end ownership on each: concept, naming, brand identity, positioning, website, copy, GTM strategy, and launch.

→ Led brand strategy, visual identity, and creative direction for Framelabs and all six programs, building seven distinct brand systems that stand alone individually while reading as one ecosystem. Defined how the studio shows up to the market and built a brand foundation that earns trust before a conversation starts.

→ Developed proprietary frameworks for positioning, GTM, and product strategy deployed across every initiative. Cut strategy-to-execution cycles by 50%. Identified market gaps and translated them into new programs, each one a standalone growth engine.

→ Architected the studio's AI-native methodology. Rebuilt the creative pipeline around AI from the ground up. Integrated generative AI into research, ideation, prototyping, and production. Built agent and prompt-based workflows that 10x creative output while maintaining taste.

→ Built internal platforms and systems designed for 10x scale. Reduced design debt by 60%, increased project velocity by 30%, and created infrastructure that compounds, every system we build makes the next one faster.

→ Led cross-functional teams across design, research, and creative. Set vision, establish standards, and build culture. Mentor designers and embed strategic thinking into how the studio operates at every level.

→ Sit at the leadership table. Shape investment thesis, inform decisions, and connect design insights to business strategy. Present to partners and stakeholders. Design isn't support. It's how we see the market, price the work, and decide what to build next.

Vector: The System Behind the Studio

Before I built anything the market could see, I built the thing the studio runs on.

Vector is Framelabs' internal operational margin system. I designed and developed it from the ground up. It governs how we price work, manage scope, allocate team capacity, and forecast financial health. All of it connected. All of it traceable.

Most studios run on spreadsheets, gut instinct, and fragmented tools. Pricing lives in one place. Scope in another. Capacity in someone's head. Forecasting in a spreadsheet nobody's updated since last quarter. That fragmentation is where profit quietly erodes. Not in big dramatic losses, but in small invisible ones that compound until you're wondering where the margin went. Vector eliminates that.

The Philosophy

Building Vector wasn't a linear process. It was iterative, reflective, sometimes frustrating. Over time, three principles emerged, not from theory, but from constraint:

Clarity. Nothing is ambiguous. When you look at a deal in Vector, you see required fee and target margin immediately. When you adjust scope, cost implications surface instantly. When you allocate capacity, overload becomes visible before it becomes painful. Every number is traceable. If margin reads 28%, you can follow the thread back to hours, rates, cost structure, and allocation. No black boxes.

Continuity. Nothing resets. Pricing flows into scope. Scope flows into capacity. Capacity flows into forecasting. Forecasting feeds back into pricing. When you adjust a deal's price, you see the impact on workload immediately. When you increase team allocation, the forecast shifts accordingly. The system behaves like one connected space. You move through it. You don't teleport between disconnected modules.

Consequences. Most tools inform. Vector reveals impact. "This deal reduces blended margin below target." "This team exceeds sustainable capacity next week." "This scenario reduces runway to 8 weeks." We avoid dramatization. We present consequence. When trade-offs are visible before commitment, behavior changes. Operators become deliberate. Decisions become grounded.

The Design Decisions

The hardest part of building Vector wasn't the complexity. It was the restraint.

Vector could have expanded into a full agency ERP. Payroll. Chat. File management. Communication suites. We declined every expansion that didn't directly serve one purpose: protect margin.

This was a genuine tradeoff. Adding a chat layer would have kept conversations in context. A CRM module would have centralized relationship data. But every addition would have diluted focus. In operational software, diluted focus is how you end up with a tool that does everything and disciplines nothing.

One primary decision per view. Every screen in Vector has one job. This sounds obvious until you start building and realize how strong the temptation is to surface "related" information. The discipline is knowing that related doesn't mean relevant in the moment of decision.

Gradual exposure over information overload. Core metrics remain visible at all times: margin, capacity load, runway. Everything else appears when it becomes contextually relevant. A pricing panel surfaces required fee and margin first. Deeper assumptions expand only when you need them. This isn't just a UI pattern. It's how you prevent decision fatigue in high-stakes environments.

Consequences surfaced proportionally. Not every interaction needs emphasis. Sending a proposal should feel composed. Adjusting allocation should feel controlled. But certain thresholds deserve signal. When margin drops below target, the system tightens visually. When overload emerges, affected timelines subtly compress. When runway shortens, projection bands narrow. Overemphasis creates anxiety. Underemphasis creates negligence. Balance creates discipline.

Why Vector Matters for Everything Else

When I cite metrics like 40% reduction in operational costs and doubled project capacity, Vector is the infrastructure that made those numbers real. When I say Framelabs runs lean by design, Vector is how. It's the system that makes lean viable rather than reckless. Without it, a studio our size would be guessing on capacity, rough-estimating margins, and discovering profitability problems after they've already happened.

And here's the connection to everything I built afterward: Vector is why I had the confidence to build six programs in rapid succession. Without operational clarity, building six things in a matter of months would have been irresponsible. I would have been guessing at capacity, hoping the studio could absorb the workload. Vector removed the guessing. I could see in real time how each new initiative affected the studio's financial health, capacity, and runway. That's not bravery. That's informed decision-making.

The Deeper Tradeoff

Building Vector was one of the biggest time investments I made at Framelabs. It's not visible to the outside world. It doesn't have a landing page. It doesn't build the brand's public reputation.

Every hour I spent on Vector was an hour I didn't spend on something market-facing. That's a real cost for a young studio that needs visibility, especially when you've only been operating for months, not years.

The argument for building it anyway: without operational discipline, everything else falls apart. You can build the most interesting programs in the world, but if you don't know your margins, your capacity, and your runway, you're operating blind. And operating blind at a lean studio isn't adventurous. It's negligent.

I chose to build the invisible system first and the visible programs second. That sequencing felt wrong in the moment because everyone could see the programs I wasn't launching yet. Nobody could see the system that would eventually make launching them sustainable.

That's the hardest kind of design work: building something no one sees that makes everything they do see possible.

The Programs: Proof the System Works

With Vector running under the hood, I had the operational clarity to do something ambitious: build six standalone programs from zero in rapid succession, each addressing a different market gap I'd identified.

These programs aren't the main story. They're evidence. They prove that when you build the right operating infrastructure, you can ship at a speed and breadth that would otherwise be reckless. The fact that all six launched within months of each other is a direct result of having Vector, the frameworks, and the AI-native methodology in place first.

• Brand OS (brandos.academy) - An AI-powered brand systems program for founders and marketers. The insight: branding is still stuck in the static deliverable model. Brand OS treats brand as a living, intelligent system. I built the entire concept, methodology, brand identity, website, positioning, and GTM approach from scratch.

• Buildl (buildl.xyz) - A creative accelerator built around sprint programs. Three tracks: Orbis (brand sprint), Bezier (MVP sprint), and Arcadia (product sprint). Each structured to take builders from concept to launch on a compressed timeline. I designed the sprint frameworks, pricing structure, program positioning, and visual identity.

• RoastStar (roaststar.design) - A design, brand, and product critique service. Most teams don't get honest, useful feedback. Internal reviews are biased. RoastStar provides structured, actionable critiques that go beyond what's wrong into what to do about it. Concept through brand, service model, website, and feedback framework, all built from zero.

  
  

• Boostara (boostara.xyz) - An AI-powered brand SEO strategy and growth program positioned around business outcomes rather than vanity metrics. Built for founders and marketing teams who need strategies that convert, not just traffic that looks good in a report.

• Pitchiva (pitchiva.xyz) - A presentation design program for top 1% pitch decks. The insight: most founders lose deals because the story is told badly, not because the product is bad. Built from the brand identity to the service model to the "first 2 slides free" acquisition hook.

• Execova (execova.xyz) - An AI-powered go-to-market strategy engine. The most technically ambitious program. Uses custom AI research agents, predictive modeling, and real-time data to architect market entry. Limited to 5 companies per quarter by design. I built the AI methodology, intake diagnostics, dynamic GTM blueprints, brand, positioning, and website.

The Decisions Behind Building Six at Once

Why six and not one? Focus is the conventional wisdom. We went against it deliberately. A single program would position Framelabs as a one-trick studio. Six programs, each solving a different problem but built on the same methodology, position it as an ecosystem. That's a different kind of credibility.

The tradeoff was brutal on execution. Nothing got 100% of my attention. Each launched at around 80% of where I wanted it. I had to get comfortable with that. The alternative, spending months perfecting one before starting the next, would have missed the window entirely.

But Vector made this possible. Without operational visibility, building six things at once would have been a gamble. With Vector, I could see in real time how each new initiative affected capacity, margin, and runway. Every time I considered accelerating a launch, I checked Vector first. Sometimes it said go. Sometimes it said wait.

How I decided what to build. Each program came from a specific gap. Brand OS from branding being stuck in 2015. Buildl from founders not needing 6-month agency engagements. RoastStar from the impossibility of getting honest creative feedback. Boostara from SEO being either cheap automation or expensive over-promising. Pitchiva from great products failing because the pitch was bad. Execova from GTM strategies being built on gut instinct.

The brand decisions. Seven distinct identities (including Framelabs itself) that each stand alone but feel like the same team built them. Too unified and they feel like features, not programs. Too different and the ecosystem effect disappears. I chose distinct names and visual identities with consistent structural DNA underneath.

The Design Strategy Behind Framelabs

1. Design as the Operating System

Most studios treat design as a deliverable. We treated it as the operating system.

That meant design had to sit at the leadership table from day one. Not reporting to product. Not waiting for strategy to be decided. Actively shaping it.

But earning that seat meant proving value in the language the room speaks: business outcomes. I stopped measuring my work in craft quality alone and started measuring it in operational efficiency, margin health, and execution speed. Vector gave me the numbers to make that case.

That's a mindset shift a lot of designers never make. It's uncomfortable because you're letting go of the thing that gave you your identity. But design leaders who only speak design stay in the design department. Design leaders who speak business shape the company.

2. Building the Studio as a Product

I approached Framelabs the way I'd approach building a product. The studio itself needed design.

Systems before scale. Before we took on more initiatives, I built the internal infrastructure: Vector for operations, frameworks for positioning and GTM, templates for execution, documentation for everything. This is why we doubled project capacity without doubling the team.

The tradeoff was saying no to things we could have pursued. There were opportunities to launch programs sooner, expand faster. I pushed back until the systems were ready. The logic was simple: if we scale on broken systems, we'll spend twice as long fixing them later. Better to go slow now and go fast forever.

Frameworks as IP. The positioning and GTM frameworks I developed aren't just internal tools. They're proprietary methodology. The same frameworks that power how we position Framelabs also power Brand OS, Execova, and every other program. Build the framework once, deploy it across six programs. Each deployment makes the framework sharper.

Design debt as real debt. Most studios let design inconsistencies pile up because they're shipping fast. We treated it like financial debt. Reducing design debt by 60% meant every new program started cleaner, moved faster, and required less rework.

3. AI-Native, Not AI-Adjacent

Most studios bolt AI onto existing workflows. We rebuilt workflows around AI from the ground up.

There were two paths. Path A: use AI where convenient, keep existing workflows mostly intact. Path B: redesign everything with AI at the core.

We chose Path B. Path A is what every studio will do eventually. It's table stakes, not competitive advantage.

This decision directly shaped programs like Execova and Brand OS. They aren't programs that use AI as a feature. AI is the architecture. If we'd chosen Path A, these programs wouldn't exist in their current form.

The key insight: AI doesn't replace taste. It gives taste more surface area to operate on. We 10x'd creative output without sacrificing quality because the human judgment layer stayed intact. The AI handles volume. We handle direction.

The biggest risk we managed: over-reliance. We designed AI workflows to be tool-agnostic where possible. The logic and prompt structures are ours. The specific tools are interchangeable.

4. Brand as a Trust Engine

For a young studio, brand isn't marketing. It's credibility.

This logic extended to every program I built. RoastStar needed to look credible enough that someone would trust it to critique their work. Pitchiva needed to look like it was built by people who know how to make great presentations. Brand OS needed to look like the kind of brand it promises to build.

Interestingly, Vector didn't need this treatment. It's internal. Nobody outside Framelabs sees it. But I applied the same design standards anyway. The interface is clean, intentional, restrained. Not because anyone's watching, but because operational tools that feel sloppy produce sloppy decisions. The design of Vector directly affects the quality of thinking that happens inside it.

5. The Cost of Staying Lean

Vector makes lean viable. Without operational visibility, lean is just a euphemism for understaffed. With Vector, lean becomes a deliberate choice backed by data.

But lean has real costs.

You carry more. Every person wears multiple hats. Vector helps by making capacity visible, but visible doesn't mean comfortable. Seeing that you're at 92% capacity is better than not knowing. It's still 92%.

You can't afford bad hires. On a lean team, one weak hire is a crisis. We chose to wait for the right people rather than move fast with the wrong ones.

You say no constantly. When a new idea comes up, we don't debate whether we have capacity. We check Vector. When it shows we don't, the conversation shifts from "should we?" to "what do we deprioritize?" That's a more productive question, but it means good ideas get shelved regularly.

Key Learnings

Build the invisible system first. Vector doesn't have a landing page. Nobody outside the studio sees it. But it's the reason everything else works. The hardest kind of design work is building something no one sees that makes everything they do see possible.

Operational clarity enables ambition. Building six programs in months sounds reckless. It isn't, if you have a system that shows you exactly what you can absorb. Vector turned ambitious into informed.

Speed is a byproduct of systems. Seven builds in under a year wasn't about working harder. It was about having the infrastructure, the frameworks, and the methodology in place before the building started. Speed without systems is chaos. Speed with systems is leverage.

Design leaders need to speak business. Earning a seat at the leadership table means proving your value in business outcomes, not design awards. That's uncomfortable. It's also necessary.

Restraint is a design decision. Vector could have been an ERP. Every program could have had more features. In each case, restraint was the harder and better choice. Focus preserves identity. Expansion dilutes it.

Consequences change behavior. When people can see the impact of their decisions before they commit, they make better decisions. Not because you told them to. Because the system made the tradeoffs visible. Great software doesn't just execute tasks. It shapes behavior.

Frameworks are the real IP. Build the framework once, deploy it everywhere, sharpen it every time. The positioning and GTM frameworks I built power all six programs and Framelabs itself.

Every decision is a tradeoff. Building Vector first meant delaying visible output. Going AI-native meant disrupting the team. Building six programs meant none got perfected. Staying lean meant carrying more. The job isn't making perfect decisions. It's making clear-eyed ones and living with what they cost.

Thanks for reading and taking the time.

If you’d like to know more about me or dive deeper into my work, feel free to reach out. Let’s connect, share ideas, and explore ways we can work together. Contact me anytime, I’d love to hear from you ♥

PS: I only present a curated set of visual moments from each company, chosen through my lens of perspective and taste. I’m thankful to everyone who’s been part of this journey, and to the tools, resources, and assets that made it possible.

Let’s connect, email me, or DM me on twitter.