Estimating hours for an MVP

The situation

A founder in Pune wants to launch an app that books home physiotherapy sessions. Patients choose a qualified therapist, pick a slot and pay online, and therapists see their bookings for the day. The founder has a pitch deck, a few sketches on paper and a list of fifteen features, and wants to know how many hours the first version will take and what it will cost.

The honest answer is a range, built up feature by feature, priced at 2good rates, with a plan for cutting scope if the number is larger than the budget.

Start with the smallest version that proves the idea

The first version has one job: to show that patients will book and therapists will turn up. Everything that does not help with that job can wait. Go through the feature list and ask of each item, "Would a patient or therapist in the first month miss this?"

For the physiotherapy app, the founder keeps these:

• Sign up and login by mobile number with a one time password.
• Therapist profiles, with an admin who approves each therapist before they appear.
• Booking: choose a therapist, see free slots, book one, cancel or reschedule.
• Online payment through an Indian payment gateway such as Razorpay.
• Booking reminders by SMS or WhatsApp.
• A simple admin panel with a list of bookings and basic reports.

Ratings, a referral scheme, video consultations and a Marathi version go on a "later" list. They may well matter, and they can wait until after the first hundred bookings.

Break each feature into a range

Estimating a whole app in one number is guesswork. Estimating a login screen is much easier, because it has been built many times before. So break the first version into features, and give each one a low and a high figure.

The low figure assumes the details are simple. The high figure allows for the usual surprises: an extra rule, a third party service that behaves oddly, a screen that needs a second round of changes. For the physiotherapy app, a working estimate of build hours looks like this:

• Sign up and login: 6 to 10 hours.
• Therapist profiles and approval: 10 to 18 hours.
• Booking with slots, cancellation and rescheduling: 18 to 30 hours.
• Online payment and refunds on cancellation: 8 to 12 hours.
• Reminders by SMS or WhatsApp: 5 to 10 hours.
• Admin panel and basic reports: 12 to 20 hours.
• Setting up environments and putting the app live: 5 to 8 hours.

That adds up to 64 to 108 hours of building.

Add testing, review and project management

Someone also has to test each feature, a senior engineer has to review the code, and someone has to plan the work and report progress. At 2good these are included in the hours, with no separate charge.

As a guide to the proportion, a 150 hour Prime block puts 115 hours into development and 35 hours into senior review, testing and project management. That is roughly three hours of checking and coordination for every ten hours of building. Applied to the build estimate, the first version comes to roughly 85 to 140 hours in total.

What it costs

Work is bought in whole blocks of 150 hours, so 85 to 140 hours means one block, or 150 hours. At the Prime rate of INR 199 or USD 2 an hour, before tax:

• One block: INR 29,850, or USD 300.
• AI tool budget: USD 50 for the block.

The minimum engagement is one block of 150 hours, which comes to INR 29,850 or USD 300 before tax. Taxes apply as usual, including GST for Indian clients. There is no advance, and you pay after you accept the work against a signed Statement of Work. Third party costs, such as hosting, the payment gateway's fees, SMS charges and app store accounts, are agreed in writing before work starts.

For the physiotherapy app, the first version fits inside one block, with some hours left for changes after the first screens. You can try the same arithmetic on your own feature list with the MVP hours estimator, and see pricing for the full rate card.

Which tier fits

Prime suits a first version with a clear scope. If your product depends on heavy integrations or hard architecture choices, Plus (USD 5 an hour) or Pro (USD 10 an hour), with INR on request, may suit better. The tier can change from one block to the next; see tiers.

Why a range is more useful than a single number

A single figure hides the uncertainty. A range shows you where it lives. In this estimate, booking has the widest spread, 18 to 30 hours, because the slot rules are not yet clear: whether a therapist can block out a lunch break, how far ahead a patient can book, and what happens if a patient cancels an hour before. Each answer moves the number.

So the range is also a list of questions. Answer them early, in the specification, and the range narrows. Leave them open, and the high end becomes more likely.

A range also helps you budget. Plan for the high end, and if the build lands lower, you have money for the first changes after launch.

How to cut scope when the number is too high

Suppose the founder wants the one block of 150 hours to cover the first version and a full round of changes after launch. The way forward is to make the first version smaller, keeping the price per hour as it is. Some practical cuts:

• Take payment at the visit for now. Many first customers will happily pay the therapist by UPI on the spot. This removes the payment and refund work.
• Simplify slots. Offer fixed morning and evening slots in place of a full calendar. The booking estimate drops to around 12 to 20 hours.
• Send reminders on one channel only, for example WhatsApp, which brings that line down to 3 to 5 hours.
• Replace reports with an Excel export of bookings. The admin panel comes down to 8 to 12 hours.

With those cuts, the build hours fall to 44 to 73, and the total with testing, review and project management comes to roughly 55 to 95 hours. That leaves at least 55 hours of the 150 hour block for the changes that come once real patients start booking.

Each cut can be reversed later, once the first version has shown that people book.

Limits of an early estimate

An estimate made from a feature list is a starting point. The real figure comes from the signed specification, when every rule is written down and each line can be tested. Expect the numbers to move once you see the first screens and think of things you did not know you needed. When that happens, the change is written down, estimated and agreed before it is built.

A short checklist

Before you ask for a quote on a first version, check that:

• You have cut the feature list to what the first month of users would miss.
• Each feature has a low and a high estimate.
• Testing, senior review and project management are included in the total.
• You have priced the range at the hourly rate, before tax, and know how it compares with the 150 hour minimum.
• Third party costs are listed separately, to be agreed in writing.
• You know which features you would cut first if the high end is too much.
• The open questions behind the widest ranges are written down, ready for the specification.