What if I want to add more features mid-way?

Written by

Contic

Read time

2 minutes

A hand writing a list in a notebook.

During the build we work one-in, one-out. If you want to add a feature, we’ll suggest one to take out, so the price and launch date hold. Bigger ideas go on the post-launch roadmap, or we quote them as extra work and you approve the number first.

New ideas mid-build are normal. Seeing a product take shape is exactly when they arrive, often at 11pm and in a voice note. The rule is there so a good idea doesn’t quietly sink the launch.

When a change is free and easy

Timing matters more than size. The earlier you change your mind, the less it costs anyone.

StageHow change works
DiscoveryShape anything. This is where the scope is set.
DesignChange screens and journeys freely. Every tier includes an interactive prototype to test before build.
BuildOne-in, one-out. The scope is set, so additions need a swap.
After launchNew features go on the roadmap, informed by real users.

Changing a screen in a design tool takes minutes. Changing it in finished code can take days. So if something feels wrong, say so during Design.

How one-in, one-out works

Say you’re halfway through the build and want to add a referral scheme. We’ll look at what’s still to build and suggest something of similar size to move out. That might be an admin report you could pull by hand for the first month.

You decide. If the swap feels wrong, you can keep the original plan and put the new idea on the roadmap instead. Either way, the price and the launch window don’t move.

When the idea is too big to swap

Some ideas aren’t features. They’re a new part of the product: a second user type, a new integration or a rethink of the main journey. Those can’t be balanced by trimming something small.

For those, you have two choices:

  1. Park it for after launch. Real users will tell you whether it matters, and how it should work.
  2. Have it quoted as extra work. You see the price before anyone starts, and you approve it or not.

We’ll recommend the first. A launched product with real feedback is a better place to design a big feature than a build in progress.

Fixing our mistakes isn’t a change

There’s an important line here. If something we agreed to build doesn’t work as agreed, fixing it is our job. It’s not a change, and it never costs you a swap or extra money.

Change control only covers new ideas from you. Under a fixed price, if an agreed feature takes us longer than planned, that’s our cost. Our answer on whether the cost is really fixed goes into that.

Why we don’t just squeeze it in

Adding work without moving anything else has to come from somewhere. It comes out of testing, security and polish. Those are the parts you can’t see until something breaks in front of a customer.

It also moves the date. A late launch costs you more than a missing feature, because every week before launch is a week you aren’t learning from users.

What happens to the parked ideas?

They don’t disappear. We keep a list through the build and hand it over at launch. By then it has become the start of your roadmap, and half the items will look different with real users in the room.

You can build it with us after launch, or with anyone else, because you own the code. Our answer on coming back later for new features covers that. For what you can shape before the build starts, see whether you can customise what’s included. For why change control is what keeps a fixed price fixed, read fixed price vs time and materials.

Fixed price vs time and materials: which software contract protects you?

Want the long answer?

Read more

Thinking about building something?

We design, build and launch digital products at a fixed price, with a money-back guarantee after Discovery. Tell us what you have in mind.