The fullpicture brand system

The palette is intentionally constrained. Cream dominates (90%+ of surface area). Teal provides structure and trust. Orange creates moments of energy — CTAs, highlights, the things that matter. Salmon and mint exist as softer variants for supporting roles.

The rule: if everything is colored, nothing stands out. Color is reserved for elements that earn it.

One typeface, no exceptions. Space Grotesk is geometric enough to feel technical, warm enough to feel human, and bold enough at heavy weights to carry a page without images. The brand relies on typographic scale for hierarchy — not color, not decoration.

Bold type carries the message. Color supports. Decoration is optional.

Headlines are weight 700–800, near-black, tight letter-spacing. Body is 400–500, comfortable reading. The gap between them is the hierarchy.

The geometric shape system is fullpicture's most distinctive brand element. Playful blocks with mixed radii — domes, drops, circles, squircles, leaves, flowers — that combine into larger compositions. They're not icons. They don't represent specific things. They're building blocks — atoms that gain meaning through assembly.

The system was designed to feel hand-crafted but systematic. Every border-radius is intentional. Every combination is considered. The shapes live at the intersection of engineering precision and creative play — which is exactly where fullpicture operates.

Individual shapes don't carry fixed meaning — they're interchangeable building blocks. What carries meaning is how they're assembled. The core brand metaphor is the transition from scattered to organized: chaos becomes system, potential becomes delivery, fragments become fullpicture.

The favicon establishes the canonical quartet. These four shapes appear in the logo mark and carry the most brand weight. When you need a representative set of four, you use these.

The transition from scattered to assembled is the brand's visual thesis.

Four shapes scattered = "the problem." Potential energy. Things that could work but don't yet.
Four shapes in a 2×2 grid = "fullpicture." Kinetic energy converted to structure. Things that work.

This transition plays out in the hero animation (chaos → organized), in the philosophy section (day-rate fragments → outcome-based system), and implicitly every time the favicon loads. The 2×2 grid IS the brand mark.

A system with 16 shapes and 4 colors creates 64 shape-color combinations. Assigning fixed, memorable meanings to 64 elements is impossible — nobody remembers that "teal-700 drop-point-br means API integration."

Instead, meaning emerges from context: In the hero, shapes near the BUILD label represent build capabilities. In a case study, shapes next to phase titles mark progression. In the principles section, shapes are just distinguished bullets.

The same squircle can be "backend engineering" in one context and "Phase 2 indicator" in another. This isn't a bug — it's how real visual systems work. A red circle means "stop" on a road sign and "record" on a microphone. Context determines meaning.

These components appear across pages. Their styling is fixed — don't reinvent them.

These partials form the site skeleton. They appear on every page via @@include and should never be rebuilt inline. The header and footer are visible at the top and bottom of this very page.

These components are used across guides, comparisons, and resource pages. They follow the same shape-and-color language but are tailored for long-form reading.

Not everything gets the same spacing. The page uses three rhythm zones:

Tight (hero, headers): 20–32px between elements. Dense, energetic, confident.
Medium (story, body sections): 48px between blocks. Comfortable reading rhythm.
Generous (evidence, transitions): 64–80px between sections. Room to absorb before moving on.

The transition between zones is the page's heartbeat. A section that's all tight reads as frantic. All generous reads as empty. The mix creates breathing.

Animation serves comprehension, not decoration. Things move to show relationships — chaos becoming order, a tab revealing content, a card lifting on hover. If an animation doesn't help someone understand something, it shouldn't exist.

• Spring physics over linear easing. Elements should feel like they have mass.
• GPU-accelerated transforms only. Animate transform and opacity. Never animate width, height, top, left, or margin.
• Meaningful transitions. The hero animation tells a story (chaos → system). Tab switches show content replacing content. Hover states confirm interactivity.
• Duration: 200–400ms for micro-interactions (hover, click). 600–1000ms for narrative transitions (hero toggle, tab switch). Nothing over 1.2s.
• No autoplay loops. Animations trigger on interaction or scroll-into-view, then settle. The page at rest is the page at its most confident.

Build: Shapes fly in from outside the frame and snap into the 2×2 grid. Assembly.

Lead: Shapes are already placed. Connection lines trace between them. Coordination.

Lead + Build: Assembly first, then connection lines appear. The full service.

Solve: A path reveals shapes at waypoints, then snaps them into the grid. Discovery → system.

These animations use the same four shapes and same endpoint (2×2 grid). The animation is the differentiator, not the shapes. The destination is always "fullpicture" — how you get there is the service model.

The .case-card is a single component with a fixed base (header) and optional supplement slots that snap together in different combinations depending on context. The same component serves the index page, the full case study page, and the pricing page — only the slot configuration changes.

Every card starts with a Header (logo + name, always present). On top of that, optional slots are stacked vertically in a fixed order:

The card grows as you add slots. Each row below adds one more supplement to demonstrate how the component scales.

Used on /case-studies/. Visual showcase with mission, client attribution, and industry footer. Quote variant C for the tinted inset style. The visual slot accepts either a screenshot (img) or decorative shapes (.case-card-visual--shapes) for placeholder cards.

Used in the "Explore more" sections at the bottom of individual case study pages. Quote variant C (tinted background). Offering shapes match the final animation state for each service type. KPIs anchor the bottom in a dark strip.

Each offering type is represented by a card with its animated shape group. These cards link to the corresponding section on the pricing page.

Active collaborations show a pulsing green dot in the card footer. Hover reveals a tooltip. Uses @keyframes pulse-ongoing with a 2s ease-in-out loop.

When work was delivered through an agency, the logo slot becomes an interactive .agency-badge. Two same-size logo pills are stacked: the client logo on top, the agency logo tucked behind offset 6px down-left — just enough of its edge peeking out as a curiosity hook. Clicking swaps the deck (300ms ease-out) and reveals a popover with agency details. Dismisses on outside click or Escape.

The .ri-card is used on the resources index page to link to guides and comparisons. It follows the same white-card-on-cream pattern as case cards but is simpler: title, description, optional tool icons, and metadata pills.

Guide cards show author + reading time + date. Comparison cards add a row of tool icons before the metadata. Both hover to teal border with a slight lift.

Container: White background, 1px border (#e5e7eb), border-radius 12px, subtle shadow (0 1px 3px rgba(0,0,0,0.04)).

Hover: Border transitions to teal-400, translateY(-2px) lift, enhanced shadow.

Title: 1.05rem, weight 700, letter-spacing -0.02em. Padded 16px 20px from top/sides.

Description: 0.88rem, weight 400, grey-mid. flex:1 so it pushes metadata to the bottom.

Tool icons: 32×32px squares, border-radius 8px, with centered logo images (14px height) or bold letter fallback.

Metadata: Uses the shared .meta-pills component. Separated from body by a 1px #f0f0f0 top border.

These components are rendered at build time by site-plugin.js from data in src/data/cards.js and src/data/interactive-diagrams.js via <!-- inject:KEY --> markers.