Developers Never “Just Add” a Feature
“Small” changes are almost never small. Clients often imagine the final product and judge the price and time it takes based on that single mental picture but often neglect HOW to get there and what it takes. This isn’t their fault since clients usually are unaware of the design and development process. This post aims to offer a high-level view of how we go from a concept, like an RV Pickup Report, to it being a properly functional addition to an app.
If you’ve ever thought, “Isn’t it just uploading some pictures?”, you’re not alone. Lots of clients say some version of this when they request a new feature. From the outside, something like an RV damage report flow looks simple: snap a few photos, maybe add a note, done.
Under the hood, though, even a “simple” feature is a mini project with many moving parts: product thinking, UX design, development, testing, and iteration. Designers and developers never “just” add a feature; they’re designing how it works, where it fits, and what happens when things don’t go as planned.
Let’s walk through what really goes into building something like an RV report flow where users “just upload photos”.
1. Clarifying what the feature actually is
First, we have to figure out what “RV report flow” actually means in practice.
Questions we need to answer:
When does a user see this? Before a trip, after a trip, during pickup, during drop‑off?
Who is filling it out? The renter, the owner, or both?
What exactly do they need to submit? Photos, notes, checkboxes, signatures?
What happens after they submit? Who is notified? Is it stored, reviewed, or used for insurance?
This is where gaps and questions show up:
What if the user has bad reception and can’t upload photos right away?
What if they submit incomplete info?
What if they need to come back and edit the report?
What if there is no damage to report? Do they still go through the flow?
Even before design starts, we’re defining:
The goal of the feature
The users involved
The edge cases and “what ifs”
This alone can change the scope from “upload pictures” to “a structured report and review process.”
2. Designing the experience
Once we know what the feature needs to do, we move into UX/UI design. This usually happens in a tool like Figma, which is what we use at Pixeltree.
For an RV report flow, that might include:
Adding a button to existing components and adjusting how it impacts the layout
Is it a new screen? A set of modals? How seamless can we integrate this new feature into the existing flow?
What is the primary device being used here and how does that influence the experience of carrying out the other steps?
Steps to guide the user (e.g., “Exterior”, “Interior”, “Mechanical issues”)
Photo upload components (with instructions like “Take a photo of the front of the RV”)
Fields for notes, checkboxes, or severity levels
A review/confirmation step so users can double-check before submitting
This design work involves:
Creating initial mockups for desktop and mobile.
Making sure the new flow fits into the existing app without feeling bolted on.
Thinking about states: loading, success, error, empty, partially completed.
And then comes feedback and iteration:
The client needs to review and test the mockups as well to make sure it suits their needs.
The dev team needs to review the design and potentially make suggestions based on programming lift and what’s even possible given the existing tech stack, data model, and architecture.
You realize, “We also need owners to see this report,” or “We should require at least three photos.”
Designers update flows, adjust layouts, add steps, remove others.
Every change in the design can:
Add new logic for development.
Introduce new paths (“If X is checked, show Y”).
Affect how long the build will take.
So even before a developer writes a line of code, we’ve done real work to define and design how this feature behaves in the real world. Users only see the tip of the iceberg while all the work required to get it there is invisible.
3. Fitting it into the existing product
Features don’t live in isolation; they sit inside a bigger ecosystem.
For example, the RV report flow has to:
Connect with the current booking flow or trip management screen
Respect existing permissions (who is allowed to view/submit reports?)
Fit with the existing visual style (buttons, typography, layout)
Play nicely with data models (how and where is this report stored?)
Some common questions at this stage:
Where is the entry point? A button on the trip page? A reminder at check‑in/check‑out?
Does this create a new kind of record (e.g., “report”) in the system?
Should this show up in emails, dashboards, or PDFs?
This is where “just add a simple thing over here” can snowball, because:
Adding one button may require navigation changes.
Adding a new data type (“RV report”) may affect APIs, admin views, exports, and more.
4. Breaking it into developer tickets
Once the flow is clear in Figma, we translate it into structured work for developers in the form of tickets that describe specific pieces of a feature like:
“Create RV report model with fields X, Y, Z”
“Build report creation UI (desktop + mobile)”
“Implement photo upload with size limits and progress states”
“Send report notification to owner”
“Display report in owner dashboard”
Each ticket needs:
Clear acceptance criteria (“This is done when…”)
Screens or prototypes attached
Notes on edge cases and error states
Business rules (“Photo is required for any damage marked ‘severe’”)
Good tickets reduce uncertainty, but they’re time‑consuming to write. This is the bridge between design and development and is crucial if more than one person is working on the feature.
5. Programming (what you think is “the whole job”)
This is the part most people picture: developers coding.
For features like an RV report feature, dev work includes:
Frontend: building the screens, photo uploader, validation (e.g., required fields), navigation between steps
Backend: saving reports and images, linking them to trips and RVs, adding APIs
Integrations: storage for images (e.g., S3), notifications, maybe analytics events
Permissions: ensuring only the right users can create and view reports
If there are one or two developers, they often have to:
Switch between frontend and backend
Coordinate so their changes don’t conflict
Keep performance and security in mind
Even “simple” flows involve:
Handling success, error, and retry states
Gracefully dealing with slow network or failed uploads
Making sure the UI doesn’t break on different device sizes
6. Testing and QA (finding all the ways it can break)
Once the feature is built, we test it.
This typically includes:
Trying the happy path: everything works as expected.
Trying unhappy paths:
User cancels halfway through.
User loses connection during photo upload.
User uploads a massive photo.
User tries to submit without required info.
Testing on mobile and desktop:
Does the photo upload work on phones?
Do buttons and content fit smaller screens?
Cross‑browser checks if web-based.
Then comes acceptance testing with you:
You walk through the feature and see if it meets your expectations.
You might spot gaps (“We also need owners to add their own notes”).
New issues are logged, prioritized, and fixed.
Every issue or change request triggers more work:
Another tweak in design
Another code change
Another round of testing
7. Branching paths and real‑world complexity
In early conversations, most people imagine a straight line: start → fill → submit → done.
In reality, features branch:
What if there’s no damage? Do we still store something?
What if damage is severe? Do we trigger a different workflow (e.g., hold deposit, notify support)?
What if the user starts a report and comes back later?
What if there are multiple reports for the same trip?
Each branch:
Adds conditions in the code (“If A and not B, then show C”)
Adds UI states (“No report yet”, “Report in progress”, “Report submitted”)
Introduces more cases to test
This branching logic is where “tiny features” often grow into proper, meaningful pieces of product functionality.
8. Post‑launch: iteration and maintenance
Even after launch, the work doesn’t really stop.
Common follow‑ups:
Users give feedback: “This step is confusing” or “Can I add video too?”
Support finds patterns: “People keep getting stuck here.”
Data shows gaps: no one uses the feature where you initially placed it.
Iteration might mean:
Tweaking copy and labels for clarity
Adjusting the flow (reordering steps, adding a confirmation screen)
Improving performance or reliability (especially around photo uploads)
Fixing bugs that show up only in real‑world usage
And the maintenance cost continues over time:
Updating this feature when related parts of the app change
Ensuring it stays compatible with new devices or infrastructure changes
Why this matters for estimating “small” features
When you request a new feature like an RV report flow, you’re not just asking for a screen with an upload button. You’re asking for:
Clarification and product thinking
UX/UI design and iteration
Integration into your current app ecosystem
Structured developer work and coordination
Thorough testing and QA
Handling of edge cases and branching paths
Future maintenance and iteration
That’s why designers and developers flinch a little at “It’s just…”, not because they don’t want to help, but because they know what it will actually take to make it reliable, usable, and integrated.
A better way to frame it together is:
“Here’s the outcome I need. Can you help me understand what’s involved and what a realistic scope looks like?”
That opens the door to honest planning, more accurate estimates, and ultimately a better product.
One big change to our process is to separate out the design phase and the development phase. This means the client invests in the design phase first as a complete scope. By the end of the design phase the flow has been refined, iterations have been made, the dev team has had their say (and may have performed “code spikes”; quick development tests to validate how a piece of a feature can be built), and missing requirements and gaps in the user flows have been discovered and added.
By the end of a design phase, there is a very tangible feature to estimate. You’ve also got a much cleared view of the timeline and derisks the development phase.
