Most bad contract engagements aren’t caused by bad developers or bad clients. They’re caused by a quote that was built on assumptions nobody stated out loud. A developer hears “it’s basically done, we just need someone to finish it up,” takes that at face value, and prices two weeks of work. Six weeks later, both sides are frustrated: the client feels like they’re being nickel-and-dimed for scope creep, and the developer feels like they walked into a project that was never actually two weeks of work to begin with. A Senior Full Stack Developer who has been through this cycle a few times learns something important. They ask a specific set of questions before a number ever leaves their mouth. That’s not because they’re being difficult. The questions themselves are a filter. How a client answers them tells you almost as much as the answers do. This piece is a working list of what to ask, why each question matters, and how to turn the answers into a quote that doesn’t quietly become a bad deal for whoever holds the risk.
Start With Scope: What Does “Done” Actually Mean?
Before anything else, a Senior Full Stack Developer needs a shared definition of the finish line. Not a feature list — a definition of done that both sides would recognize independently, without a conversation, if the project were handed to a stranger. Vague scope is the single biggest source of disputes in freelance and contract work, and it’s almost always avoidable with a handful of direct questions asked early.
Is This a Fixed Spec or an Evolving One?
Ask directly: is there a written spec that isn’t going to change, or is this a direction that’s still being figured out as the client sees the product take shape? Both are legitimate ways to run a project, but they require completely different pricing models and completely different expectations about how many rounds of revision are “included.” A client who says “we know exactly what we want” but can’t produce a document, a set of wireframes, or even a clear written description of the core user flows is telling you the spec is evolving whether they realize it or not. That’s not a red flag by itself — a lot of real projects start this way — but it changes the conversation from “what will this cost” to “how do we structure billing so an evolving scope doesn’t become free work.”
What Are the Acceptance Criteria?
For every deliverable, ask how the client will know it’s finished. “The checkout flow works” is not acceptance criteria. “A user can add an item to the cart, apply a discount code, pay with a saved card, and receive a confirmation email within 30 seconds, tested on the three browsers we support” is acceptance criteria. If the client hasn’t thought this far, that’s fine — help them get there before quoting, because the gap between “works” and “works the way the client pictured it in their head” is exactly where unpaid revision cycles come from. Get acceptance criteria in writing per milestone, not just for the project as a whole. A milestone with no defined end state is a milestone that never quite ends.
If It’s Not Greenfield, Interrogate the Codebase Before You Interrogate the Requirements
A huge share of contract work is not building something from scratch — it’s extending, fixing, or rescuing an existing system. In these cases, the requirements document tells you what the client wants to happen; it tells you almost nothing about how hard that will be to build on top of what already exists. This is where inexperienced quotes go wrong most often: the developer prices the feature and forgets to price the codebase.
Test Coverage and Technical Debt
Ask to see the test suite, not just be told it exists. Ask what percentage of the code paths that matter to this project are actually covered, and ask when the tests were last run and passing in CI, not just written at some point in the past. A codebase with no automated tests isn’t automatically a dealbreaker, but it means every change carries manual verification overhead that has to be priced in, and it means regressions are more likely to surface late. Ask about known technical debt directly — “what parts of this codebase do your own team avoid touching if they can help it?” is a better question than “is the code in good shape,” because it invites a specific, honest answer instead of a reassuring generality.
Deployment Process and Release History
Ask how code currently gets from a developer’s machine to production. Is there a CI/CD pipeline, or does someone SSH in and pull the latest branch? How often does the team actually ship, and when something breaks in production, how long does it typically take to notice and roll back? A shaky or manual deployment process doesn’t just slow down releases — it adds real risk to every milestone, because “the feature is done” and “the feature is safely in production” can be two very different amounts of work. If deployments are fragile, that’s time that belongs in the quote, not time a Senior Full Stack Developer absorbs quietly because it wasn’t listed as a deliverable.
Who Else Has Touched This Code
Ask who wrote the original system, whether they’re still reachable, and how many other developers — contractors, in-house, offshore teams — have worked on it since. A codebase that’s passed through five different contractors with five different conventions and no continuity is a different scoping problem than one maintained by a single stable team for three years. It’s also worth asking bluntly whether anyone else is actively working in the same area of the code right now. Parallel, uncoordinated work on overlapping files is a common and entirely preventable source of merge conflicts and duplicated effort, and it’s much cheaper to find out about it during scoping than during week three.
Map the Integration and Dependency Risk
Almost no serious project lives in isolation. It talks to a payment processor, pulls data from a partner API, waits on another team to finish their half of a feature, or needs a data migration that touches production records. Every one of those dependencies is a place where the timeline can slip for reasons that have nothing to do with the developer’s own work, and every one of them should be surfaced before a quote is finalized.
Ask which third-party APIs or services the project depends on, and ask pointed questions about each: is there a sandbox environment to develop against, or will testing happen against production? Is there existing documentation, or will part of the job be reverse-engineering an undocumented integration? Has the client already secured API keys and the necessary account tiers, or is that itself a pending task that could stall the start of work? A dependency on a third-party service the developer doesn’t control is a dependency on that service’s uptime, rate limits, and support responsiveness — none of which the developer can promise, and all of which deserve a line in the quote explaining that delays caused by external services are out of scope for any fixed deadline.
If the work depends on another team — internal engineers, a design agency, a separate contractor building the backend while this one builds the frontend — ask what their current timeline looks like and how firm it is. A frontend can’t be finished against an API that doesn’t exist yet, and “they should be done by then” is not a commitment. Ask what the fallback plan is if the other team slips, because if there isn’t one, that gap becomes the developer’s problem by default.
Data migrations deserve their own explicit conversation. Ask whether the project involves moving or transforming existing production data, how large that dataset is, whether there’s a recent backup and a tested rollback plan, and who signs off before a migration touches real customer data. Migrations are notorious for looking like a two-hour script and turning into a multi-day process once edge cases in years of accumulated real-world data start showing up. Treat any migration as its own milestone with its own estimate, not a bullet point folded into a larger task.
Decision-Making Authority and Change Management
Scope changes are not the problem. Unpriced, unapproved scope changes are the problem. A Senior Full Stack Developer should know, before starting, exactly who has the authority to say yes to a change and exactly how that change gets priced when it happens — because it will happen on almost every project of any real length.
Ask who the single point of decision-making contact is. Not “who’s on the project,” but specifically: whose approval is required for a scope change to be real? On projects with multiple stakeholders — a product manager, a founder, a marketing lead who all have opinions — it’s common for a developer to get verbal direction from one person, build it, and then have a different stakeholder object that it wasn’t what they wanted. That’s not a technical failure, it’s a governance failure, and it’s entirely preventable by naming one decision-maker before work starts and getting everyone else to agree to route requests through that person.
Ask how change requests will be handled procedurally. Will new requests be written down somewhere both sides can see, with an estimate attached before work begins, or is the expectation that reasonable-sounding small additions just get absorbed into the existing quote? “It’s just a small change” is one of the most expensive sentences in software development, precisely because it’s said dozens of times over a project and each one is individually easy to agree to. Set the rule in advance: any request outside the original written scope gets a written estimate and an explicit approval before it starts, even if the estimate is small. This isn’t about being rigid — it’s about making sure both sides are looking at the same running total instead of finding out at invoice time that “a few small changes” added two weeks.
Infrastructure and Access
A quote assumes a certain amount of working time per day or per week. That assumption quietly falls apart if the developer spends the first several days of the engagement waiting on credentials, VPN access, or a staging environment that doesn’t exist yet. Access delays are one of the most common and most avoidable ways a timeline slips without anyone doing anything wrong — the work simply can’t start.
Ask specifically what environments exist: is there a staging environment that mirrors production closely enough to be useful, or will testing have to happen locally against synthetic data, with the real behavior only discoverable after deployment? Ask how access is provisioned — through an internal IT process that might take days, or something the client can grant directly within an hour? It’s reasonable to ask for a target date by which repository access, environment credentials, and any required third-party accounts will be active, and it’s reasonable to note in the quote that the clock on any fixed deadline starts once access is actually granted, not on the date the contract was signed.
It’s also worth asking what the client’s security and access review process looks like, especially for anything touching customer data. Some organizations require background checks, signed data processing agreements, or security training before a contractor can touch production systems. None of that is unreasonable, but it can add days or weeks before real work begins, and it needs to be flagged and scheduled rather than discovered as a surprise once the contract is already signed and the developer is sitting idle.
Communication Cadence and Stakeholder Availability
A project cannot move faster than the client’s response time, and this is one of the most underestimated variables in any quote. A developer can be fully available, fast, and skilled, and still lose a week to a single unanswered question about which of two acceptable approaches the client prefers. Before quoting, it’s worth finding out how quickly and how reliably the client-side stakeholder actually responds — not how quickly they say they will.
Ask what the expected communication cadence is: daily standups, a weekly check-in, async updates in a shared channel? Ask who is actually available to answer questions during the work, and how quickly, realistically, that person tends to respond — a founder running three other fires at once is a very different collaborator than a product manager whose full-time job is this project. Ask what happens if the developer is blocked on a decision only the client can make: is there a backup contact, or does the project simply stall until the primary stakeholder resurfaces?
It’s fair to build response-time expectations into the agreement itself. A clause stating that questions requiring client input will be answered within one or two business days, and that delays beyond that shift the timeline accordingly, protects the developer from being blamed for a schedule slip that was actually caused by silence on the other end. It also protects the client, because it makes clear from the outset that their responsiveness is part of what they’re paying to control.
Turning the Answers Into a Quote That Protects Both Sides
All of the questions above exist to produce better inputs to the actual number. The mistake many developers make isn’t asking too few questions — it’s asking good questions and then pricing the project as if every answer had been the best-case one. A quote should reflect the real risk that surfaced during scoping, not the risk the client would prefer to hear about.
Padding for Unknowns, Not Guessing
Every unresolved answer from the questions above is an unknown, and unknowns deserve explicit padding — not a vague “add 20% to be safe” gut-check, but a specific line item tied to the specific risk. If test coverage is thin, add time for manual verification. If a third-party API is undocumented, add time for discovery before implementation begins. If access provisioning has no firm date, note that the timeline is contingent on it. Padding that’s tied to a named risk is defensible to a client and easy to explain; padding that’s just a round number tacked on “for safety” invites pushback and erodes trust, because it looks like the developer doesn’t actually know what they’re pricing.
Milestone-Based Billing vs. Fixed Price
A fixed-price quote only makes sense when the scope answers above came back clean: a written, stable spec; a healthy or well-understood codebase; minimal external dependencies; a single clear decision-maker; and confirmed access. When several of those answers came back murky — an evolving spec, an unfamiliar legacy codebase, dependencies on another team’s timeline — that’s a strong signal to move to milestone-based or time-and-materials billing instead. Breaking the engagement into milestones, each with its own defined acceptance criteria and its own estimate agreed before that phase starts, lets both sides adjust as real information emerges without either party absorbing all the risk of the unknowns discovered along the way. It also gives the client natural checkpoints to confirm the direction is still right, which reduces the odds of a large, expensive misunderstanding surfacing only at the end.
What Happens When Scope Changes Mid-Project
Because scope changes are close to inevitable, the contract should say — in plain language, agreed to before work starts — exactly what happens when they occur. That means: changes are documented in writing, changes outside the original scope get a new estimate before work on them begins, and the client’s named decision-maker has to approve that estimate. It also means being honest about the tradeoff: a change can usually be absorbed into the existing timeline and budget, or it can be added without disrupting the current plan, but rarely both. Naming that tradeoff explicitly, in the quote itself, turns a conversation that could become adversarial midway through the project into something that was already agreed to before either side had an incentive to argue about it.
The Freelancers Union publishes general guidance on contract terms worth reviewing alongside project-specific scoping. None of this is about protecting the developer at the client’s expense, or the reverse. A quote built on real answers to real questions is the version of the engagement where both sides know what they signed up for, which is the actual precondition for a project finishing on good terms. Clients evaluating whether a candidate is the right fit for hiring a senior full stack developer should treat these questions as a positive signal rather than friction — a developer who asks about acceptance criteria, codebase health, and decision-making authority before quoting is a developer who has done this enough times to know exactly where projects go wrong, and is trying to make sure this one doesn’t.
