- We offer certified developers to hire.
- We’ve performed 1500+ Web/App/eCommerce projects.
- Our clientele is 1000+.
- Free quotation on your project.
- We sign NDA for the security of your projects.
- Three months warranty on code developed by us.
An MCQ app can look deceptively simple.
At first glance, the product appears to need only a few screens: a login page, a list of quizzes, multiple-choice questions, a timer, a results page, and perhaps a leaderboard. That can make the development budget seem straightforward.
In practice, a production-ready MCQ application can involve considerably more engineering.
The moment an app needs thousands of questions, multiple categories, difficulty levels, timed examinations, randomized questions, negative marking, user accounts, subscriptions, payments, analytics, notifications, an administrator dashboard, question imports, anti-cheating controls, multilingual content, offline access, or personalized recommendations, the project becomes much more than a basic quiz application.
That is why asking “What does MCQ app development cost in 2026?” cannot be answered responsibly with one fixed number.
Current 2026 Indian app-development pricing published by several development-market sources shows wide variation based on scope. General mobile-app estimates range from roughly ₹1.5 lakh for simple applications to ₹25 lakh or considerably more for complex products, while mid-complexity applications with authentication, payments, APIs and administrative functionality commonly move into the several-lakh to low-tens-of-lakh range. (AppWizards)
For an MCQ app specifically, a practical planning model is:
| MCQ App Type | Approximate 2026 Development Budget in India |
| Basic quiz MVP | ₹1.5 lakh to ₹4 lakh |
| Standard MCQ learning app | ₹4 lakh to ₹8 lakh |
| Advanced exam-preparation app | ₹8 lakh to ₹15 lakh |
| Feature-rich competitive-exam platform | ₹15 lakh to ₹30 lakh+ |
| Enterprise-scale education ecosystem | ₹30 lakh to ₹60 lakh+ |
These are planning ranges rather than universal quotations. The actual cost depends on the number of platforms, user roles, backend architecture, question-management system, payment model, content volume, design complexity, integrations, security requirements and expected scale.
The most important point is this:
You are not really paying for “MCQ screens.” You are paying for the system behind the questions.
A simple quiz with 100 static questions and a sophisticated examination platform containing 500,000 questions, adaptive testing, subscriptions, analytics, live rankings and an administrator content-management system may both be described as “MCQ apps,” but their engineering requirements are completely different.
This guide explains where the money goes, what features affect the budget, how much each development stage can cost, what hidden expenses to anticipate, and how to plan an MCQ app budget in 2026 without underestimating the project.
The first mistake founders make is treating app development cost as a single product price.
A better approach is to divide the project into separate cost components.
A commercial MCQ application can contain:
Every additional system increases development time.
This explains why two vendors can quote ₹3 lakh and ₹15 lakh for what appears to be the same “quiz app.”
The quotations may not actually represent the same product.
One quotation could cover:
The second could include:
Naturally, the prices would be very different.
There is no official industry price list for MCQ applications.
Development companies price projects according to their teams, geography, technology stack, scope, project-management model, quality processes and commercial structure.
Recent 2026 Indian development pricing sources show that simple applications can begin around ₹1.5 lakh to ₹4 lakh, while more sophisticated apps with authentication, payments, backend services and administration can reach ₹4 lakh to ₹12 lakh or more. More complex systems can move substantially beyond that range. (MatchedNeeds)
An MCQ application can therefore be divided into several practical budget levels.
This category is appropriate when the objective is to validate an idea rather than launch a large education business.
A basic MCQ MVP might contain:
It may have limited administrative functionality.
For example, questions might initially be imported through a spreadsheet or simple database rather than managed through a sophisticated content-management system.
A basic application could also use a cross-platform framework so that Android and iOS can be developed from a shared codebase.
Current 2026 market references for cross-platform development in India place simple MVPs broadly around ₹1.5 lakh to ₹4 lakh, although actual quotes vary considerably according to scope. (MatchedNeeds)
A standard educational MCQ application usually needs considerably more functionality.
Typical functionality can include:
The backend becomes much more important at this stage.
Questions cannot simply live inside the application code.
The system needs a centralized database so administrators can add, edit, remove and organize questions without releasing a new mobile application version every time content changes.
This distinction alone can substantially affect the development budget.
An advanced exam-preparation application begins functioning more like a complete education platform.
Features may include:
At this point, the application is no longer simply a quiz interface.
It becomes an examination-management system.
A competitive-exam platform may require multiple interconnected products.
The ecosystem could include:
Complex applications can also require advanced performance engineering because thousands or hundreds of thousands of students may attempt tests simultaneously.
A mock test taken by 50 students is technically very different from a mock examination taken by 100,000 students at the same time.
The latter creates a concurrency problem.
Enterprise products can extend far beyond ordinary MCQ functionality.
Potential requirements include:
At this level, infrastructure and engineering architecture can become as important as the visible application.
The visible interface is only a small part of the product.
Consider a single question:
Which planet is known as the Red Planet?
A basic application simply displays four answers.
A professional examination platform may need to know:
Suddenly, the simple question has become a data object inside a sophisticated examination engine.
This is where development costs originate.
The first major pricing factor is platform coverage.
You may need:
Developing separate native Android and iOS applications can require more engineering resources than using a cross-platform framework.
Cross-platform technologies such as Flutter can reduce duplicated development work because a shared codebase can target multiple platforms. Current 2026 market guides commonly identify cross-platform development as one way to reduce duplicated platform work, although native integrations and platform-specific requirements can still introduce additional engineering. (Lenoretech)
The decision should not be based solely on price.
It should be based on:
Screens influence development cost, but they are not the only factor.
A simple screen such as:
may require little engineering.
A question screen can be much more complex.
For example, an advanced examination screen may support:
Therefore, 20 simple screens can sometimes be cheaper than 10 highly interactive screens.
The size of the question bank is a major architectural consideration.
A small application might contain:
A serious competitive-exam platform might contain:
Large question repositories introduce additional requirements.
These can include:
The database must also be designed to retrieve questions efficiently.
A basic MCQ app may support only one question format.
For example:
Select one correct answer.
A sophisticated application can support:
Each question type introduces additional UI and scoring logic.
Consequently, question-type diversity can increase development cost.
The examination engine is one of the most important components of an advanced MCQ app.
It determines:
A professional examination engine may need to support:
The complexity of these rules can substantially affect the budget.
Instead of looking only at the overall project price, it is useful to understand where development resources go.
A basic login system may include:
A more advanced authentication system may add:
Each additional authentication mechanism requires implementation and testing.
Current 2026 development pricing examples show that authentication and social-login functionality can represent separate development line items rather than being automatically included in a basic application quote. (Innovatrix Infotech)
A student profile might include:
A basic profile is inexpensive.
A personalized profile connected to analytics and recommendation systems requires substantially more backend logic.
An MCQ application usually needs a hierarchy such as:
Exam → Subject → Topic → Subtopic → Question
For example:
UPSC → History → Modern India → Freedom Movement
Or:
SSC → Quantitative Aptitude → Percentage → Advanced Questions
The deeper the hierarchy, the more sophisticated the content-management system becomes.
Questions may be classified as:
But a mature platform may use numerical difficulty values.
For example:
This data can later support personalized learning.
A timer sounds simple.
It isn’t always simple.
A basic quiz timer may simply count down from 30 seconds.
An examination platform must consider:
For high-stakes examinations, server-side time validation can be important because client-side timers alone can be manipulated.
Randomization can range from simple to sophisticated.
A basic algorithm may select:
20 random questions from 100.
An advanced system may require:
5 easy questions + 10 medium questions + 5 difficult questions across specified topics, with no repeated question from the student’s previous three attempts.
That requires considerably more backend logic.
Suppose the correct answer is always option C.
Students could potentially identify patterns.
Therefore, many systems randomize:
The scoring system must remember the original correct answer after options are rearranged.
Competitive examinations frequently use negative marking.
For example:
The system must calculate this accurately.
If multiple examinations use different scoring rules, the architecture needs configurable scoring.
A strong MCQ application should not simply tell users whether they are right or wrong.
It can provide:
This increases content value but also increases content-management requirements.
Students may want to save questions for later.
A bookmarking feature requires:
If the app supports multiple devices, bookmarks need reliable server synchronization.
One of the most underestimated expenses is the administrator dashboard.
The mobile app is what students see.
The admin panel is what keeps the business running.
A serious MCQ application should rarely depend on developers for every content update.
Administrators should be able to:
A basic admin dashboard may cost around ₹80,000 to ₹2 lakh depending on functionality, technology and design. Published 2026 feature-level pricing examples show admin dashboards being treated as substantial development components rather than minor add-ons. (Innovatrix Infotech)
A highly customized enterprise administration system can cost substantially more.
Imagine an administrator has 20,000 questions in an Excel spreadsheet.
Manually entering them one at a time is inefficient.
A better system supports:
For example, the import file might contain:
The system can validate each row before inserting it into the database.
This feature becomes especially valuable for large educational businesses.
UI/UX design should not be treated as decoration.
An examination application has unusual usability requirements.
Students need to answer questions quickly.
The interface should make it obvious:
Poor UX can directly affect the learning experience.
A good MCQ interface should prioritize:
Design costs depend on:
The backend is the invisible engine of the MCQ app.
It may manage:
A simple quiz app may use a lightweight backend.
A large examination platform requires much more.
The backend may need:
This is one reason why quoting only for “mobile app development” can be misleading.
The mobile interface is only one part of the complete product.
A professional database might contain tables or collections for:
Relationships between these entities must be carefully designed.
For example:
One user can have many attempts.
One attempt can contain many answers.
One question can appear in many tests.
One exam can have many sections.
One subscription can have many transactions.
Poor database architecture may work during early testing but become a problem as the user base grows.
If the MCQ app is free, payment integration may not be necessary.
But many educational apps use:
Payment systems may involve:
The implementation cost depends on the chosen payment provider and the business model.
There can also be marketplace or platform fees after launch. Google states that Google Play service fees apply to certain paid apps and digital purchases, with 99% of developers subject to a service-fee tier of 15% or less under applicable programs. (Google Help)
These platform economics should be considered separately from the initial development budget.
Subscriptions add another layer of complexity.
The system needs to determine:
A sophisticated subscription system may support:
Each plan can have different access rules.
Notifications can be useful for:
But notification systems need careful design.
Sending too many notifications can reduce engagement.
A better system can segment users.
For example:
This makes notifications more relevant.
Leaderboards can increase engagement, but they require additional backend logic.
The application may calculate:
For small applications, a simple database query may be sufficient.
At scale, leaderboard calculations may require:
The larger the user base, the more important performance becomes.
Analytics help answer questions such as:
A mature MCQ platform can track:
Analytics can become a significant backend and data-engineering requirement.
Artificial intelligence is becoming increasingly relevant to education applications.
An MCQ application may use AI for:
However, adding an AI API is not the same thing as building an AI-powered learning system.
For example, a basic AI explanation feature may call an external model API.
An advanced adaptive-learning system might need:
The difference can be substantial.
AI-generated questions can reduce some content-production workload, but they should not automatically be published without review.
Potential workflow:
Topic → AI generation → validation → expert review → approval → publication
A professional system can store:
This becomes particularly important when questions are used for serious examinations.
Adaptive testing can make an MCQ platform significantly more sophisticated.
Instead of presenting identical questions to every student, the system can adjust difficulty according to performance.
For example:
A student answers several easy questions correctly.
The system can progressively introduce more difficult questions.
Another student struggling with the same topic may receive foundational questions.
This requires a more advanced assessment architecture.
The application may consider:
Adaptive testing can therefore push the project toward a higher development tier.
Offline functionality is another important cost driver.
An offline-enabled app might allow students to:
Offline synchronization is significantly more complicated than online-only functionality.
The system must handle conflicts.
For example:
A user takes a test offline.
Later, the same user logs in from another device.
The server now needs to determine which data should be synchronized.
Offline-first systems can therefore add meaningful development and testing effort. Current 2026 feature-cost examples place offline functionality among the more substantial app features compared with basic authentication or static screens. (HireFlutterDev)
An MCQ app may not initially seem security-sensitive.
However, the question bank can be valuable intellectual property.
If the platform sells premium examination content, unauthorized access could directly affect revenue.
Security considerations include:
For high-stakes examinations, security requirements can be substantially greater.
Competitive examination platforms may require anti-cheating mechanisms.
Potential features include:
Not every MCQ application needs all of these.
But adding proctoring or identity verification can transform the project scope.
India’s education market can require multiple languages.
An application might support:
Multilingual support involves more than translating button labels.
Question content must also support:
If the application supports right-to-left languages, additional interface considerations may also arise.
A mobile app does not always have to be the entire product.
Some businesses launch:
The web version can be useful for students who prefer laptops or desktops.
This is particularly relevant for:
A web application introduces additional responsive-design and browser-testing requirements.
The technology stack affects development effort, but it should not be selected solely because one technology appears cheaper.
Possible frontend approaches include:
Possible backend technologies include:
Possible databases include:
The best combination depends on:
Flutter can be attractive when the objective is to launch Android and iOS applications from a shared codebase.
It is especially suitable for many conventional educational applications.
However, a cross-platform framework does not eliminate backend development.
You still need:
Recent 2026 market estimates for Flutter development in India vary widely, with simple projects commonly positioned around ₹1.5 lakh to ₹4 lakh and more sophisticated applications extending into higher ranges depending on scope. (MatchedNeeds)
Native Android development can be appropriate when:
The disadvantage is that an iOS version requires a separate technology path.
Native iOS development can be suitable for:
Again, Android development becomes a separate engineering effort if both platforms are required.
The development team you choose can influence the budget considerably.
Possible approaches include:
Published 2026 Indian market estimates show substantial differences between freelance and agency hourly rates, although exact rates vary by specialization and project. (SiteYatra)
A freelancer may work well for:
A development company may be more suitable when you require:
The important comparison is not simply the hourly rate.
It is the total project outcome.
A cheaper hourly rate can become expensive if:
A practical approach is to avoid building every feature immediately.
Start with a focused MVP.
A possible MCQ MVP could include:
Then add:
after validating demand.
This can reduce initial capital requirements and allow real users to influence product development.
A hypothetical Indian project might look like this:
| Component | Estimated Budget |
| Discovery and planning | ₹25,000–₹50,000 |
| UI/UX design | ₹40,000–₹80,000 |
| Mobile development | ₹1,00,000–₹2,00,000 |
| Backend | ₹60,000–₹1,20,000 |
| Admin panel | ₹40,000–₹80,000 |
| QA testing | ₹25,000–₹50,000 |
| Deployment | ₹15,000–₹30,000 |
| Approximate total | ₹3.05 lakh–₹6.10 lakh |
These are illustrative planning figures, not a market quotation.
A real quotation should be based on a written scope.
An advanced project might be structured as:
| Component | Approximate Range |
| Product discovery | ₹50,000–₹1 lakh |
| UI/UX | ₹1–₹2 lakh |
| Mobile applications | ₹3–₹6 lakh |
| Backend | ₹2–₹4 lakh |
| Examination engine | ₹1.5–₹3 lakh |
| Admin panel | ₹1–₹2.5 lakh |
| Payment/subscriptions | ₹50,000–₹1.5 lakh |
| Analytics | ₹50,000–₹1.5 lakh |
| QA | ₹75,000–₹1.5 lakh |
| Deployment and DevOps | ₹50,000–₹1 lakh |
| Potential total | ₹11.25 lakh–₹24 lakh |
The numbers can move upward if the application includes AI, large-scale concurrency, offline synchronization, proctoring, institutional accounts or extensive integrations.
The initial quotation is not necessarily the final cost of ownership.
You should budget for:
These costs may be recurring.
A small MVP may operate on modest cloud infrastructure.
As traffic grows, you may need:
A platform serving 500 students does not have the same infrastructure requirements as one serving 500,000.
If the application uses phone authentication, every OTP can create a small variable expense.
At scale, these small costs can become meaningful.
AI-powered features can create usage-based costs.
For example:
The development budget and AI operating budget should therefore be separated.
Launch is not the end of the project.
Mobile applications need ongoing maintenance because:
Several 2026 development cost guides recommend budgeting roughly 15% to 20% of the initial build cost annually for ongoing maintenance, although actual maintenance requirements vary significantly by application complexity and service level. (Space To Tech)
For example, if an application costs ₹10 lakh to build, a planning allowance might be:
₹1.5 lakh to ₹2 lakh per year
for ordinary maintenance and support.
That does not necessarily include major new features.
A complete redesign or AI transformation would normally be treated as a new development project.
At around ₹2 lakh, you should keep expectations realistic.
The application could potentially include:
It probably should not attempt to include:
Trying to include everything at this budget often results in poor quality.
A ₹5 lakh project can potentially support a more practical MVP.
Possible functionality:
The exact scope still depends on the development team and specifications.
At around ₹10 lakh, the project can potentially become a commercially stronger product.
Potential scope:
This is often a useful level for a serious education startup.
At approximately ₹20 lakh, you can consider building a much broader education platform.
Possible functionality:
The exact scope must still be defined before budgeting.
A low initial quotation can sometimes exclude important components.
Look carefully for phrases such as:
None of these terms are automatically problematic.
The problem occurs when the buyer assumes they are included while the vendor assumes they are excluded.
A written scope solves this.
Do not compare only the final number.
Compare:
For example:
Vendor A: ₹4 lakh
Vendor B: ₹8 lakh
The second quotation may include a full admin dashboard, backend, QA, deployment and six months of support.
The first may include only mobile development.
The prices are not directly comparable.
Ask the development team:
These questions can prevent major misunderstandings.
Reducing cost does not necessarily mean removing important features.
It means prioritizing the right features.
Instead of launching:
start with one category.
Once the product is validated, add more.
Design the backend so new exams can reuse:
This makes future expansion easier.
If Android and iOS are both required, cross-platform development can reduce duplicated implementation work.
However, the decision should be made according to technical requirements rather than cost alone.
AI can be added after the core learning experience is validated.
Start with:
Then introduce AI where it provides measurable value.
A good admin panel can actually reduce long-term operating costs.
Instead of requiring developers to modify the database for every new question, administrators can manage content themselves.
A phased roadmap can be useful.
Build:
Add:
Add:
Add:
Add:
This approach allows the budget to follow actual product validation rather than assumptions.
Cost and timeline are closely related.
A basic application might take:
6 to 10 weeks
A standard application could require:
10 to 16 weeks
An advanced platform might take:
4 to 7 months
A complex enterprise education platform can require:
6 to 12 months or more
Published 2026 Indian development estimates similarly show simple applications being delivered in weeks and more complex feature-rich products requiring several months. (JenX Technologies)
The timeline depends on:
A larger team does not always make the project proportionally faster.
Some tasks are sequential.
Technology is only half the product.
The other half is content.
You may need:
For serious competitive examinations, question quality can become one of the largest operational expenses.
A technically excellent application with inaccurate questions will still fail to create trust.
For an education application, expertise and trustworthiness are particularly important.
Questions should ideally be:
For professional or academic subjects, expert review becomes especially valuable.
An application should not treat AI-generated content as automatically correct.
Human review remains important for:
Accessibility should also be included in the product plan.
Consider:
An accessible MCQ interface can improve usability for a wider audience.
Students expect question transitions to be immediate.
Slow interfaces can become frustrating during timed tests.
Performance considerations include:
Performance becomes particularly important during peak examination periods.
Imagine 100,000 students starting a mock examination at exactly 10:00 AM.
The infrastructure must absorb a sudden traffic spike.
A startup may initially have:
1,000 users
Later:
100,000 users
Eventually:
1 million users
The architecture should not necessarily be built for one million users from day one.
But it should avoid decisions that make future scaling unnecessarily difficult.
Good architecture can allow gradual expansion through:
An MCQ platform can collect:
Therefore, privacy and security should be considered from the beginning.
Security measures may include:
If the platform serves children or regulated educational environments, additional requirements may apply depending on the market and jurisdiction.
Development is not complete when the application compiles.
Launch can involve:
Google Play also has platform-level service-fee rules for qualifying digital purchases, which should be separated from the application’s development cost. (Google Help)
Apple has its own developer and commercial requirements.
These are operating considerations rather than core software-development expenses.
An excellent application can still fail without distribution.
Potential marketing channels include:
Marketing should not be confused with development cost.
If you have ₹10 lakh available, spending all ₹10 lakh on development may not be the best business structure.
You may need separate budgets for:
SEO can become an important acquisition channel.
A platform can publish useful educational pages around:
Search-friendly content can bring users into the ecosystem before they install the application.
However, SEO pages should provide genuine value rather than simply generating thousands of thin pages.
Development cost should be connected to monetization strategy.
Possible models include:
A subscription model requires additional functionality.
An advertising model requires ad integration.
Institutional licensing may require multi-tenant architecture.
Therefore, monetization decisions affect the technical budget.
Some companies do not want to build a separate application for every institution.
Instead, they build a white-label platform.
One underlying system can support:
Each customer can have:
This requires multi-tenant architecture.
The initial development cost may therefore be higher, but the platform can support multiple customers.
A large education business may need:
Mobile applications
↓
API gateway
↓
Application services
↓
Database
↓
Caching
↓
Analytics
↓
Administration
↓
Cloud infrastructure
Each layer can be independently scaled.
This is very different from a simple application that stores questions locally on the device.
A useful conceptual formula is:
Total development cost = product scope + design + mobile development + backend + admin + integrations + QA + deployment + infrastructure preparation
Then add:
Operating cost = cloud + third-party services + maintenance + content + support + marketing
This distinction is critical.
The development budget pays to create the product.
The operating budget pays to keep the business running.
Imagine a startup wants to build an application for banking-exam preparation.
The first release requires:
A reasonable planning range could fall around:
₹7 lakh to ₹15 lakh
depending on design quality, technology, development team, backend complexity and testing requirements.
The startup could then add:
after launch.
Now imagine a platform supporting:
This is no longer a simple MCQ app.
It is an education technology platform.
A budget in the tens of lakhs or beyond can be reasonable depending on architecture and operational requirements.
Some buyers try to calculate:
Number of screens × cost per screen
This is unreliable.
Consider two ten-screen apps.
Ten static information screens.
Ten screens containing:
They have the same screen count.
Their engineering effort is completely different.
The better budgeting method is:
screen count + functionality + backend complexity + integrations + user roles + scale
An MCQ platform might have:
Every role can have different:
For example, a teacher might create tests.
A content editor might edit questions.
An institution administrator might manage students.
A super administrator might control the entire platform.
Role-based access control therefore becomes an important architectural component.
APIs connect the mobile application to the backend.
Typical APIs include:
A basic app may require a relatively small API layer.
A large platform can have dozens or hundreds of endpoints.
Every endpoint needs:
Testing should not be treated as the final five minutes before launch.
MCQ applications contain many edge cases.
For example:
Testing needs to cover these situations.
QA may include:
Android devices vary significantly.
The application may need testing across:
iOS has fewer hardware combinations but still requires testing across supported OS versions and screen sizes.
Web applications require browser testing.
The more platforms and devices you support, the greater the QA requirement.
The first production release often reveals issues that internal testing does not catch.
Post-launch support may cover:
A maintenance agreement should clearly define:
Before requesting quotations, prepare a scope document.
Include:
Explain:
List:
Document:
Specify:
Specify:
Specify:
Mention potential later features:
This allows the development team to design an architecture that can evolve.
Before approving a quotation, verify whether the price includes:
If a quote does not clearly state whether these are included or excluded, ask for clarification before signing.
A first version does not need every possible feature.
Focus on the core user journey.
An MCQ application with a serious business model needs a reliable backend.
Question quality determines the educational value of the application.
The cheapest technology today can become expensive tomorrow if it creates maintenance problems.
Examination applications need reliable scoring.
A wrong result can damage user trust.
A platform designed for 1,000 users may behave differently when 100,000 users take a test simultaneously.
Without a good admin system, content operations can become expensive.
So, what does MCQ app creation actually cost in 2026?
There is no single universal price.
For an Indian development project, a sensible planning framework is:
These ranges should be treated as planning estimates, not fixed industry tariffs. Published 2026 development-market estimates demonstrate substantial variation because application scope, technology, team structure and infrastructure requirements differ. (MatchedNeeds)
The most important budgeting principle is to stop thinking of an MCQ app as a collection of screens.
The real product is a combination of:
mobile experience + examination engine + question database + backend + administration + analytics + payments + infrastructure + content operations.
If your objective is simply to validate an MCQ idea, a focused MVP can potentially be built with a relatively modest budget.
If your objective is to compete in the competitive-exam or EdTech market, the budget needs to account for scalable architecture, content management, reliable scoring, analytics, security, administration and long-term maintenance.
The smartest budget is therefore not necessarily the smallest budget.
It is the budget that matches the product you actually intend to operate.
A well-defined scope before development can prevent the most expensive problem of all: starting with a cheap-looking quotation and discovering halfway through development that the critical backend, admin, testing, payment, analytics or scalability requirements were never included.
Get cost, timeline & technical suggestions within 24 hours.
