Should the MVP use your real brand, or a placeholder one?

Founders often assume an MVP needs full brand polish to be taken seriously, or conversely, that brand doesn't matter yet since it's "just a test." Neither is quite right. The actual answer depends on what you're testing: whether people want the product at all, or whether people trust your specific brand enough to try it.

If you're testing a functional assumption, whether a workflow solves a real problem, whether people complete a specific task, a clean but unpolished visual treatment (a solid, simple design system rather than a fully custom brand identity) is usually sufficient, and spending real budget on brand polish before validating the core function is money that could have tested the actual open question instead.

For products in categories where trust is a major adoption barrier, financial products, health products, anything asking users to share sensitive data or money early, a rough, unpolished visual presentation can itself suppress adoption independent of whether the core product idea is sound, muddying your test results. In these categories, a baseline level of professional polish is part of the actual variable under test, not a separate concern.

Most MVPs land somewhere in between: not a full brand identity project, but a real name, a clean wordmark, and a consistent, simple color and type system, built in days rather than weeks. This is usually enough to avoid trust being an unwanted confounding variable, without spending MVP budget on brand work that may need to change anyway once you've learned more about the actual product and audience.

Unless the product category specifically requires early trust signals, we default clients toward a lightweight real identity over either extreme, fully placeholder or fully polished, since it keeps the test focused on the actual product question while avoiding a visibly unfinished experience that can itself become the story users tell about why they didn't convert.

Once the core assumption is validated and you're moving from MVP to the real product, that's the right moment for a fuller brand investment, informed by what you've actually learned about who your real users are and what resonates with them, rather than guessing at brand direction before you have any real user data to inform it.

A founder testing a subscription meal-planning idea launched an MVP with an intentionally generic, unbranded landing page, reasoning that brand didn't matter yet since it was "just a test." Signups were low, and the founder initially concluded the core idea didn't have demand. A quick round of user interviews revealed the actual issue: several prospective users assumed the generic-looking page was a low-effort scam given how often unbranded landing pages get used for exactly that, and had bounced before ever reading the actual offer.

A lightweight rebrand, a real name, a simple logo, a consistent color scheme, took about a week to put together and was layered onto the exact same landing page copy and offer. Signups roughly doubled with no other changes. The original test hadn't actually been measuring interest in the product; it had been measuring willingness to trust an anonymous-looking page, a different question entirely, and one the founder hadn't intended to test at all.

We ask two direct questions early in MVP scoping: does the product ask for money, sensitive personal data, or health information before the user has any other reason to trust it, and is the target audience one that's been burned by low-quality copycat products in this specific category before. A yes to either question pushes us toward the lightweight real identity described above rather than a fully placeholder treatment, since the risk of muddying the test result outweighs the modest time saved by skipping even basic brand work.

Beyond visual identity, a genuinely surprising number of MVPs lose trust points on a detail that has nothing to do with design: a free-tier domain name (a subdomain of a website builder's own domain, for instance) or a generic email address for support inquiries rather than one matching the product's own name. These are cheap to fix, a real domain costs very little, and they carry an outsized trust signal relative to their cost, often more than founders expect given how little design effort is actually involved.

We include a real domain and a matching support email address in even the leanest MVP setup by default, treating it as baseline infrastructure rather than an optional brand touch, since the cost is negligible and the downside of skipping it, a visitor bouncing because the contact email looks unprofessional or suspicious, is a real, avoidable loss to the test.

Occasionally a founder pushes to skip even the lightweight identity work entirely, wanting to launch literally as fast as possible with zero brand investment. We're direct about the trade-off in these conversations: the time saved is usually a day or two at most, while the risk is a test result contaminated by trust concerns that has nothing to do with the actual product hypothesis being validated. For most founders, once the actual time cost is quantified this specifically, the lightweight identity work becomes an easy yes rather than a real point of contention.

A generic, purely descriptive product name ("Meal Planner App") avoids the trust question entirely but introduces a different problem: it's harder to build any memorability or word-of-mouth around a name indistinguishable from a category description, and it's genuinely difficult to rename later once early users and any early press have already learned the original one. We treat picking a real, if simple, name as a separate decision from the broader brand-polish question, since a placeholder name is one of the few MVP shortcuts that tends to create more rework later than it saves upfront.