# Meuze — complete site content > Meuze is a creative design firm working across brand, product, and platform. Design and engineering sit in the same practice, so the work ships instead of stopping at a presentation. This document contains every page of https://meuze.com as Markdown, generated at build time from the same source as the HTML. Sections are separated by a rule of equals signs. Contact: hello@meuze.com Canonical site: https://meuze.com Content may be quoted with attribution to Meuze (https://meuze.com). Documents included: 15 ============================================================================== # Meuze — A design firm. We design it, and we build it. > Meuze is a creative design firm working across brand, product, and platform. Design and engineering sit in the same practice, so the work ships instead of stopping at a presentation. ## What Meuze is Meuze is a creative design firm working across brand identity, product design, design systems, and the engineering that puts them into production. Design and engineering are one practice here rather than two departments, which is why the work arrives as running software rather than a specification for somebody else to interpret. We work with founders, product teams, and companies rebuilding something that no longer fits. Meuze is **not** an AI company. It is a design firm. The practice is design and engineering. ## Facts - **Name:** Meuze - **Type:** Creative design firm - **Practice:** Design and engineering combined - **Founded:** 2026 - **Based in:** Toronto, Canada - **Reach:** Working internationally - **Contact:** hello@meuze.com - **Disciplines:** 6 - **Case studies:** shared on request — email hello@meuze.com - **Journal articles:** 2 ## Capabilities - Brand identity and naming - Product and interface design - Design systems and component libraries - Web application development - Mobile application development - Front-end engineering - Back-end and API development - Cloud architecture and deployment - Prototyping and MVP development - Motion and interaction design - Accessibility engineering - Technical SEO and machine readability ## Stack - **Design:** Figma, Design tokens, Component libraries, Prototyping - **Front end:** TypeScript, React, Next.js, Angular, Svelte, Astro - **Mobile:** React Native, Expo - **Back end:** Node.js, REST, GraphQL, Edge functions - **Data:** PostgreSQL, Supabase, Firebase, Redis - **Cloud:** AWS, ECS, Azure, Cloudflare, Vercel - **Delivery:** CI/CD, Docker, Observability, Performance budgets - **Standards:** WCAG 2.2 AA, Core Web Vitals, Structured data ## How we work ### Design and engineering together One practice, not two departments passing files. What gets drawn is what gets built, because the same discipline is responsible for both. ### Shipped, not presented Deliverables are running software and production-ready files. Decks are a means, never the outcome. ### Built to be maintained Documented systems, readable code, and tooling your team can operate long after the engagement closes. ### Real work in round one Applied design in the first round, in the browser where it matters. Not a moodboard. ## Four rounds, start to shipped ### 01 — Scope (Before round one) A short paid diagnostic. Ends with what the problem is, what to build, and what it costs. ### 02 — Direction (Rounds one and two) Two distinct directions, shown applied to real screens and surfaces. ### 03 — Build (Rounds three and four) Design and engineering run together. You review working software, not mockups. ### 04 — Ship (Final round) Launch, documentation, and handover. Your team can run it without us. ## Common questions ### What does Meuze do? Brand identity, product and interface design, design systems, and the engineering to ship them — web, mobile, and the infrastructure underneath. Most engagements combine design and build. ### Do you design and build, or only design? Both, and that is the point of the practice. Design that cannot be built does not survive a sprint, so everything is drawn against what it costs to implement. ### Is Meuze an AI company? No. Meuze is a design firm. We build brands, products, and software, and we care that the results are readable by machines — but the practice is design and engineering. ### How fast do you work? Measured in rounds, not weeks. Most engagements resolve in four: scope, two rounds of direction, two of build. You see real work in the first round. ### What does a project cost? Scoped per engagement after a short paid diagnostic, so the number is set against a real problem rather than guessed. Email us for a range. ### How do we start? Email hello@meuze.com with the problem and its context rather than a specification. You get a reply, not a pitch deck, and the first call is free. --- Source: https://meuze.com/ Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Studio — Meuze > A creative design firm founded in 2026. Design and engineering in one practice. Meuze is a creative design firm working across brand identity, product design, design systems, and the engineering that puts them into production. Design and engineering are one practice here rather than two departments, which is why the work arrives as running software rather than a specification for somebody else to interpret. We work with founders, product teams, and companies rebuilding something that no longer fits. ## Studio facts - **Founded:** 2026 - **Based in:** Toronto, Canada - **Reach:** Working internationally - **Disciplines:** Brand Identity, Product Design, Design & Build, Design Systems, Motion & Interaction, Platform & Cloud - **Design:** Figma, Design tokens, Component libraries, Prototyping - **Front end:** TypeScript, React, Next.js, Angular, Svelte, Astro - **Mobile:** React Native, Expo - **Back end:** Node.js, REST, GraphQL, Edge functions - **Data:** PostgreSQL, Supabase, Firebase, Redis - **Cloud:** AWS, ECS, Azure, Cloudflare, Vercel - **Delivery:** CI/CD, Docker, Observability, Performance budgets - **Standards:** WCAG 2.2 AA, Core Web Vitals, Structured data - **Languages:** English - **Contact:** hello@meuze.com ## What we believe ### Design and engineering together One practice, not two departments passing files. What gets drawn is what gets built, because the same discipline is responsible for both. ### Shipped, not presented Deliverables are running software and production-ready files. Decks are a means, never the outcome. ### Built to be maintained Documented systems, readable code, and tooling your team can operate long after the engagement closes. ### Real work in round one Applied design in the first round, in the browser where it matters. Not a moodboard. ## How a project runs ### 01 — Scope (Before round one) A short paid diagnostic. Ends with what the problem is, what to build, and what it costs. ### 02 — Direction (Rounds one and two) Two distinct directions, shown applied to real screens and surfaces. ### 03 — Build (Rounds three and four) Design and engineering run together. You review working software, not mockups. ### 04 — Ship (Final round) Launch, documentation, and handover. Your team can run it without us. ## Who this suits ### A good fit - You have a real problem and the authority to act on it. - You would rather see working software than a deck. - You want design and engineering answerable to each other. ### A poor fit - You need a fixed specification executed at volume. - Decisions sit with a committee that cannot be convened. - You know the answer already and want it rendered. --- Source: https://meuze.com/studio Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Services — Meuze > Meuze works across 6 disciplines. Almost nobody needs exactly one of them. Design and engineering in one place. An identity question is usually a product question, and a product question is usually a build question. ## The disciplines ### Brand Identity Names, marks, and identity systems built to survive contact with everything else. - **Build iterations:** Two directions, two rounds - **Deliverables:** Naming and verbal identity; Logotype and symbol; Typographic and colour systems; Guidelines and asset library; Design tokens for engineering - **Full detail:** https://meuze.com/services/brand-identity ### Product Design Interfaces designed by the practice that has to make them work afterwards. - **Build iterations:** Continuous, weekly review - **Deliverables:** Discovery and product strategy; Information architecture and flows; Interface and interaction design; Working browser prototypes; Accessibility to WCAG 2.2 AA - **Full detail:** https://meuze.com/services/product-design ### Design & Build Web and mobile applications, designed and engineered in the same practice. - **Build iterations:** Two rounds, then build - **Deliverables:** Design and front-end build; Full-stack web applications; Mobile applications with React Native and Expo; APIs, data modelling, and integrations; Cloud architecture and deployment; CMS and content modelling; Performance and accessibility engineering; CI/CD, monitoring, and handover - **Full detail:** https://meuze.com/services/design-and-build ### Design Systems Component libraries engineers actually reach for, because engineers wrote them. - **Build iterations:** Foundations, then components - **Deliverables:** Design tokens and theming; Accessible component library; Figma library kept in sync; Usage documentation; Migration of existing screens - **Full detail:** https://meuze.com/services/design-systems ### Motion & Interaction How a product moves, defined once and implemented properly. - **Build iterations:** Principles, then passes - **Deliverables:** Motion principles and timing scale; Interface and transition design; Brand and logo animation; Production implementation; Reduced-motion handling - **Full detail:** https://meuze.com/services/motion-interaction ### Platform & Cloud The infrastructure underneath — architected, deployed, and observable. - **Build iterations:** Architecture, then delivery - **Deliverables:** Cloud architecture and environment design; Containerised deployment on AWS ECS; Serverless and edge functions; CI/CD pipelines; Database design and migrations; Monitoring, logging, and alerting - **Full detail:** https://meuze.com/services/platform-cloud ## Four rounds, start to shipped ### 01 — Scope (Before round one) A short paid diagnostic. Ends with what the problem is, what to build, and what it costs. ### 02 — Direction (Rounds one and two) Two distinct directions, shown applied to real screens and surfaces. ### 03 — Build (Rounds three and four) Design and engineering run together. You review working software, not mockups. ### 04 — Ship (Final round) Launch, documentation, and handover. Your team can run it without us. --- Source: https://meuze.com/services Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Brand Identity > Names, marks, and identity systems built to survive contact with everything else. *A design service offered by Meuze, an independent creative design firm.* ## At a glance - **Service:** Brand Identity - **Provider:** Meuze (https://meuze.com) - **Build iterations:** Two directions, two rounds ### Deliverables - Naming and verbal identity - Logotype and symbol - Typographic and colour systems - Guidelines and asset library - Design tokens for engineering --- Identity gets applied by people who were not in the room, on surfaces nobody anticipated. So it is built as a system, not a picture. ## What makes one last - **Hierarchy.** You can tell what matters most on any surface. - **Range.** It handles a dense data table and a launch headline without breaking. - **Documentation.** A new designer picks it up in an afternoon. - **Specificity.** A competitor could not swap their name in. ## Built for engineering Colour, type, and spacing ship as design tokens, not a PDF. The identity arrives in a form the codebase can consume on day one — which is the difference between a brand that holds and one that drifts within two releases. ## Brand Identity: common questions ### How many rounds does an identity take? Two rounds of direction, two of refinement. You see distinct territories applied to real surfaces in round one — not moodboards. ### Do you do naming separately? Yes. A generation round, a shortlist round, then linguistic and preliminary trademark screening with your counsel. ### What do we receive? Production-format assets, a written guidelines document, and design tokens your engineers can import directly. --- Source: https://meuze.com/services/brand-identity Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Product Design > Interfaces designed by the practice that has to make them work afterwards. *A design service offered by Meuze, an independent creative design firm.* ## At a glance - **Service:** Product Design - **Provider:** Meuze (https://meuze.com) - **Build iterations:** Continuous, weekly review ### Deliverables - Discovery and product strategy - Information architecture and flows - Interface and interaction design - Working browser prototypes - Accessibility to WCAG 2.2 AA --- Software gets judged repeatedly. A brand can be right once; a product has to be right on the four hundredth visit, on a bad connection, at the end of a long day. ## How it runs - **Research that can change the brief.** Watching real use, reading the support tickets nobody wants to read. - **Structure before surface.** What information exists, how it groups, what someone is trying to finish. - **Prototypes in the browser.** Timing, loading, empty and error states are design problems that static screens hide. ## Designed against what it costs to build Designs that cannot be built do not survive contact with a sprint. Every screen is drawn against what it costs to implement — so the specification is honest, and so is the estimate. ## Product Design: common questions ### Do you work with our engineering team? Yes, and in their language. Designs arrive as components and tokens, with edge cases, empty states, and error handling already specified. ### Can you build it too? Yes — that is the point of the studio. See Design & Build. ### What about accessibility? WCAG 2.2 AA is the baseline, not a later audit. Contrast, focus order, and keyboard paths are checked as the design is made. --- Source: https://meuze.com/services/product-design Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Design & Build > Web and mobile applications, designed and engineered in the same practice. *A design service offered by Meuze, an independent creative design firm.* ## At a glance - **Service:** Design & Build - **Provider:** Meuze (https://meuze.com) - **Build iterations:** Two rounds, then build ### Deliverables - Design and front-end build - Full-stack web applications - Mobile applications with React Native and Expo - APIs, data modelling, and integrations - Cloud architecture and deployment - CMS and content modelling - Performance and accessibility engineering - CI/CD, monitoring, and handover --- This is the service the practice exists for: the people who draw it are the people who ship it. ## What that changes - **No translation loss.** No spec document, no "engineering interpreted it differently." - **Honest estimates.** Scope is judged by the people who will do the work. - **Faster rounds.** Feedback goes straight into the code. ## How it is built Static-first and server-rendered wherever the product allows. JavaScript is added where an interaction needs it, assets are processed at build time, and pages arrive as complete HTML. On applications that cannot be static, the same discipline applies to payload size, caching, and time to first interaction. ## Infrastructure is part of the design Where something runs shapes what it can do. Architecture, environments, and deployment are scoped alongside the interface rather than handed to somebody else afterwards — which is how a design survives contact with production. ## Readable by machines Search engines and language models are a real share of the audience now, and they read markup, not layout. Semantic HTML, structured data, sitemaps, and plain-text representations ship as standard. This site is the reference implementation — see the [colophon](/colophon). ## Design & Build: common questions ### What do you build with? TypeScript throughout. React, Next.js, Angular, Svelte, or Astro on the front end; React Native and Expo for mobile; Node, PostgreSQL, Supabase, or Firebase behind them. Deployed to AWS, Azure, Cloudflare, or Vercel depending on where you already are. ### Do you work in our existing cloud? Yes. We deploy into AWS — ECS, Lambda, RDS, CloudFront — as readily as Azure or an edge platform. The right answer is usually the one your team already operates. ### Can our team maintain it? That is a design requirement. Every build ships with readable code, infrastructure defined in version control, and a walkthrough. ### Do you handle SEO and AI visibility? Built in. Semantic markup, clean heading structure, schema.org data, server-rendered HTML, and machine-readable formats so search engines and language models read the product accurately. --- Source: https://meuze.com/services/design-and-build Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Design Systems > Component libraries engineers actually reach for, because engineers wrote them. *A design service offered by Meuze, an independent creative design firm.* ## At a glance - **Service:** Design Systems - **Provider:** Meuze (https://meuze.com) - **Build iterations:** Foundations, then components ### Deliverables - Design tokens and theming - Accessible component library - Figma library kept in sync - Usage documentation - Migration of existing screens --- Most design systems fail the same way: they are a picture of a system, not a system. Nobody imports a swatch page. ## What ships - **Tokens** for colour, type, spacing, and motion, consumable by code. - **Components** with states, keyboard behaviour, and ARIA already handled. - **Documentation** covering when to use something, and when not to. ## The test A system is working when engineers reach for it without being asked. That is the bar — not coverage, not component count. Everything here is built to be the path of least resistance. ## Design Systems: common questions ### Is this Figma or code? Both, generated from one source of truth. A token changes in one place and moves through design and production together. ### What is it worth to us? Shipping speed and consistency. A new feature starts most of the way designed, and the slow drift that makes a product feel unmaintained stops. ### Can you work with our existing system? Often the better option. Auditing and repairing what exists usually beats replacing it. --- Source: https://meuze.com/services/design-systems Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Motion & Interaction > How a product moves, defined once and implemented properly. *A design service offered by Meuze, an independent creative design firm.* ## At a glance - **Service:** Motion & Interaction - **Provider:** Meuze (https://meuze.com) - **Build iterations:** Principles, then passes ### Deliverables - Motion principles and timing scale - Interface and transition design - Brand and logo animation - Production implementation - Reduced-motion handling --- Motion is where a product stops being a set of screens and acquires a temperament. The same layout reads as precise or sluggish depending entirely on how it moves. ## Defined as a system - **Easing and duration** fixed as a scale, not chosen per component. - **Transition logic** — what enters, what persists, what is never animated. - **Documented**, so a future feature makes the same decisions. ## Implemented, not handed over Motion is specified in the same tokens the rest of the system uses and implemented directly. That closes the usual gap between the animation that was approved and the one that shipped. ## Motion & Interaction: common questions ### Design or implementation? Both. Motion that exists only in After Effects tends to arrive in production as something slower and worse. Here it ships as code. ### Will it hurt performance? No. Animation runs on compositor-friendly properties with a measured frame budget. If it cannot hold sixty frames per second it does not ship. ### What about motion sensitivity? `prefers-reduced-motion` is respected everywhere, and the reduced state is designed rather than merely switched off. --- Source: https://meuze.com/services/motion-interaction Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Platform & Cloud > The infrastructure underneath — architected, deployed, and observable. *A design service offered by Meuze, an independent creative design firm.* ## At a glance - **Service:** Platform & Cloud - **Provider:** Meuze (https://meuze.com) - **Build iterations:** Architecture, then delivery ### Deliverables - Cloud architecture and environment design - Containerised deployment on AWS ECS - Serverless and edge functions - CI/CD pipelines - Database design and migrations - Monitoring, logging, and alerting --- Where something runs shapes what it can do. Treating infrastructure as a separate phase is how products end up with an architecture nobody chose. ## Scoped with the product - **Environments** that match how the team actually ships. - **Pipelines** so deploying is boring and reversible. - **Observability** from day one, not after the first incident. ## Sized honestly Most products do not need a distributed system. Architecture is scoped to the load the product actually has, with a clear account of what has to change if that load grows an order of magnitude. ## Handed over Infrastructure is defined in version control and documented. Your team can operate, extend, and audit it without us. ## Platform & Cloud: common questions ### Which cloud do you work in? AWS, Azure, Cloudflare, and Vercel. On AWS that typically means ECS, Lambda, RDS, S3, and CloudFront. The right platform is usually the one your team already operates. ### Do you work with managed backends? Yes. Supabase and Firebase are often the correct answer for a product that needs to be in front of users quickly, and both are straightforward to grow out of later if you architect for it. ### Can you take over an existing deployment? Frequently. That starts with an audit of what is running, what it costs, and where the risk sits — then a plan that does not require stopping the product to fix it. --- Source: https://meuze.com/services/platform-cloud Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Work — Meuze > Case studies are published as clients approve them. Relevant work is shared directly on request. Meuze publishes case studies as client approvals come through, which is slower than making the work. No public case studies are listed at present. To see relevant work, describe the problem you are trying to solve to hello@meuze.com. The studio will send the closest comparable project, including the reasoning behind it rather than finished images alone. This is not a statement about the studio's experience or capacity — see https://meuze.com/services.md for the disciplines Meuze works in and https://meuze.com/studio.md for how it works. --- Source: https://meuze.com/work Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Journal — Meuze > Occasional writing on design practice and process. ## Articles ### Designing for machine readers *Published 2026-07-14 by Meuze* A growing share of the people who meet your brand will never see it. They will read a summary a model wrote. That is a design problem. **Read in full:** https://meuze.com/journal/designing-for-machine-readers ### The brief is usually wrong *Published 2026-05-02 by Meuze* Clients are excellent at describing symptoms and unreliable at diagnosing causes. The most valuable round of any project is the one spent finding out what the work actually is. **Read in full:** https://meuze.com/journal/the-brief-is-usually-wrong --- Source: https://meuze.com/journal Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Designing for machine readers > A growing share of the people who meet your brand will never see it. They will read a summary a model wrote. That is a design problem. - **Author:** Meuze - **Published:** 2026-07-14 - **Topics:** Practice, Web - **Publisher:** Meuze — A design firm. We design it, and we build it. --- There is a version of your company that exists only in the answers assistants give about it. Someone asks what your firm does, and a model answers from whatever it extracted from your website. That answer is a brand surface. Nobody art-directed it. ## The plumbing is the design Markup carries meaning, and we have been sloppy about it because the consequences used to be invisible. - A heading that is a `div` with a large font size is meaningless to a parser. - Metadata that lives only in a styled sidebar is ambiguous to everything but a human. - A page that renders after hydration is, to most crawlers, an empty page. None of these are hard. They are just decisions that have to be made on purpose. ## What actually helps - **Ship complete HTML.** If content only exists after JavaScript runs, assume machine readers never see it. - **Use a real heading hierarchy.** One `h1`, descending without skips. Free, and the strongest structural signal there is. - **Say the important thing first.** Models weight early, self-contained statements. A paragraph that only makes sense after three others gets quoted badly or not at all. - **Be consistent about entities.** Same name, same one-line description, everywhere. Writerly variation reads as ambiguity to a system trying to resolve who you are. - **Add structured data.** Boring, and it states unambiguously what a page is rather than leaving it to inference. - **Answer questions in question shape.** If clients ask how fast you work, make that the heading. ## The uncertain part Much of what is sold as AI optimisation is folklore. Conventions like `llms.txt` are cheap and reasonable in principle, but public evidence that major systems consume them is thin — anyone claiming otherwise with confidence is guessing. What is not uncertain is the discipline underneath. Clean semantics, complete HTML, honest structure and clear writing have been the right answer for accessibility for twenty-five years. They are the right answer for search. They happen to be the right answer for machine readers too. The audience changed. The craft did not. --- Source: https://meuze.com/journal/designing-for-machine-readers Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # The brief is usually wrong > Clients are excellent at describing symptoms and unreliable at diagnosing causes. The most valuable round of any project is the one spent finding out what the work actually is. - **Author:** Meuze - **Published:** 2026-05-02 - **Topics:** Practice, Process - **Publisher:** Meuze — A design firm. We design it, and we build it. --- Almost every project arrives with a brief that is subtly the wrong brief. This is not a complaint about clients. It is structural. A company notices a symptom — the site feels dated, the product looks unmaintained, sales says the deck is not landing. Someone has to turn that discomfort into something procurable, so it becomes "we need a rebrand," because that is a thing you can put in a budget line. "Our positioning is unclear" is not. ## Symptoms and causes - A dated-looking site is often a **content** problem wearing a design costume — nobody has updated it because the CMS is miserable. - A product that feels unmaintained is often a **design system** problem, not a visual one. - A deck that is not landing is usually a **story** problem, and no amount of typographic care fixes that. Take those briefs literally and you produce competent work that fixes nothing. The symptom returns. ## What to do about it Put a short, separately-scoped diagnostic in front of every engagement. Three things make it work: 1. **It can conclude you need less than you asked for.** That has to be genuinely available or the round is theatre. 2. **It is priced so stopping is cheap.** If it costs a large fraction of the project, nobody acts on an inconvenient finding. 3. **It talks to people outside the commissioning team.** The person who wrote the brief has a hypothesis. Support and engineering usually have a better one. ## What this looks like in practice A research institute asks for a rebrand. One round in, it is obvious that nobody has trouble recognising the institute — they have trouble finding its research, which lives across three half-abandoned content systems. The identity is fine. The archive is the emergency. The honest proposal is a fraction of the budgeted identity work and a substantial platform engagement instead. Smaller project, much better outcome, and nobody finds it by executing the brief as written. ## The trade Sometimes this talks you out of revenue. Sometimes it surfaces an organisational problem design cannot solve. That is the trade. A studio that only ever confirms the brief is a production vendor with better taste. The judgment is the product. --- Source: https://meuze.com/journal/the-brief-is-usually-wrong Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Contact — Meuze > Email hello@meuze.com. We reply within two business days. Describe the problem rather than the deliverable. A reply, not a pitch deck. The first call is free. ## What to include - **The problem.** Not the deliverable — what is going wrong, and for whom. - **Who decides.** How many people have to approve the work. - **Timing and budget.** A range is fine. "No idea" is also fine — say so. ## Channels - **Email:** hello@meuze.com - **LinkedIn:** https://linkedin.com/company/meuze - **GitHub:** https://github.com/meuze ## Questions we get first ### What does Meuze do? Brand identity, product and interface design, design systems, and the engineering to ship them — web, mobile, and the infrastructure underneath. Most engagements combine design and build. ### Do you design and build, or only design? Both, and that is the point of the practice. Design that cannot be built does not survive a sprint, so everything is drawn against what it costs to implement. ### Is Meuze an AI company? No. Meuze is a design firm. We build brands, products, and software, and we care that the results are readable by machines — but the practice is design and engineering. ### How fast do you work? Measured in rounds, not weeks. Most engagements resolve in four: scope, two rounds of direction, two of build. You see real work in the first round. ### What does a project cost? Scoped per engagement after a short paid diagnostic, so the number is set against a real problem rather than guessed. Email us for a range. ### How do we start? Email hello@meuze.com with the problem and its context rather than a specification. You get a reply, not a pitch deck, and the first call is free. --- Source: https://meuze.com/contact Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com). ============================================================================== # Colophon — Meuze > How this website is designed, built, and made readable by machines. ## Typography - **Display:** Instrument Serif, set tight with negative tracking. - **Text and interface:** Inter, variable weight. - Both are self-hosted as subset WOFF2 files. No third-party font requests. ## Build - **Framework:** Astro, fully prerendered to static HTML. - **Hosting:** Cloudflare Pages, served from the edge. - **JavaScript:** roughly five kilobytes, for the theme toggle, scroll reveals, and the animated hero figure. It is suspended when off-screen. Every word of content is in the HTML before any script runs. - **Content:** Markdown content collections, schema-validated at build time. ## Machine readability A growing share of the people who encounter this site will never see it — they will read a summary generated by a language model. We treated that as a design constraint. - **Complete server-rendered HTML.** Nothing meaningful appears only after hydration. - **Strict heading hierarchy.** One `h1` per page, descending without skips. - **Schema.org JSON-LD** on every page, as a single connected `@graph` so entity relationships are explicit rather than inferred. - **Markdown mirror of every page** at the same path with a `.md` suffix, advertised via ``. - **`/llms.txt`** — a structured index of the site, following the llmstxt.org convention. - **`/llms-full.txt`** — the entire site as one Markdown document. - **`/api/site.json`** — the studio as structured JSON. - **An explicit `robots.txt`** naming ~60 AI crawlers, with an explicit Content-Signal policy. - **Consistent entity descriptions.** The same name, tagline, and description appear verbatim everywhere, generated from one source file. ## An honest caveat Some of the above is convention rather than proven mechanism. Public evidence that major AI systems consume `llms.txt` is thin, and we implement it because it costs a few kilobytes, not because we can prove it moves anything. What is not in doubt is the underlying discipline: clean semantics, complete HTML, honest structure, and clear writing have been the right answer for accessibility and search for decades, and they happen to be the right answer for machine readers too. ## Accessibility - Designed to WCAG 2.2 AA. Contrast, focus order, and keyboard paths checked as part of the build. - Full keyboard navigation with a visible focus ring and a skip link. - `prefers-reduced-motion` fully respected — all animation is suppressed. - Content is readable and complete with JavaScript disabled. --- Source: https://meuze.com/colophon Publisher: Meuze — A design firm. We design it, and we build it. Contact: hello@meuze.com Full site index: https://meuze.com/llms.txt License: Content may be quoted with attribution to Meuze (https://meuze.com).