# 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. Canonical: https://erdibuilds.app/help/add-features Last updated: 2026-11-06 (November 6, 2026) ## 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 (A way for two programs to talk to each other). - 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 (The place where the code is stored) 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](https://erdibuilds.app/guides/how-to-split-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. **Example plan for one larger feature** | | 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 | 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](https://erdibuilds.app/help/design-only). Features for subscription products are covered on the [SaaS page](https://erdibuilds.app/build/saas). ## 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. ### What 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](https://erdibuilds.app/help/rescue-project) covers that case. ### What 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. ### Who 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. ### How 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. ## Related - [Hire a Developer to Continue Your Project](https://erdibuilds.app/help/continue-existing): Someone 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 Only](https://erdibuilds.app/help/design-only): Get 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 developer](https://erdibuilds.app/build/saas): Plan 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 developer](https://erdibuilds.app/build/web-app): How 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 Milestones](https://erdibuilds.app/guides/how-to-split-a-project-into-milestones): Split 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 Projects](https://erdibuilds.app/guides/fixed-price-vs-hourly): Fixed 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.