One of the hardest parts of custom software is not writing the code.
It is deciding where the software stops.
A small operational problem can turn into a large project very quickly. A request for a booking screen becomes customer profiles. Customer profiles become CRM. Someone asks for payments. Then reporting. Then a second workflow. Then a mobile app.
Every addition can sound reasonable on its own.
Taken together, they change the project.
That is why MicroFit uses Scope Lock: a deliberate point before the build where the problem, workflow, users, integrations and delivery boundary are made explicit.
The purpose is simple: keep small software small.
What Scope Lock is
Scope Lock is the moment when both sides can answer the same practical questions:
- What problem are we solving?
- Who will use the application?
- What is the main workflow?
- What information does the application need?
- Which existing systems must it talk to?
- What rules and exceptions are part of the first version?
- What is explicitly outside the build?
- What does "done" mean?
Until those answers are clear enough, the project is still being shaped.
Once they are clear and agreed, the build can be treated as a defined piece of work rather than an open-ended discovery process.
Why this matters more on small projects
Large software programmes often assume that requirements will evolve over months or years. They have programme governance, multiple phases and budgets designed to absorb change.
A MicroFit is different.
The value comes from being constrained: a narrow business problem, a clear outcome and a deliberately small build.
That makes scope discipline more important, not less.
If a project is meant to be small, one "small addition" can represent a significant percentage of the total work.
A new user role may affect permissions, interfaces and testing. A new integration may require authentication, error handling and data mapping. A new workflow may create an entirely new branch of application logic.
The visible request may be one sentence. The implementation impact may be much larger.
Scope Lock is not a giant specification document
Traditional software projects sometimes try to remove uncertainty with long requirement documents.
That is not the objective here.
A good Scope Lock should be precise enough to build from, but lightweight enough to be useful.
It should capture the things that materially affect the solution:
The actors
Who uses the software? Customers, staff, managers, administrators, suppliers?
Different actors usually imply different permissions and views.
The core steps
What happens from start to finish?
For a booking workflow, that might be: check availability, select a slot, confirm, receive a reminder, cancel if necessary, and let staff manage exceptions.
The business rules
What makes this process specific?
Capacity, eligibility, approval thresholds, deadlines, pricing logic, routing rules or resource constraints are often the reason generic software does not fit.
The integrations
What other systems need to exchange information with the application?
An integration is not just a checkbox. The direction of data, frequency, authentication and failure behaviour all matter.
The exclusions
What are we deliberately not building in this version?
This is one of the most useful parts of the exercise.
A clear exclusion is not a missing feature. It is a decision that protects the result.
What happens when a new idea appears later?
It will. Good ideas often appear once people can see the solution taking shape.
Scope Lock does not mean "never change anything".
It means a new request is treated explicitly as one of three things:
- A clarification — the request was already implied by the agreed behaviour and does not materially change the work.
- A substitution — something can be swapped without expanding the overall build.
- A change — the request adds meaningful work and should be considered separately rather than quietly absorbed.
That distinction protects both speed and trust.
Without it, every project slowly becomes a negotiation over whether a sentence was "included". With it, the team can discuss the impact of the idea instead of arguing about the wording.
Predictability comes from boundaries
"Fixed price" and "predictable delivery" are not properties of software development by themselves.
They are consequences of controlling uncertainty.
A tightly scoped application can be estimated and delivered much more predictably than a vaguely defined one. That does not eliminate technical surprises, but it dramatically reduces avoidable ambiguity.
The principle is the same as in any constrained engineering problem: first define the system boundary, then optimise inside it.
For MicroFit, the delivery clock starts from Scope Lock because that is the point at which the build has a stable shape.
A useful side effect: better product decisions
Scope Lock also forces a useful question:
Does this feature solve the target problem, or does it simply sound like something software should have?
That question removes a surprising amount of unnecessary work.
Not every application needs dashboards. Not every workflow needs AI. Not every customer-facing process needs a native mobile app. Not every data set needs advanced reporting.
The first version should contain the capabilities required to solve the defined problem well.
Everything else has to earn its place.
Small by design
MicroFit is not an attempt to make large software projects artificially fast.
It is a way to recognise a different class of problem: one that is too specific for generic SaaS, but too small to justify a traditional custom software engagement.
Scope Lock is one of the mechanisms that keeps that category honest.
A MicroFit should have a clear fit, a clear boundary and a clear definition of done.
If the boundary cannot be made clear, the project may need to be redesigned — or it may simply not be a MicroFit.