Every project we take on starts with a two-week app development discovery phase that ends with a written scope and a fixed price. Clients who have been burned before usually ask the same thing: what actually happens in those two weeks, and what do we get? This is the answer, step by step.

Why the app development discovery phase exists

Scope creep is not caused by clients asking for more. It is caused by nobody writing down what “done” means before the price was agreed. Discovery produces that document. It costs you about six hours of your time over two weeks, and it is yours whether or not you build with us.

Take a booking app. “Users can cancel” sounds like one feature. Then someone asks: up to when? Full refund or partial? Who approves an exception? Does the provider get notified, and can they dispute it? That one line turns into four screens and a refund rule. If nobody asks these questions before the price, they get asked in sprint four. At that point the answer costs money and goodwill. Discovery moves those questions to the cheapest point in the project.

Step 1: kickoff workshop (day 1, two hours of your time)

A two-hour session with the people who own the problem: usually a founder or product owner, someone from operations, and whoever will use the admin side. We ask about the business, the users, what happens today without the software, and what success looks like in six months. We do not talk about features yet.

Typical questions: Who pays, and who uses it, if they are different? What spreadsheet, inbox or phone call does this replace? What breaks today when volume doubles? Which regulation or contract limits what we can do? The operations person matters more than people expect. They know the exceptions, and exceptions are where cost hides.

You receive: a one-page summary of goals, users and constraints, the same day, for you to correct.

A good correction is specific: “Clinics, not patients, are the paying customer.” If you change nothing, we assume we have missed something and ask again.

Step 2: user flows (days 2 to 5, one hour of your time)

We draw every path a user takes through the product as boxes and arrows: sign up, book, pay, cancel, dispute, and the admin paths that handle each. This is where features appear, because a flow that needs a screen is a screen that needs building. We review the flows with you in a one-hour call and mark each one as version one, later, or never.

A typical product with payments and two user roles ends up with somewhere between 20 and 40 flows. The admin side is usually a third of them, and it is the part most early estimates leave out. The dispute flow is a common example. It looks minor, then turns out to need a case list, a status history and a way to issue refunds without opening the payment provider’s dashboard.

You receive: the flow diagrams with every box labelled in, later or out.

Step 3: technical plan (days 5 to 8, thirty minutes of your time)

Our lead engineer turns the flows into a plan: the stack, the data model at the level of main entities, the integrations and which vendor each uses, the hosting, and the risks. If an integration needs a vendor sandbox with an eight-week approval, this is where it gets flagged and the application started.

The risks list is the useful part. Each entry names the risk, what it could cost in time, and what we do about it. Typical entries: an old system with no API, a mobile feature that depends on app store review, or a vendor whose pricing changes at a usage threshold. Your thirty minutes go on the decisions only you can make, such as which payment provider you already have a relationship with.

You receive: a technical plan in plain language with a diagram, and a list of accounts to create in your name (repository, cloud, payments) so you own everything from the first commit.

We insist on that last point. If the code and hosting sit in an agency’s accounts, leaving that agency becomes a migration project. In your accounts, it is a change of access.

Step 4: design direction (days 6 to 9, one hour of your time)

In parallel, the designer produces wireframes for the three most important screens and a direction for the visual system: type, colour, component style. Not final designs; enough to agree the feel and to size the design work.

Three screens is deliberate. They are usually the ones users see most, such as the home view, the core action and checkout. Agreeing those sets the patterns for the rest. Designing every screen at this stage would take weeks and get redone once real content arrives.

You receive: wireframes of the key screens and a one-page design direction.

Step 5: scope review (day 10, ninety minutes of your time)

We walk through the scope document together. It lists every feature in version one with a sentence of acceptance criteria, every feature deliberately out, the stack, the team, the sprint plan, the launch plan, and the fixed price with its payment schedule. We change it live in the call. You take it away, sleep on it, and sign it or not.

Acceptance criteria are written so either side can test them. Weak: “Users can cancel bookings.” Useful: “A customer can cancel up to 24 hours before the slot and is refunded in full automatically; later cancellations go to the admin queue.” The second version can be checked in a demo. The first one starts an argument.

You receive: the scope, the price, and the sprint calendar.

What makes the price fixed

The “out” list. A scope that lists only what is in leaves every ambiguity to be argued over later. Ours lists what is out next to what is in, with the reason. When a new idea comes up in sprint three, it is compared to the list, priced, and either swapped for something of equal size or scheduled for version two. Nobody is surprised.

An illustrative case: midway through a build, a client wants in-app chat. It was on the out list, marked “email notifications cover this for launch.” We size chat and show what it is equal to, say the reporting dashboard. The client picks one. The price and the date stay where they were.

What discovery costs

Discovery is included in every project we quote, and the output is yours either way. If you take the scope to another team, it will make their quote more accurate too. We think that is the right trade: a client who knows what they are buying is a better client.

If you have a product in mind, start with the project form. The first thing that happens is a kickoff call, and two weeks later you have a scope with a number on it.

Frequently asked questions

Can discovery be shorter?

For a small internal tool, one week. For anything with payments, roles or integrations, two weeks is the minimum that produces a scope we can fix a price on.

What if we already have a specification?

Good; discovery goes faster and we spend the time on the technical plan and the out list. A specification written by the buyer usually lists what is wanted; it rarely lists what is not.

Does the fixed price ever change?

Only when the scope changes, in writing, with both sides agreeing the new number before the work starts. That has to be true or “fixed” means nothing.

What should we prepare before the kickoff?

Nothing formal. Useful extras: the spreadsheets or tools the product will replace, any existing designs or brand guidelines, and a list of systems it must connect to. Bring the operations person even if their calendar is tight. Their two hours save more than any document.