MAKIN 
What we keep, what we defer and how we decide under a hard deadline.
Cut scope, never cut correctness.
Fewer features shipped properly beats more features shipped approximately. The things that must not be deferred are the ones expensive to retrofit: data model, authentication, money handling, and an audit trail. Everything else can wait for version two.
Pick the one user who must succeed.
A v1 serving three personas serves none. Choose the single path that has to work — usually the one that generates revenue — and make it genuinely good. The other paths can be visible and rough, or absent entirely.
Deferred is a list, not a feeling.
Write down everything cut and why. An unwritten deferral becomes an argument in week five and a surprise for the client in week seven. A written one is a roadmap you can hand over.
Leave the seams where you will cut next.
Six-week builds get extended. Keep the boundaries clean at the points you already know will change — the integration, the pricing rule, the reporting layer — so the next phase is an extension rather than a rewrite.
What “correct” means for the four things you keep
Naming the four things that cannot be deferred is easy. The harder part is agreeing what done looks like for each, so a thinner version does not slip through under deadline pressure. Write a short definition for each before the first screen is designed, and hold the build to it.
- Data model: stable IDs, a timestamp on every record, deletions that can be undone, and no open text fields where you will later need to filter or report.
- Authentication: roles in place even if v1 has only one, a working password reset, sessions that expire and no shared logins.
- Money: amounts in the smallest unit, never floating-point, payment callbacks safe to receive twice, and every payment matched to an order.
- Audit trail: who changed what and when, recorded for every edit to money, permissions and status, and never editable from inside the app.
What goes on the deferred list
Some features feel essential in planning and turn out not to be. Deferring them is not a judgement that they are unimportant. It is a judgement that the chosen user can succeed without them for now, and that adding them later will not mean reworking anything on the keep list.
Each deferred item gets a line on the written list: what it is, why it waited and what would bring it forward. Check offline working before anything goes on it. If the user who must succeed works where there is no signal, as with a field workforce app, offline is a data-model decision rather than a feature, because records created on a device need their own IDs and a rule for conflicts, and adding sync to an online-only model later is close to a rewrite. Candidates for the list are these.
- Personas beyond the one who must succeed, including most manager and admin views.
- Dashboards and reports, where a clean export to a spreadsheet can stand in at first.
- Themes, multiple languages and other presentation options.
- Integrations other than the one the revenue path depends on.
A test for requests that arrive mid-build
Under a hard date, the dangerous requests are the reasonable ones. Run each through the same four questions in the same order, and record the answer on the shared board. The last of them is the easiest to skip. A deadline holds only if scope is traded rather than accumulated, so when something genuinely must come in, name the item that goes out in the same conversation and move it to the deferred list with its reason.
- Does the chosen user’s path fail without it? If not, it is deferred.
- Does it touch the data model, authentication, money or the audit trail? If so, decide now, because it only gets harder.
- Can a person do it by hand for the first users? If so, do that and defer the software.
- Does it replace something already planned, or add to it? Additions need a matching cut.
Steer the deadline with demos, not status reports
A status report says work is nearly done; a demo shows whether it is. Our engagements are founder-led and run on a shared board with a working demo from day one, and under a six-week deadline that demo does most of the steering. Show the chosen user’s path end to end on a real device with realistic data, and let the product owner use it rather than watch it.
Review the deferred list in the same meeting. If something on the path is slipping, the choice is made out loud: cut a further item, accept a rougher edge on a secondary screen, or move the date. What is never traded is anything on the keep list.
Choose the smallest v1 that proves the path
Sometimes the quickest correct v1 is not the app everyone pictured. If the user who must succeed is your own operations team, an internal tool can prove the process before any customer-facing app exists. Internal Tools & Portals starts at ₹45,000 and is delivered in up to 30 days; a Mobile App (MVP) for Android and iOS from a single codebase starts at ₹1,25,000 and is delivered in up to 3 months.
The aim is to put the one path in front of real users early, learn where it breaks, and let version two be shaped by that rather than by the original wish list. A customer app built around a process nobody has yet run in software tends to encode guesses.
Hand over v1 so version two starts clean
The handover is where the seams and the deferred list pay off. A v1 handed over without them leaves the next team, or your own, reverse-engineering decisions made under pressure and never recorded. The handover pack should carry each of the following.
- The deferred list, with the reason for each cut and what would bring it forward.
- The seams: where the integration, the pricing rule and the reporting layer are isolated, and how to extend each one.
- The definitions of correct for the four keep items, so later work is held to the same standard.
- What to watch in the first weeks of real use, and who decides what enters version two.