Scoping and a working prototype of your business app in three weeks

The three-week scoping and prototype engagement is our entry offer, and it is also what allows us to commit to a fixed price afterwards. A committed price has to be prepared: it assumes we have seen your real business rules, your volumes and your data — not that we have read a six-page brief.

What you are buying

Week by week

1. 1

   Week 1 — understand the real process

   First workshop with the teams concerned, collection of a sample of anonymised production data, review of existing material: standard contracts, calculation spreadsheets, procedures. Mostly we are looking for what is written nowhere and applied by everybody.

2. 2

   Week 2 — build and confront

   The prototype is built on the priority use case. At the end of the week, the second workshop: users operate the first version and correct our assumptions. That is the session where the rules missing from workshop one surface.

3. 3

   Week 3 — adjust, price, present

   Prototype adjusted after the second workshop, rules document written, full project cut into batches and priced firmly. Presented in session, with the remaining areas of uncertainty named and their potential effect on the price.

What the prototype is not

This is the point we are most explicit about, because a misunderstanding here poisons everything that follows. The prototype exists to support a decision, not to run your operations.

• It is not a version one going into production: it has neither the robustness, nor the security, nor the data migration of a live application.
• It covers a single use case, chosen for its decision value — not the whole functional scope.
• It is not opened to your members or suppliers: the test users are internal and named.
• It is neither maintained nor hosted long-term beyond the final session, unless separately agreed.
• It is not free, deliberately: a free prototype is built in two days on invented data and teaches nobody anything.

What you have to provide

Three weeks hold because the pace is tight. The conditions below are not formalities: when one is missing, the schedule slips mechanically.

1. An available business owner: roughly two days spread across the three weeks, workshops included, with the standing to make scope decisions.
2. A sample of anonymised production data: an export of your declarations, your contracts or your calculation workbooks. Invented data produces a flattering prototype and a wrong estimate.
3. The existing business rules in whatever form they live: written procedures, standard contracts, or simply the people who have been applying them for ten years.
4. Two to four users available for the second workshop — the people who execute the process, not only those who supervise it.
5. Someone able to say what is out of scope: scoping is as much about removing items as adding them.

What you keep if you do not proceed

Everything. The prototype and its code, the rules document and the quote are yours, with no reservation clause. You may use them to consult other suppliers — several organisations use exactly this to build a serious tender, which is an entirely legitimate use of the engagement.

At minimum you leave with two things you did not have: an internal demonstration that makes the project tangible for your board or management committee, and a credible budget to decide against. Sometimes the conclusion is to build nothing, because the process can be simplified rather than tooled. Reaching that conclusion for a few thousand euros is the best possible return on this spend.

When we advise against it

• When the requirement is already written, priced and arbitrated internally: scoping would add nothing and we quote the project directly.
• When no business owner can free up time this quarter: better to postpone than to produce a scope built on assumptions.
• When the decision to invest has not yet been taken at the level that decides: a prototype does not replace an internal political arbitration.
• When the real need is a heavily standardised off-the-shelf package — payroll, general accounting, office software. We say so during the discovery call rather than charge for scoping to find out.
• When the subject is maintenance on an existing system you intend to keep: what you need is an audit, not a prototype.

MEKANO is a Lyon-based development studio. We build the management applications of small and mid-sized companies and of buying groups — member portals, supplier approval, revenue declarations, year-end rebate engines, document management — at a fixed price, in batches with formal acceptance, source code handed over. This entry offer is the first step of every project we take on.