Add new features to a product that already works
To add a feature, describe the user's goal, the screens involved and how you will know it works. A developer then estimates it, builds it in milestones and tests it together with the parts that already exist.
Last updated:
Who this is for
This help type is for products that are live or nearly live. Users exist, the base works, and now you want more: a new payment option, a team area, a mobile version of a web feature, search, notifications or an admin view. A new feature touches old code, so it is different from starting fresh.
- Customers keep asking for the same missing function.
- You want to add a paid plan or a second pricing tier.
- You plan to connect your product with another service through an API.
- Your own developer is busy and you need extra hands for one feature.
What to prepare
- A short feature description as a user story: who does what, and why.
- Simple sketches or screenshots with notes. Photos of a sheet of paper are fine.
- Rules and edge cases: who can see it, what happens when something goes wrong.
- Access to the repository and a test version of the product, not the live one.
- Any limits: deadlines, services that must be used, and parts that must not change.
If you have several features, put them in order. One or two done well bring more than five half done. The guide on splitting a project into milestones shows how.
How it runs in milestones
A good plan delivers something visible at each step. Each milestone is funded before work starts and runs 1, 2, 3, 4, 6 or 8 weeks. Milestones are from 50 to 2,000 each in your project currency.
| Topic | What you get | Example timing |
|---|---|---|
| Phase 1: Shape it | Screens, rules and a technical plan checked against the existing code | One milestone, for example 1 week |
| Phase 2: Build the core | The main flow working on a test version | One to two milestones, for example 2 to 4 weeks |
| Phase 3: Edge cases and polish | Error states, permissions and testing alongside existing features | One milestone, for example 1 to 2 weeks |
| Phase 4: Release | Live release, a short note on what changed and how to use it | One milestone, for example 1 week |
Phase 1: Shape it
- What you get
- Screens, rules and a technical plan checked against the existing code
- Example timing
- One milestone, for example 1 week
Phase 2: Build the core
- What you get
- The main flow working on a test version
- Example timing
- One to two milestones, for example 2 to 4 weeks
Phase 3: Edge cases and polish
- What you get
- Error states, permissions and testing alongside existing features
- Example timing
- One milestone, for example 1 to 2 weeks
Phase 4: Release
- What you get
- Live release, a short note on what changed and how to use it
- Example timing
- One milestone, for example 1 week
Example only: the weeks are for illustration. Developers set the length of each milestone in their proposal, and each real milestone runs 1, 2, 3, 4, 6 or 8 weeks.
Questions to ask developers
- Have you worked with this technology and with this kind of feature?
- Which parts of the existing code does this feature touch?
- How will you avoid breaking what already works?
- Can the feature be released in smaller pieces so I can test early?
- What would you do differently if I had half the time?
A feature is often more than its screen. Payments, emails, permissions and data changes all belong to it. Ask the developer to list them so nothing appears as a surprise later.
If you need a designer first, see design only. Features for subscription products are covered on the SaaS page.
Frequently asked questions
Can I hire a developer for just one small feature?
Yes. Describe it clearly and ask for a single milestone. Small, well defined features are a good way to get to know a developer.
Link to this answerWhat if the existing code is messy?
A developer should tell you early if the feature is hard to add because of the existing code. Then you can decide whether to clean up first. The rescue help type covers that case.
Link to this answerWhat if the feature grows during the work?
Write down the extra part and agree on it as a separate milestone. This keeps the first milestone clear for both sides.
Link to this answerWho owns the new feature?
Unless both sides agree otherwise in writing on the platform, the rights to the result of a milestone pass to the client once that milestone is paid in full.
Link to this answerHow do I test a feature before approving?
Ask for a test version and a short list of steps to try. You can request changes before you approve, and a milestone is approved automatically only after 14 days without a response.
Link to this answerRelated pages
- Hire a Developer to Continue Your ProjectSomeone started your product and now you need it finished or moved forward. Learn how to hand over a project and plan the next milestones.
- Hire a Designer or Developer for Design OnlyGet screens and a look people love, ready for a developer to build. See what to prepare, what you receive and how milestones work.
- Build a SaaS with an independent developerPlan a SaaS product: accounts, subscriptions, technologies, an example milestone plan, what to write in the brief and how to pick a developer.
- Build a web app with an independent developerHow to plan a browser-based web app: common technologies, an example milestone plan, what to write in the brief and how to judge a developer.
- How to Split a Project Into MilestonesSplit a software project into milestones that each deliver something you can see and approve. Rules, an example plan and a free planner tool.
- Fixed Price vs Hourly for Software ProjectsFixed price suits clear scopes, hourly suits open ones. See how each model handles risk, change and control, and when milestones give you the best of both.