How to Develop an MVP in 2026 – Steps, Costs, and Success Factors
Let’s be honest — in business it’s not enough to simply come up with an idea. You need to quickly understand whether it actually makes sense. That’s where MVP, a Minimum Viable Product, comes into play. It’s not just a trendy buzzword but a practical tool that helps save time, money, and energy. Put simply, an MVP is a basic version of a product that already works but includes only the most essential features. It’s launched to test assumptions and find out if what you’re building is something people really need.
There’s no shortage of successful MVP examples. Take a look at global cases — Airbnb started as a simple website with just a few apartment photos in San Francisco, while Dropbox began with nothing more than a video demo that showcased the concept. And that was enough to spark user interest.
What Does the MVP Concept Mean?
The term Minimum Viable Product (MVP) became popular thanks to Eric Ries and his book The Lean Startup. The idea is simple yet powerful — build the smallest possible version of a product that still works and delivers real value to users.
In other words, an MVP is not the same as a traditional prototype. A prototype might not function at all and only demonstrate the concept. An MVP, however, is a working product that provides actual value to customers, even if in a limited way. This makes it a crucial step in product validation and one of the smartest strategies for startups and businesses aiming to reduce risks, save resources, and test their ideas in the market.
The main goal of an MVP is to test a hypothesis. For example, let’s say you believe people need an app for quickly choosing healthy meals. Instead of immediately investing in a complex system with thousands of recipes, you build a simple app with just 10 dishes and an option to order delivery. If users actively engage with it, you move forward. If not, you adjust your approach or shut down the idea — while still saving your budget and valuable resources.
Types of MVP
When it comes to validating a product idea, not all MVPs are created equal. The right type depends on what you need to learn first — whether it’s user interest, market fit, or product usability. Some MVPs help you test demand before any development begins, while others simulate the final product experience without actually building the full technology behind it.
Classic MVP approaches are especially useful in the earliest stages of product discovery. They help founders and teams gather real-world insights, test assumptions, and make data-driven decisions — all before committing significant resources to development. Let’s explore the most common types of classic MVPs that have helped countless startups and product teams move from idea to validation.
Concierge MVP
The Concierge MVP looks like an automated product on the surface, but behind the scenes, all operations are done manually. Instead of investing time and money in engineering, the team personally delivers the service to early users. For example, a startup offering personalized clothing recommendations could manually select and send outfits rather than building a recommendation algorithm. This approach allows teams to launch fast, test the core value proposition, and learn directly from real user behavior. However, it’s not scalable in the long term and may create a gap between the manual and automated experience. It’s best suited for validating the value of a service rather than its technical implementation.
Wizard of Oz MVP
Similar to the Concierge model, the Wizard of Oz MVP hides the manual work from users — they believe the service is fully automated. A common example is a chatbot that seems to respond instantly through AI, but in reality, human operators craft the replies during testing. This method helps validate how users interact with your product and whether the experience meets their expectations before building actual functionality. It provides realistic insights and flexibility to refine processes, though it can raise ethical concerns if users aren’t informed later and often requires intensive manual effort.
Landing Page MVP
A Landing Page MVP is one of the simplest and fastest ways to measure market interest. It involves creating a single page that clearly communicates your product’s value, benefits, and call to action — such as signing up, joining a waitlist, or pre-ordering. Tracking engagement, conversions, and user behavior helps determine whether people are genuinely interested before full development begins. While this method offers speed and minimal cost, it can be misleading — sign-ups or clicks don’t always mean users are ready to pay. Still, it’s a powerful tool for testing messaging, positioning, and pricing hypotheses early on.
Prototypes & Interactive Mockups
Prototypes and interactive mockups visually represent how the product will look and function. These can range from low-fidelity wireframes to high-fidelity clickable designs in tools like Figma. They help teams test usability, refine user flows, and align stakeholders around a shared product vision. Although prototypes are excellent for gathering UX feedback, they rarely expose technical constraints or system performance issues. Teams can easily overestimate readiness for development, mistaking a polished prototype for a near-final product. Used wisely, however, prototypes remain one of the most efficient ways to validate user experience before building anything real.
Understanding the key MVP types.
Product MVP Strategies
In product development, there’s no one-size-fits-all approach to building an MVP. The right format depends on what you need to validate — user behavior, technical feasibility, or business model assumptions. From lightweight software prototypes to early-stage hardware pilots, each MVP type offers a different path toward learning with minimal risk. Let’s explore the most common ones founders and product teams rely on to turn ideas into validated solutions.
Single-Feature Application MVP
A single-feature MVP delivers one core function exceptionally well to test user interest. For example, a restaurant might launch an app that does nothing but handle table reservations, avoiding any extra frills. This narrow focus keeps development lean and lets you get a working product into users’ hands quickly. Teams can then collect usage metrics and feedback on that one value proposition before adding more features. The benefit is rapid deployment and simplified maintenance, but the risk is that if this solitary feature isn’t compelling enough, users may churn quickly. In other words, the app’s success hinges entirely on that single solution satisfying a real pain point.
Simplified SaaS Solution MVP
A simplified SaaS MVP is a stripped-down version of a full software service, built with only the essential features to solve the customer’s primary problem. For instance, instead of developing a complete CRM suite, a startup might release just a basic lead-tracking module. This approach lets the team launch a subscription product immediately and begin testing revenue models or pricing strategies. By focusing on one or two key functions, they gain rapid feedback and can iterate based on real user behavior. The payoff is quick market validation and early monetization opportunities, but the downside is obvious: if the MVP is too minimal, clients may not see sufficient value. Missing features can leave customers unsatisfied or unwilling to pay, so it’s crucial to ensure the core offering truly addresses the target user’s “pain” even in its bare-bones form.
Pilot Hardware Prototype MVP
In hardware development, an MVP often takes the form of a pilot prototype with limited sensors or functionality. Rather than mass-producing a finished device, engineers build a few functional units to test in real-world conditions. These prototype devices help validate technical feasibility and uncover any system-level issues early. For example, you might assemble a wearable’s core circuit board in a 3D-printed shell so testers can try it in daily life. Such real-world testing can reveal design flaws and performance problems before you invest heavily in production. The trade-off is cost: custom hardware units require specialized parts and longer development cycles, making this MVP approach expensive and logistically challenging. Nonetheless, the early insights often justify the investment by preventing far costlier mistakes down the road.
For startup founders and product leaders, comparing these MVP patterns side by side can guide strategy. For example, a concierge-style MVP (where you personally deliver the service) lets you validate the offering with early customers, whereas a landing page MVP can gauge demand at almost zero cost. Likewise, a custom hardware prototype yields concrete operational data, but other lightweight MVPs trade precision for speed. The table below contrasts these approaches, summarizing each type’s main advantages, drawbacks, and ideal application domains to help determine the right MVP for your venture.
How to Choose the Right MVP Strategy?
Choosing the right MVP strategy always starts with understanding your goal of validation. Are you trying to find out whether people would actually pay for your solution? Or do you want to see how they behave when using it in a real scenario? The answer defines the direction.
How to launch a Concierge MVP?
Start with a clear hypothesis — define what exactly you’re testing and which metrics will signal success. Next, prepare a simple request channel — this could be a form, a chat, or even a phone line. Set up internal rules for processing requests and create response templates so every interaction feels structured. During the process, gather qualitative feedback after each user interaction. Look for repeating pain points or expectations — these are early indicators of value. Only after identifying consistent behavior should you consider automation. Building systems too early often leads to wasted effort on features that don’t matter.
Typical mistakes here include starting with too broad an audience, skipping documentation of user scenarios, or drawing conclusions from partial data. Treat every conversation as data, not anecdote.
How to test with a Wizard of Oz MVP?
The Wizard of Oz approach lets you simulate a fully automated service while humans still perform the actual operations behind the interface. It’s a clever way to see how users interact with your product — as if it were already built — and understand their expectations toward automation, speed, and design.
To organize it effectively, prepare detailed conversation scripts and define expected user responses. Hire or assign operators who can respond instantly, ensuring a seamless user experience. Track response time, user satisfaction, and conversion rates to identify bottlenecks or moments of confusion. At the same time, start building the technical foundation for gradual automation. Once you confirm that users genuinely value the service, you can begin replacing manual steps with real algorithms or software.
However, keep ethical boundaries in mind. Users should never feel deceived — transparency becomes crucial as you scale. Avoid using this method if your product’s value depends on a real algorithm that cannot be imitated without misleading results, or when operational costs become too high to sustain manual intervention.
Landing Page MVP is the best way to test market demand
A Landing Page MVP is essentially a concentrated marketing experiment — fast, measurable, and laser-focused on communicating value. The goal is simple: present your core proposition, add a clear CTA, and make tracking effortless. During testing, experiment with different headlines, pricing, and offers to see what resonates best. Paid ads with small budgets can also help you measure real demand beyond organic curiosity. Typical metrics include click-through rate (CTR), conversion to signup, cost per lead, and the share of users who left their contact information. Remember — your landing page is not just about design; it’s a powerful validation tool for your positioning and pricing strategy.
Prototypes reveal how users really interact
Prototypes allow you to visualize and test how users interact with your product before you commit to full-scale development. Low-fidelity sketches are ideal for early interviews and concept validation, while high-fidelity mockups (for example, in Figma) are perfect for usability testing. The key questions here are: “Is the interface intuitive?” and “Can users complete the main action without guidance?” A common mistake is creating a prototype that looks like a finished product but lacks real functionality – this often leads to misleading feedback. Start simple: build rough screens, then move to clickable mockups. Test with 5–10 users, note every friction point, and refine iteratively. Fixing usability issues at this stage is far cheaper than doing so post-launch.
Single Feature Application MVP do one thing exceptionally well
Single-feature MVPs are the go-to choice for mobile and consumer startups. Instead of building a multi-functional app, you focus on one key feature that delivers the most value — and perfect it. Tinder, for instance, started with just one mechanic: swipe and match. This simplicity helped the team optimize engagement and retention before expanding. To apply this model effectively, define the single feature that represents your core value, then build it with exceptional speed, reliability, and user experience. Focus on metrics like user retention, repeat usage, and engagement frequency. The only drawback? Some users might expect broader functionality — so plan your product roadmap for future expansion early on.
Simplified SaaS MVP shows if users will pay
In Simplified SaaS MVPs, you’re not only testing whether the product works — you’re validating whether people are willing to pay for it. SaaS is all about recurring revenue, so it’s crucial to test both value perception and pricing sensitivity.
Start with a trial period or a limited free version. Track activation rates — not just signups — to understand how many users actually engage with your product. Monitor churn and customer feedback closely. You can experiment with premium modules as add-ons, but never hide your main value proposition behind a paywall. The goal is to prove that users find enough value to justify an ongoing subscription.
Hardware MVP validating in real world conditions
When building Hardware MVPs, the ultimate test happens in the field. Unlike software, physical products must prove reliability, usability, and durability under real-world conditions. Startups often use small factory batches or handcrafted prototypes to gather early performance data. To succeed, involve end users early, set up data collection systems (for example, telemetry or usage logs), and maintain strict quality control. Every iteration should bring you closer to a stable, scalable version ready for production. Hardware MVPs may take longer to perfect — but they ensure your final product truly works where it matters most.
A quick checklist to choose the MVP type
Define the hypothesis you want to validate.
Choose the minimal experiment that directly tests this hypothesis.
Prepare success metrics and data collection tools.
Run a pilot with a small, representative user group.
Analyze, iterate, or pivot based on real insights.
Transitioning from MVP to a Full-Scale Product
If your MVP shows positive signals, the natural next step is scaling the product. However, not every encouraging metric is equally meaningful — it’s crucial to distinguish between superficial activity and indicators that truly validate product-market fit. A “positive signal” is any data point or insight suggesting that users not only engage with your product but derive real value from it and are willing to integrate it into their routines.
Key indicators to guide your decision include:
Sustained performance on core metrics over multiple weeks. It’s not enough to see a spike in signups or engagement; consistency demonstrates that the product resonates with a meaningful segment of your target audience. Metrics might include retention rates, repeat usage, or conversion along your primary funnel.
Recurring qualitative feedback from diverse users. Insights gathered from interviews or in-depth conversations that repeatedly highlight the same benefits or pain points are stronger validation than isolated positive comments. Look for patterns that indicate a consistent user need being met.
Willingness to pay or engage with monetization mechanisms. Early purchases, trial subscriptions, or pre-orders indicate that users perceive tangible value and are ready to exchange money for it — arguably one of the strongest indicators of product viability.
Technical feasibility for scaling. Even with validated demand, growth is constrained if the underlying architecture cannot support larger volumes or more complex workflows. A positive signal includes a system that can scale incrementally without requiring a complete redesign.
Emerging engagement trends among high-value segments. Beyond general usage, identify early adopter groups or specific user cohorts that exhibit higher LTV potential. Consistent engagement from these segments is a strong sign that scaling will be profitable and sustainable.
Once positive signals are identified, the next step is to prepare for scaling strategically. Key actions include:
Assess which parts of the MVP need immediate automation, focusing on areas where manual processes create bottlenecks or affect user experience. Prioritize features that impact critical workflows.
Create a 3–6 month roadmap with measurable milestones covering improvements, automation, infrastructure, and user acquisition. Ensure each milestone aligns with the metrics that validated the MVP.
Expand data analysis to identify the most valuable user segments. Early adopters often provide the clearest insight into long-term engagement and lifetime value (LTV). Segment users by behavior, usage patterns, and willingness to pay, and focus growth efforts accordingly.
Invest in infrastructure only after confirming the business model. Premature scaling adds unnecessary cost and complexity. Validate that key workflows can handle growth before committing resources.
Gather high-quality feedback. Ten in-depth, semi-structured interviews are more valuable than hundreds of anonymous surveys. Observe not just what users say, but also their actions, friction points, hesitation, and repeat usage. Semi-structured interviews allow guided discussion while leaving room for unexpected insights.
Scale only when three independent signals converge: consistent conversion metrics, repeatable qualitative feedback, and early willingness to pay.
If these signals are not present, scaling would be premature and risky. Return to your core hypotheses and refine the MVP, focusing on gaps revealed by user feedback and metrics. Test adjustments iteratively and validate them with targeted user interactions before expanding, ensuring that growth is built on solid, evidence-based foundations.
From Idea to Scale — Stages of MVP Development
Before you begin Discovery, take a moment to align on purpose and scope. The MVP process is an evidence-driven journey: it prioritizes learning over perfection and reduces risk by exposing assumptions early. A clear brief — defining the problem space, target outcomes, and which hypotheses matter most — ensures discovery work produces actionable insights rather than a long list of opinions. With that alignment in place, you can run discovery efficiently and translate findings into testable hypotheses.
Discovery & Market Analysis
Without exaggeration, the Discovery phase is the most critical starting point in any product development process. Imagine setting out on a journey without a map or compass — the chances of getting lost are high, right? That’s why the Discovery phase begins with a thorough market analysis: what solutions already exist, which trends are gaining momentum, and what pains the target audience experiences. Equally important is identifying who your potential users actually are. Are they young professionals glued to their smartphones, or perhaps conservative corporate clients with different adoption habits?
Next, you formulate your hypothesis. For example: “Users lack a fast way to order a healthy lunch in just two clicks.” This becomes the foundation for testing. It’s best to develop several hypotheses and prepare a clear plan for how you will validate them. A common mistake is to immediately fall in love with the idea and build the product around it. The goal at this stage is not to perfect the solution but to verify whether the problem truly exists and whether people are willing to pay for a resolution.
Design Prototyping & UX Concept
Once you have a validated hypothesis and a basic understanding of your audience, it’s time to move into visualization. This is not code yet, but it’s something tangible. Design now takes center stage. Prototyping allows you to quickly show users how the service will work. No one enjoys reading long functional descriptions, but a clickable mockup in Figma or even simple sketches immediately communicates the user experience.
It’s crucial that even at the MVP stage, the user experience remains comfortable. Minimal functionality does not mean “clunky” or confusing. If a user struggles to navigate, they will simply leave. Therefore, the focus should be on a clean interface, intuitive actions, and logical flows. The mindset of “we’ll fix it later” does not work here — first impressions strongly shape how users perceive your product.
Development Frontend & Backend Rapid Iterations
Now we move to the technical implementation. The key rule here is: do not attempt to build a “skyscraper” from day one. The MVP should have a simple architecture that can be quickly modified. Development proceeds in short iterations: build a small piece, demo it, gather feedback, and make adjustments. This approach is far more effective than working silently for a year, only to realize users do not need what you built.
The frontend should be lightweight, clear, and tailored to core user scenarios. The backend must be stable, but without unnecessary complexity. Your goal is not to create a perfect system from the start, but to deliver a working product that can already be tested in real-world conditions.
Testing Technical & User-Centered
This is where the most interesting phase begins. Testing consists of two components: technical and user-centered. Technical testing ensures that everything functions without critical bugs: forms submit correctly, data loads as expected, and the server remains stable. User-centered testing is even more valuable. You let people interact with the product while observing their behavior. Where do they get confused? What do they enjoy? Do they return? This isn’t dry statistics — these are live insights. Often, this phase reveals which elements need major redesign and which can remain as they are. It’s far better to uncover issues at this stage than after a full-scale launch.
Launch Releasing the Minimal Version
Once everything has been tested, it’s time to go to market. This could be a limited release — for example, only to a small group of users or within a single region. Alternatively, it could be a wider release, with a clear emphasis: “This is the initial version; we are actively gathering feedback.”
The key is not to fear showing your product. Some teams spend years polishing features and never actually reach users, causing the idea to lose relevance. An MVP teaches the opposite lesson: it’s better to launch quickly and start learning than to delay endlessly.
Analysis & Scaling
After launch, it’s crucial not just to celebrate that the product “exists,” but to analyze numbers and feedback. How many people registered? How many are actively using the product? Are users willing to pay? Which features are most important? This stage is where the most valuable insights emerge — you see where to go next. If positive signals are present, scaling begins: adding features, expanding to new markets, and improving infrastructure. If results are weak, that’s not a problem. You still have the opportunity to refine hypotheses or explore a different niche.
Choosing Functionality for Your MVP – Focused Framework
Choosing what to build into an MVP is a discipline that balances risk, learning velocity, and resource efficiency. The right approach connects each feature to a testable hypothesis, provides measurable outcomes, and keeps implementation minimal but complete. Below is a structured, practitioner-ready guide with actionable methods and governance principles – presented mainly as paragraphs for easier reading.
Start with hypotheses and Jobs to Be Done
Every feature you consider should be justified by a clear hypothesis or a Job To Be Done (JTBD). Rather than asking “Would this be nice?”, ask “Which hypothesis does this validate?” and “What single metric will tell us whether this works?” If a feature does not map to a hypothesis or a JTBD that matters for validating product–market fit, deprioritize it. This testable mapping turns product decisions into experiments, not opinions.Turn qualitative insight into quantitative inputs
Prioritization works best when informed by evidence. Convert customer interviews, competitive research, and usage benchmarks into quantitative estimates that feed prioritization models. For example, use interview frequency and quotes to estimate likely Reach and Impact; use engineering velocity to estimate Effort. Document sources for each estimate — this makes Confidence measurable and keeps the scoring defensible.Apply RICE rigorously but reasonably
Use the RICE framework (Reach, Impact, Confidence, Effort) to rank features objectively. Define Reach as the number of users affected in a defined horizon (e.g., 3 months), Impact as expected delta on a core metric, Confidence as the percent certainty informed by data, and Effort in team-months. Compute (Reach × Impact × Confidence) ÷ Effort to produce a comparable score. Importantly, record assumptions for each input so scores can be revisited as new data arrives. As an operational note, avoid over-precision: RICE is an ordering tool, not a forecasting model. The point is to surface high-return candidates and expose high-effort or low-confidence items for further research or surrogate experiments.Account for risk and technical dependencies
A high RICE score is not the whole story. Apply a risk overlay — reduce priority for features with high technical, regulatory, or market risk — and map architectural dependencies. A high-value feature that depends on a large platform change should either be sequenced after enabling work or tested with a surrogate (concierge or Wizard-of-Oz) to validate the hypothesis without heavy engineering.Use Value vs Effort as a human filter
Complement RICE with a simple value vs effort matrix to help stakeholders align quickly. Features that fall into the high-value/low-effort quadrant are the natural MVP candidates. High-value/high-effort items belong on the roadmap but typically not in the first MVP. This visual filter is useful during cross-functional review meetings to create consensus.Prioritize learning velocity and instrument everything
Prioritize features that yield fast, unambiguous learning. A feature that delivers a clear signal in two to four weeks is preferable to one that requires months of usage to evaluate. Design each feature as an experiment: define a single primary metric (the one number that proves or disproves the hypothesis), list supporting signals, and ensure analytics events and instrumentation are in place before release. Good instrumentation turns development work into repeatable experiments.Translate features into experiments and acceptance criteria
For each selected feature, specify the experiment you will run, the primary metric and threshold for success, the measurement method, and the timebox for evaluation. Decide in advance whether the outcome will result in “scale,” “iterate,” or “kill.” These exit criteria reduce downstream debate and avoid scope creep.Governance rhythm and cross-functional decisions
Make prioritization a collaborative routine: weekly or biweekly triage involving product, design, engineering, and analytics. Use RICE + value/effort + risk overlay as inputs and publish the rationale for accepted and rejected items. Lock the MVP backlog for the sprint or release period and protect it from late-stage feature requests unless an added item demonstrably accelerates learning.Implementation guardrails
When building, follow strict guardrails: implement vertical slices (end-to-end flows) rather than multiple half-implemented features; use feature flags for controlled rollouts and fast rollback; instrument telemetry and logging extensively; and set hard deadlines for de-scoping nonessential polish. Prioritize observability and rollback capability over premature performance optimization.
Post-launch validation and explicit exit rules
Before launch, declare success thresholds and time windows. Classify outcomes as Validated (meets threshold and moves to scale/automation), Refine (signal positive but below threshold — iterate), or Reject (no meaningful signal — remove/deprioritize). Timebox experiments to avoid indefinite “trying” without decision.
Practical considerations and anti-patterns
Stakeholder requests should require a hypothesis and a primary metric — no metric, no scope. Prefer surrogates (manual processes) when engineering would be expensive and the hypothesis can be tested without code. Beware two anti-patterns: (a) equating UI polish with validated value, and (b) allowing roadmap items to be selected on charisma rather than evidence.
How to Make Your MVP Work? Practical Advice for Business
Treat the MVP as an experiment, not a miniature final product. Resist the urge to pack every desired feature into the first release. The point of an MVP is to validate one or two high-risk hypotheses with the smallest possible investment of time and money. Define those hypotheses explicitly, agree on success thresholds up front, and let them drive scope. Involve real users from day one: recruit target customers into discovery workshops, prototype reviews, and early usability sessions. These conversations uncover context, edge cases, and language that analytics alone cannot reveal and will save development cycles and reduce the risk of costly rework. Use semi-structured interviews to balance comparability with flexibility, and complement qualitative insights with a small quantitative pilot to validate frequency and scale.
Where appropriate, favor no-code and manual surrogates to accelerate learning, and treat them as part of the discovery funnel rather than permanent solutions. Platforms like Bubble, Webflow, or simple Zapier automations can deliver functioning prototypes and real workflows far faster and cheaper than custom engineering. Similarly, concierge or Wizard-of-Oz experiments let you test the value proposition without committing to a full technical build. These approaches preserve optionality and help you validate UX and demand before you invest in architecture or integrations.
Set clear, measurable KPIs and instrument everything before you ship. Choose one primary metric as the experiment’s North Star and two or three supporting indicators; instrument minimal but sufficient events (key clicks, conversion events, retention cohorts) so you can answer both “what happened” and “why.” Time-box experiments (2–6 weeks for most feature tests) and declare exit criteria: what constitutes validation, what requires iteration, and what will be retired. Treat the MVP budget as an experiment budget — reserve capacity for a rapid follow-up iteration and for bug fixes, avoid premature infrastructure spend, and require simple cohort LTV/CAC checks before you scale.
Prioritize depth of insight over volume of data and be deliberate about seeking disconfirming evidence. Ten well-run semi-structured interviews combined with targeted analytics will reveal more than hundreds of shallow surveys. Talk to churned users, analyze failed cohorts, and monitor negative feedback channels; survivorship and confirmation biases are common and costly, and intentionally looking for counterexamples will surface real risks early. Plan the replatforming moment in advance: no-code and manual approaches have limits, so set explicit criteria for migration — sustained demand, repeatable monetization, and clear architectural needs — and design an incremental migration that preserves user experience.
Communicate transparently and align incentives around learning. Publish hypotheses, KPIs, and the experimental plan internally so stakeholders share the same success criteria; externally, be honest about the product stage and invite early users to contribute feedback. Reward validated learning rather than feature output: celebrate experiments that yield clear results (including invalidations), and protect the MVP backlog from scope creep with a strict governance rhythm.
MVPs are not about delivering less — they are about learning faster with less waste. Start small, listen closely, and let validated learning determine the path to scale.