Can new feature ideas be added during a custom software project?

Yes, but new ideas should not be inserted directly into active development. Record the user, problem, and success condition in the backlog. Wavesteam assesses effects on scope, data, interfaces, schedule, and price; the parties then approve work against a maintenance allowance or written change order.

New ideas are normal, particularly once people can use a prototype or see exceptions in production. The issue is whether the change interrupts the milestone being accepted, whether a “small button” changes data and permissions, and how cost is approved. Unlimited verbal additions cause delay and make it impossible to tell whether the original contract is complete.

Change	Example	Treatment	Typical impact
Defect against agreed acceptance	Excel export omits a contracted field	Defect repair	Not charged as a new feature
Small experience improvement	Copy, alignment, reasonable validation of an existing field	Assess within current iteration or allowance	Depends on contract, not automatically free
New business function	Member tier, points, approval step, role	New requirements and acceptance estimate	Usually changes time and price
Scope-level change	New app, payment, hardware, external system, multi-tenancy	Reassess architecture, compliance, plan	Significant; may become a phase
Exploratory idea	Unproven AI or promotion	Interview, prototype, or manual test first	Pay for validation before full implementation

A backlog item states who has what problem, current workaround, frequency and loss, expected behaviour, exclusions, data and permissions, and success evidence. The client supplies an accountable business owner, not a technical design. Wavesteam works out the workflow, exceptions, interfaces, and acceptance before estimating.

Assessment includes secondary effects. A member tier can alter identity, discounts, refunds, service views, historical migration, and reports. WeCom integration can affect organization sync, identity links, messaging limits, departures, and consent. Even one field may affect APIs, imports, exports, and mobile clients. Assumptions and exclusions prevent the same name from representing different products.

Priority considers users, frequency, time or margin, compliance, cost, consequence of omission, and evidence confidence—not stakeholder seniority alone. High-value, low-risk items enter a near iteration. Unclear data or rules get a validation task. Rare exceptions may keep a manual path. A backlog is a decision record, not a promise to build every item.

Protect accepted milestones. A major change can replace equivalent scope, extend the date, or enter a later phase, with written approval. The change record identifies additions and removals, design/technical impact, price, payment, date, acceptance, and warranty start. The original scope remains independently acceptable rather than permanently “almost finished.”

Free minor work follows the maintenance agreement; there is no universal “one or two days free.” Track consumption, remaining allowance, and target release. Defects, inspections, new functions, platform-policy changes, and major upgrades need distinct definitions. The service process and warranty guide inform the contract discussion.

Each iteration has fixed scope, test environment, and release window, followed by agreed usage, completion, time, errors, service volume, or revenue evidence. High-risk changes use staged rollout, feature flags, and rollback. Wavesteam encourages evidence-led evolution without equating extensibility with unlimited free work.