How to scope a SaaS project you can afford to finish
How I approach SaaS scope and pricing as a former agency owner and current freelancer, and what to ask when budgeting for design and development.
If you’re budgeting for a SaaS project, a list of screens will only get you so far. Before I can give you a useful quote, I need to understand what people will do with the product and how much of it already works. Working that out together is part of the job. You shouldn’t need to become a product designer before you can hire one.
When I ran Drool, my design agency, I said yes to too much. “Sure, we’ll handle that too” became a habit, and the scope and timelines got hard to control. I wrote about it when I shut the agency down. I helped create those expectations.
I freelance now, doing design and development. I’d rather spend more time with you deciding what the project includes before either of us commits to a price. That gives you something you can budget for and gives me a job I can finish.
My Next Filing leads with the next task, its deadline, and the action to take.
Start with what you need the product to do
You can come to me with a rough idea, an existing app, or a folder full of screenshots. What helps most is explaining the problem you want to solve.
Suppose you run a SaaS product for agencies. Teams upload drafts, then chase clients over email to find out whether the work is approved. You want that decision inside the app so nobody has to search an email thread before sending the final file.
That’s a useful starting point. “Add an approval screen” leaves me guessing at much of the work.
I’d ask who can approve a draft, whether several people need to agree, and what happens when someone uploads a replacement. One person clicking Approve is a smaller job than five people reviewing different versions and waiting on each other. Both might look like one screen in your brief.
As a designer, I need to make those choices understandable on the screen. As a developer, I need to make sure the app saves the right decision against the right file. If an approval carries over to a draft the client hasn’t seen, a polished interface won’t help.
For this hypothetical project, suppose you decide that one named person can approve or request changes. Feedback can be plain text, and a replacement draft needs a new decision. We can sketch that before spending time on the visual design.
You don’t need to answer every question in the first call. I do need your help deciding which behavior matches how your customers work. Those decisions tell me what I’m estimating.
Show me what we’re starting with
The approval feature could be an addition to a working product or the first piece of a new one. That changes the quote considerably.
If accounts, client access, and file storage already work, we may be able to use them. A walkthrough with whoever maintains the product helps me check that. An upload that works for your staff might give clients no way to open the file. Fixing that belongs in the estimate too.
The same goes for design. On SellScale, our team at Drool built a modular design system for a product with more than 200 screens. Shared buttons, inputs, and other components gave us parts we could use across the product.
That screenshot is a Figma library. A design-and-development quote also depends on which components exist in code. A finished design can save design time while still leaving the implementation to do.
Share what you have, including the awkward parts. A prototype, old design files, customer complaints, and a conversation with your engineer help me judge what we can reuse and what needs work.
If an unknown could change the price substantially, I’d suggest a small paid investigation before quoting the whole job. Agree on its cost and what you’ll get from it. For this example, that might be confirmation that the existing app can support client access, followed by a scope and estimate you can use. You should be able to decide whether to continue when that work ends.
Ask what the fee gets you
Once the scope is clearer, I separate the work we can reuse from the work the project adds. I look at the flows and screen states that need designing, the components that need building, and the connections to the existing product. Feedback, testing, and handover need time too.
If several screens use the same new table component, the estimate includes that component once and the work needed to use it on each screen. Each use still needs the right data and behavior. A version-comparison view adds design and implementation work that a plain approval status doesn’t. Those differences help me estimate the effort behind the fee.
Two quotes can use the same feature name while assigning different work to your team. Check who owns each part.
If you’re commissioning design only, your engineers still need time to build it. If I’m building the interface and your team owns the backend, we need to agree on what they’ll provide and when. Work assigned to your team still belongs in your budget.
Even with the same scope, people will quote different fees. Experience, rates, and how they run their business affect the price. An agency may include coordination and specialist time that a freelancer’s quote doesn’t. Ask who is doing the work and what responsibility they’re taking. Price alone won’t tell you that.
The billing arrangement matters too. With a fixed fee, we agree on the work and what counts as finished. I allow for uncertainty within that scope when setting the price. Once you accept the quote, the fee stays fixed for the agreed work. If that work takes me longer than I expected, the extra time is mine to cover.
With hourly or daily billing, you pay for the time used. Ask for an estimate, a spending limit, and a point where work stops for your approval.
Before comparing totals, have each person mark their assumptions and exclusions. If one expects your engineer to connect the screens and another includes that work, you have a difference you can account for. I’ve covered choosing the person in more detail in my freelance designer hiring guide.
Learnway. Search, topic filters, and path generation share a screen, with different work behind each.
Share the budget while we can still change the scope
I understand the hesitation to share a budget. You want to find out what the work costs without every quote landing at your maximum. It’s reasonable to ask for an initial range and what it assumes.
When we’re deciding what to build, though, knowing your limit helps. I can suggest a smaller version, use more of what you already have, or tell you that the project won’t fit. I’d rather have that conversation before designing something you can’t afford to develop.
Basecamp’s Shape Up starts with how much time a problem deserves, then shapes the solution to fit. I like bringing that constraint into a budget conversation. There are usually choices to make before every feature becomes a commitment.
Suppose your approval wish list includes several approvers, comments pinned to an image, automatic reminders, and a screen for comparing versions. If the quote is beyond your budget, I’d discuss cuts like these with you.
You still get a client approval feature. Your team takes on the reminders, and the client coordinates their internal agreement. Those are real compromises. If someone will spend hours chasing approvals every week, keeping the reminders may be worth more to you than another part of the project.
I’d keep the work needed to save decisions correctly, prevent clients from opening each other’s files, and recover when a save fails. Phone layouts and keyboard access belong in the agreed design too. I’d cut a feature before leaving the remaining flow half working.
Early wireframes for MyDrip, working through preferences and photo uploads before the finished visual design.
For an illustration of the budget, suppose the fuller version is quoted at $10,000 and the smaller one at $7,000. These are invented amounts in USD, not my rates or a price for this feature. Assume the existing accounts and file storage have been checked and can be reused.
Your total allowance might look like this, with some money held back for additions or costs outside the quote.
The lower fee follows a reduction in work. It still takes time to understand the app and get the remaining feature ready for customers. You can’t assume that removing half the items from a wish list will halve the quote.
The money held back stays under your control. It can cover separately agreed additions, such as a new integration, or costs explicitly excluded from the quote. Spending it requires your approval. The fixed fee already covers delivery of the agreed work, including the uncertainty I allowed for when pricing it. These amounts don’t prescribe a percentage. If an unresolved dependency could change the scope, investigate it before accepting a fixed quote.
You can also ask about a discount. I may lower a fee when there’s a good prospect of more work with a client, depending on what I know about the relationship. A mention of future projects doesn’t automatically earn a discount. If the price changes, write down whether the work changed too. A discounted fee still buys the same agreed work unless we explicitly change the scope.
Budget for getting it live and keeping it running
The example above adds a feature to an existing web app. If you’re commissioning a new SaaS product, accounts, billing, file storage, and other basic functions may all need to be built or connected. A marketing website is another piece of work. Don’t use a feature budget as a budget for the whole product.
Ask for recurring costs alongside the delivery fee. Hosting, email, storage, and other services can keep charging after the project ends. Maintenance needs an owner and an allowance too. Confirm what the initial support period covers and how later work will be priced.
There may also be work for you before launch. Someone has to supply content, set up service accounts, and review what has been built. If your engineers are involved, include their availability in the schedule. For a website, be specific about who writes the copy and supplies the images. Finished layouts can still be waiting on a lot of content.
Phidata’s landing page, with desktop, mobile, and navigation layouts included in the design work.
Agree on milestones and payment dates so you know when the money is needed. Each review should have a clear decision to make, and someone on your side who can make it. If several people need to contribute, leave time to collect their feedback before sending it back.
Agree on changes before paying for them
Suppose you see the first version and realize you need a second approver. That’s a reasonable thing to discover. It also changes the job.
The app now needs to handle one person approving while another requests changes. It needs to show who is still waiting and when the draft counts as approved. Adding a second name on the screen is a small part of that work.
I’d explain what changes in the estimate and schedule before starting it. You could replace something else in the scope, approve the additional cost, or leave it for later. You should get to choose.
That doesn’t mean every piece of feedback is extra work. If we agreed that approval belongs to a particular draft and the app saves it against the wrong one, the delivered behavior is wrong. Fixing it is part of meeting the agreement. Ask what counts as a revision, a defect, or an addition before work starts. The review allowance and support period should be clear too.
Bring enough to start a conversation
You don’t need to send me a document that answers every technical question. For the approval example, this would be enough to start.
We have a working project app, but our customers still approve drafts over email. We want them to approve or request changes in the app, and we need to know which version they reviewed.
We have accounts and file uploads already. Our engineer can walk you through them. One approver and text feedback would be enough for now, and our team can send reminders manually.
We have up to $8,000 available for this work, including some room for unknowns. We need help with design and development. Please explain what you’d include, what you’d need from our team, and whether this can fit before we commit.
Add your deadline and why it matters. Show me what exists, tell me what you’re unsure about, and name the person who will make decisions with me. I can help turn that into a scope and a quote you can judge.
Work with me
I work with founders and product teams on SaaS UI/UX, website design, and React frontend development. I can help define the scope, design the flows, and build the interface on your team’s backend. If the product needs reusable components, I can include a design system in the work.
Bring the problem, what you already have, and any budget or deadline you’re working within. I’ll help work out what fits, what can wait, and what needs investigating before I can quote. Rough ideas and sketches are enough to start that conversation.
Use the inquiry form below to tell me what you’re trying to get done, and we can work out the next step together.
