Writing acceptance criteria for a dev project
How tight should your spec be? Story.law shows founders how to write 2026 acceptance criteria that hold a dev shop to a working result, not to hours spent.
How tight should your specification be when you hire a developer or agency? Story.law works with founders every day who are navigating exactly this question, and the answer matters more than most people realize. A well-drafted spec does three concrete things for you: it raises the probability that you receive what you actually asked for, it gives you an objective basis to refuse payment for work that does not conform, and it signals to any serious agency that you understand the build well enough to hold them accountable. This guide walks you through every layer of that process, from writing testable outcome criteria to structuring a review window, tiering defects by severity, holding back payment against final acceptance, and managing change orders so that new requests do not silently become obligations.
What Are Acceptance Criteria in a Dev Project?
Acceptance criteria are the specific, verifiable conditions that a software deliverable must satisfy before you release payment and formally accept the work. They answer the question that sits at the center of almost every software dispute: done according to whom? Without a written answer, the developer may treat a successful demo as completion while you expect production-ready functionality across all defined environments. Acceptance criteria eliminate that gap by turning your expectations into an objective checklist that both sides agreed to before a single line of code was written. When you hire a developer or agency, embedding those criteria in the contract is the single most important protective step you can take.
Why Acceptance Criteria and Specifications Matter in 2026
The legal and commercial landscape around software procurement has become more sophisticated, and founders who treat the specification as an afterthought are taking on disproportionate risk. Acceptance testing clauses now appear in the overwhelming majority of custom software development agreements, which means agencies are arriving at the negotiating table with standard language that protects their interests. If you show up without equivalent preparation, you are accepting their defaults. Story.law's approach to vendor contracting is designed to correct that imbalance. The firm's lawyers have genuine technical fluency in software development, which means they negotiate acceptance language with a working understanding of how builds actually progress, not just how contracts are supposed to read.
Beyond individual protection, a detailed specification is a diligence signal. An agency that cannot describe the build in precise terms during scoping may not understand it well enough to deliver it. Pressing for specificity early filters out that risk before you have paid a deposit.
Common Challenges When Hiring a Developer and How Specifications Solve Them
Founders who have been through a difficult dev engagement will recognize at least one of the problems below. Each one is traceable to a document problem, not just a people problem.
The Most Frequent Problems Founders Face
Vague scope definitions: When the statement of work describes outcomes in general terms like "a fully functional application" or "working software," you have no testing standard. "Working software" is an argument waiting to happen. Vague scope is the root cause of most payment disputes in software projects.
Effort-based billing without result guarantees: Some agency proposals are structured as time-and-materials engagements with language like "we will work together on the authentication module." That language can leave you owing fees for effort regardless of whether the module functions correctly. You want to pay for a result, not for hours.
No defect classification: When all bugs are treated equally, the agency can argue that any open issue is too minor to block payment. Without a severity tier system, you lose the ability to distinguish a critical failure from a cosmetic flaw, and you lose the contractual right to reject delivery on legitimate grounds.
Missing review windows: If the contract does not specify how long you have to test a deliverable, you may face a deemed-acceptance provision that automatically triggers payment after a short window. Early-stage founders who are juggling fundraising, hiring, and product decisions are particularly exposed to this risk.
No change order discipline: Scope expands gradually on almost every project. Without a written change order process, what started as a request to add one feature can become a dispute about whether you owe additional fees or whether the feature was always included in scope.
How specifications address each problem: A properly drafted specification pairs outcome criteria with constraint-based scoping. You define what the software must do (outcomes) and you specify the repository, integration points, environments, and delivery format within which it must do it (constraints). This gives the developer a workable framework while giving you a testable standard. Story.law builds this pairing into every dev project agreement it drafts, ensuring that founders are not left choosing between a spec that is too loose to enforce and one that is too prescriptive to be realistic.
What to Include in a Software Project Specification
A strong specification is not a product roadmap. It is the contractual exhibit that defines what the developer must build and how you will verify that they built it. The level of detail you need depends on the contract model: a fixed-price build requires a more complete specification up front than a milestone-based agile engagement. Either way, the core elements below belong in your document.
The Essential Components of Your Specification
Functional requirements by feature: List every feature the build must include. For each feature, state what it must do in terms a non-developer can verify. If the software must process payments, generate reports, handle user permissions, or sync with a third-party platform, say that directly in the specification rather than referencing it by category.
Non-functional requirements: Specify performance thresholds, uptime expectations, browser or device compatibility, and security standards. If the application must load a dashboard in under two seconds under a defined concurrent user load, write that number down. Quantified criteria are testable; qualitative descriptions are not.
Integration points and environments: Name every third-party system the build must connect to and specify the environment in which it must operate. Define the staging and production environments. Specify the repository and the handover format so there is no ambiguity about what you will receive at the end of the engagement.
Explicit exclusions: State clearly what is not included in the current scope. Mobile app development, internationalization, legacy data migration, and ongoing maintenance are common items that founders assume are included but agencies assume are out of scope. Naming exclusions protects both parties.
Delivery format and handover requirements: Define what a complete handover looks like. This includes source code access, deployment scripts, API documentation, credentials, and any training materials. If the developer retains access to production infrastructure after handover, that is a leverage point you want to close before the project ends.
Milestone structure: Break the project into discrete milestones, each with its own acceptance criteria. Applying acceptance criteria only to the final delivery puts too much pressure on that single moment and creates resentment that accumulates across the engagement. Milestone-level criteria let you catch problems early and adjust before they compound.
A practical note on limits: a developer genuinely cannot specify every implementation detail up front, and demanding that they do so can drive away capable agencies or produce a specification that is technically unrealistic. Pair your outcome criteria with constraint-based scoping rather than prescribing the technical approach. You are buying a result, not supervising an implementation.
Clause-by-Clause Table: The Acceptance Framework
The table below maps each core clause to its purpose, the market standard position, and the buyer-favorable ask. Story.law marks negotiation asks as asks, not as defaults, because the law requires only what the contract states, and what you push for in negotiation is a separate question.
| Clause | Purpose | Market Standard | Buyer-Favorable Ask |
|---|---|---|---|
| Acceptance testing period | Gives you a defined window to test each deliverable against the specification | 15 to 20 business days from delivery notice | 30 calendar days; negotiation ask |
| Defect severity tiers | Distinguishes critical failures from minor issues so rejection rights are calibrated correctly | Critical and High defects block acceptance; Minor defects go on a post-acceptance punch list | Four tiers (Critical, High, Medium, Low) with separate cure timelines; negotiation ask |
| Cure cycles | Gives the developer a defined chance to fix rejected work before escalation | Two cure cycles before termination rights engage | Two cure cycles with a right to terminate and recover fees after the second failure; negotiation ask |
| Deemed acceptance | Defines what happens if you stay silent after the review window closes | Silence after the review window triggers acceptance | Require affirmative written acceptance; no deemed acceptance by silence or by production use; negotiation ask |
| Holdback against final acceptance | Retains a portion of the total fee until final acceptance is confirmed | Not universal; more common in larger engagements | 10 to 15% holdback released on final acceptance; negotiation ask |
| Milestone-level criteria | Applies acceptance testing to interim deliverables, not just the final build | Sometimes included, often omitted | Acceptance criteria attached to every milestone; negotiation ask |
| Change order process | Governs how scope changes are proposed, priced, and approved | Written change orders required before extra work begins | Written change order signed by both parties with a stated fee and timeline impact before any new work starts; standard ask |
| Source code escrow / handover | Ensures you receive a usable codebase regardless of how the relationship ends | Handover on final payment | Repository access transferred at each milestone; negotiation ask |
| Termination for repeated failure | Gives you an exit right if the build fails acceptance multiple times | Sometimes included | Right to terminate and recover fees paid after a defined number of failed cycles; negotiation ask |
How to Write Testable Acceptance Criteria
The practical challenge for most founders is translating product intentions into criteria that can actually be tested against. The standard is objectivity: a criterion is testable if a third party unfamiliar with the project could run the test and reach an unambiguous pass or fail result.
Writing Criteria That Hold Up
Use the Given/When/Then format for user-facing features: This format structures each criterion as a scenario. Given a defined starting state, when a specific user action occurs, then a specific outcome must result. For example: given a registered user who has completed checkout, when they navigate to order history, then they must see a list of all prior orders sorted by date, with each order displaying the order number, total, and fulfillment status. That criterion is testable. "Order history works correctly" is not.
Quantify performance thresholds: Every performance requirement should include a number, a measurement method, and a load condition. Stating that the application must be fast is not a criterion. Stating that the dashboard must render in under 1.5 seconds for a concurrent load of 500 users, measured in a staging environment configured to match production specifications, is a criterion.
Specify the test environment: Acceptance testing conducted on the developer's local machine is not the same as testing on the environment where users will actually run the software. Define the environment in which acceptance testing occurs and require the developer to replicate production conditions before submitting a deliverable for review.
Name the integration behaviors explicitly: If the software must integrate with a payment processor, a CRM, or an analytics platform, write out what a successful integration looks like for each case. A Stripe integration "working" is not a criterion. A Stripe integration that processes a live test transaction, returns a confirmed status to the application, and logs the transaction in the order database within 10 seconds is a criterion.
Separate defect tiers from acceptance standards: Not every bug should allow you to reject the entire deliverable. Define which defect tiers block acceptance and which go on a post-acceptance punch list. Critical defects that prevent core functionality justify rejection. Cosmetic issues that do not affect user flows should be catalogued and remediated after acceptance, within a defined cure window.
Apply criteria to each milestone: Acceptance criteria should attach not only to final delivery but also to interim milestones. When the first two milestones are paid against vague approval standards, the final acceptance clause carries too much pressure and too much resentment. Building criteria into each milestone distributes the verification burden across the engagement and catches misalignment before it becomes expensive.
The Review Window, Defect Tiers, and Holdback: Structuring Your Rights
Three contract mechanics do more work than any other clause combination when it comes to protecting you on a dev project. Understanding how each one operates, and how they interact, is the difference between a spec that is enforceable and one that reads well but collapses under pressure.
Review Window
The review window is the period during which you have the contractual right to test a deliverable and raise objections. The market standard for custom software development is 15 to 20 business days from the date of delivery notice. A buyer-favorable ask is 30 calendar days, particularly for complex builds or for founders who are also managing fundraising and hiring. The contract should state explicitly that the window begins on the date of a conforming delivery notice, not on the date the developer declares the work done. It should also state what a conforming delivery notice looks like: typically, written notice that the deliverable is ready for testing, accompanied by documentation sufficient to begin testing.
Watch for deemed-acceptance language that treats production use as acceptance. Some agency drafts state that if you deploy the software to production, you have accepted it, regardless of whether it passed your acceptance testing. That provision can strip your rejection rights before you have finished testing. If deemed acceptance appears in the draft, require that it be triggered only by affirmative written notice, not by silence or by deployment.
Defect Severity Tiers
A four-tier severity model gives you the calibration you need to exercise rejection rights proportionally.
Critical: The defect prevents a core function from operating at all. Examples include a payment flow that fails on every transaction, an authentication system that does not allow users to log in, or a data pipeline that corrupts records on write. Critical defects block acceptance.
High: The defect materially impairs a significant function but does not prevent all core operations. Examples include a reporting module that returns incorrect totals or an integration that fails intermittently under normal load. High defects block acceptance.
Medium: The defect impairs a non-core function or creates a degraded user experience without preventing core operations. Medium defects go on a punch list for post-acceptance remediation, with a defined cure window of 15 to 30 days.
Low: The defect is cosmetic or has minimal functional impact. Low defects are logged and scheduled for remediation without blocking acceptance or triggering cure obligations.
The contract should state that a deliverable passes acceptance if it performs all functions described in the applicable specification without Critical or High defects. That formulation gives you a clean standard and prevents the developer from arguing that a High-severity defect is merely cosmetic.
Holdback Against Final Acceptance
A holdback is a portion of the total contract fee retained by you until final acceptance is confirmed. It is one of your most effective negotiating tools because it keeps the developer financially engaged through the testing and correction phase. A market-standard holdback for a custom software project is 10 to 15% of the total fee, released on written confirmation of final acceptance. If you can negotiate it, tie the holdback release to a defined post-launch stability period, typically 30 days, during which the developer remains obligated to remediate any Critical or High defects that emerge under real user load.
Milestone-level holdbacks are a negotiation ask but worth pursuing on larger builds. Structuring each milestone payment so that 85 to 90% is paid on delivery and 10 to 15% is held until the next milestone passes acceptance creates a rolling financial incentive for quality at every stage.
The Change Order Process: Protecting Your Budget and Your Scope
Scope expansion is the most common way a fixed budget becomes an open-ended obligation. The mechanism is almost always the same: a founder makes a request that seems small, the developer completes the work without raising a formal change order, and weeks later there is a dispute about whether the work was always included in scope or represents a billable addition. A written change order process cuts that ambiguity at the source.
Building a Change Order Process That Works
The change order clause should state that no work outside the original scope will be performed without a written change order signed by authorized representatives of both parties before the work begins. The change order document itself should specify the nature of the change, the additional fee (or fee credit), the revised timeline, and any impact on downstream milestones. Verbal approvals and Slack messages are not change orders.
The clause should also define what constitutes a scope change versus a defect remediation. Failure to meet the agreed specification is a remediation obligation that falls within the original fee. A new feature request, an integration with a platform not named in the original specification, or a change to a functional requirement that was previously agreed is a scope change that requires a change order. That distinction matters because it is the line between work the developer owes you and work you owe the developer additional fees for.
Warn against the "we will work together on X" formulation in any contract or statement of work. That language is effort-based, not result-based. It creates an obligation to pay for activity rather than for a defined output, and it gives you no basis to refuse payment if the collaborative effort does not produce a working result.
Can You Refuse to Pay a Developer If the Software Doesn't Work?
This is one of the most common questions Story.law hears from founders after a development engagement goes wrong. The short answer is: it depends entirely on what your contract says.
If your contract ties payment to milestone acceptance and the deliverable has not passed acceptance testing, you have a contractual basis to withhold that payment. The stronger your acceptance criteria, the cleaner that basis is. If the contract is silent on acceptance standards, or if it uses vague language like "satisfactory completion," you are in a disputed interpretation of what the developer owed you, and that dispute is expensive to resolve.
The law does not automatically give you a right to withhold payment because you are unhappy with the result. Your right to withhold depends on the express terms of the contract, the applicable state law, and whether the developer's performance can be characterized as a material breach. Some jurisdictions have prompt payment frameworks that add procedural requirements to withholding, even when a contractual right exists.
The practical implication is this: the time to establish your withholding rights is before the project starts, not after a deliverable fails. A contract with objective acceptance criteria, defined rejection rights, and a written cure process gives you a defensible position. A contract without those provisions leaves you arguing about subjective expectations in a forum where the developer can claim they completed the work they were hired to do.
Story.law drafts development agreements specifically to address this gap. The goal is to give you a contractual right that tracks the actual failure, not a general grievance that a court or arbitrator will struggle to evaluate.
Best Practices and Expert Tips for Founders Hiring Developers
The guidance below reflects what Story.law has observed across a broad range of development engagements. Each tip is actionable before you sign.
Treat the specification review as a diligence interview: Before you sign, ask the agency to walk you through how they would test each major criterion in your specification. An agency that cannot describe a concrete testing approach for a feature may not understand it well enough to build it. Their ability to engage with your criteria is evidence of their technical competence.
Do not let the agency draft both the spec and the contract: When the agency defines the scope and writes the acceptance language, their defaults govern. At minimum, you should have independent counsel review the acceptance clause, the payment terms, and the change order process before you sign. Story.law can generate and review that language through Aegis, its AI-native legal platform, at a fraction of what a traditional legal review would cost.
Attach the specification as a contract exhibit, not a separate document: The specification should be incorporated by reference into the contract with language that makes clear it governs acceptance testing. A specification that lives in a project management tool or a shared drive is not a contract document. It can be modified without triggering a formal change order, and it can be disputed as non-binding.
Require written delivery notices for every milestone: The acceptance window should start on a specific, documentable event. Requiring a written delivery notice, rather than treating a demo or a Slack message as delivery, gives you a clear record of when your review period began and prevents disputes about whether a milestone was formally submitted.
Build in a stability period after final acceptance: The warranty period should begin on final acceptance and should cover defects that emerge under real user load, not just those identified during controlled testing. A 90-day post-acceptance warranty is a reasonable ask for a custom build. Tie the warranty period to specific defect tiers so the developer knows exactly what they remain obligated to remediate.
Negotiate IP transfer at each milestone, not only at final payment: Many standard agency agreements transfer IP only when the final invoice clears. If the project terminates before final acceptance, you may have paid for work you cannot use. Negotiating IP transfer at each accepted milestone gives you ownership of the work product you have already paid for, regardless of how the engagement ends.
Document every request in writing: Even in an agile engagement with a collaborative working relationship, every request that might constitute a scope change should be sent in writing. That habit protects you regardless of whether the developer raises a formal change order. If a dispute arises, your written record establishes the timeline and the nature of the request.
Advantages and Benefits of a Detailed Specification and Acceptance Framework
The time invested in a rigorous specification and acceptance framework pays back across every dimension of the project. Here is how the benefits compound.
Clear scope reduces rework costs: When both parties agree in writing on what the software must do before development begins, the probability of building the wrong thing drops significantly. Rework on a custom software build typically costs more than the original build because it requires undoing existing code before replacing it.
Objective criteria reduce dispute costs: Most software disputes are resolved through negotiation rather than litigation, but negotiation takes time that a founder does not have. Objective acceptance criteria give both parties a shared factual basis for resolving disagreements quickly, without involving lawyers for the ordinary course of testing and correction.
Milestone-level acceptance improves delivery quality: Applying acceptance criteria to interim milestones creates a feedback loop that catches misalignment early. Problems identified at milestone two are dramatically cheaper to fix than problems identified at final delivery.
A holdback maintains developer motivation through the end of the project: Development engagements have a known pattern of attention: intensity is highest at the start and lowest in the final stretch, when the next client is already being onboarded. A holdback keeps the developer financially engaged through testing, correction, and handover.
A written change order process protects your budget: Scope creep is the most common reason software projects exceed budget. A written change order process does not prevent you from adding features; it ensures that every addition is priced before it is built and documented so there is no ambiguity about what you owe.
A strong spec is a diligence signal in both directions: When you go to raise capital, investors and their counsel will review your material vendor contracts. A development agreement with rigorous acceptance criteria, IP provisions, and a clear handover process is a signal that you manage operational risk carefully. An agreement that relies on handshake terms is a diligence risk.
Key Takeaways and How to Get Started
Writing acceptance criteria for a dev project is not a technical task. It is a legal and commercial task that happens to require some technical literacy. The founder who approaches it that way is in a dramatically stronger position than the one who leaves it to the agency or treats it as a formality.
The five takeaways from this guide are:
A detailed specification does three things for you: it raises the odds you get what you asked for, it gives you an objective basis to refuse nonconforming work, and it is a diligence signal.
Pair outcome criteria with constraint-based scoping. Defining what the software must do is not the same as specifying how it must be built, and the distinction matters for both enforceability and workability.
Apply acceptance criteria to every milestone, not just the final delivery. Milestone-level criteria distribute the verification burden and catch problems early.
Structure your payment to track acceptance. Milestones paid on delivery, holdback released on final acceptance, and a post-acceptance warranty period aligned to defect severity tiers.
A written change order process is not optional. Any engagement that proceeds without one will generate a scope dispute.
Story.law can generate the development agreement and acceptance framework that corresponds to this guide directly on the platform. If you are preparing to hire a developer or agency, start with a free question to Aegis and get a practitioner-reviewed agreement built around your specific build, not a generic template that protects no one.
How Story.law Helps Founders Get This Right
Story.law was built for exactly the situation this guide describes: a founder who needs real legal protection on a vendor contract but does not have the budget or the time for traditional legal fees. The Aegis platform combines attorney-drafted templates with AI-assisted customization, so you can generate a development agreement with the acceptance criteria, defect tiers, holdback provisions, and change order process described in this guide in a fraction of the time a traditional engagement would require.
Because Story.law is built by a law firm, every communication through Aegis is protected by attorney-client privilege. That distinction matters when the contract being negotiated is a development agreement that may later become relevant in a dispute, a financing, or an acquisition. Generic contract tools and template generators do not offer that protection.
Story LLP’s lawyers have technical fluency in software and AI, which means the acceptance language they draft reflects how builds actually work, including the reality that a developer cannot specify every implementation detail up front. The firm pairs outcome-based criteria with constraint-based scoping, so the specification is rigorous enough to be enforceable without being so prescriptive that no capable agency will sign it.
FAQs About Dev Project Acceptance Criteria and Specifications
What are acceptance criteria in a software development contract?
Acceptance criteria are the specific, verifiable conditions that a deliverable must satisfy before you are contractually obligated to approve it and release payment. They define the line between a build that conforms to the agreement and one that does not. In a well-drafted development contract, acceptance criteria are attached to each milestone as a contract exhibit, written in testable terms, and tied to a defined review window and defect severity tier system. Story.law drafts acceptance criteria as enforceable contract provisions, not informal checklists.
How detailed should a software project specification be?
Detailed enough that a third party unfamiliar with the project could read the specification and test each criterion without asking for clarification. That standard is practical, not theoretical. Every performance threshold should include a number. Every integration should name the third-party system and describe the expected behavior. Every exclusion should be stated explicitly. The specification does not need to prescribe the technical implementation, but it must define every outcome you intend to test. Story.law helps founders reach that standard without overreaching into implementation details that no agency can commit to up front.
Can I refuse to pay a developer if the software doesn't work?
Your right to withhold payment depends on what the contract says, not on your general dissatisfaction with the result. If the contract ties payment to milestone acceptance and the deliverable has failed a defined acceptance test, you have a contractual basis to withhold payment pending remediation. If the contract lacks objective acceptance criteria, your legal position is weaker and the dispute is more expensive to resolve. Story.law structures development agreements specifically to give you clear, defensible withholding rights that correspond to documented failures, not subjective disagreements.
What is a reasonable acceptance period for a software deliverable?
The market standard for custom software development agreements is 15 to 20 business days from a conforming delivery notice. A buyer-favorable negotiating ask is 30 calendar days, which is reasonable for complex builds or for founders managing competing operational demands. The acceptance period should be defined in the contract, should begin on a documentable event (a written delivery notice, not a demo or a Slack message), and should require affirmative written acceptance rather than treating silence as approval. Story.law recommends against deemed-acceptance provisions that are triggered by production use.
What is a holdback in a software development agreement, and should I ask for one?
A holdback is a portion of the total contract fee, typically 10 to 15%, retained by you until final acceptance is confirmed and any post-acceptance stability period has passed. It is one of the most effective tools for keeping the developer financially engaged through testing, correction, and handover. Holdbacks are a negotiation ask rather than a market default on smaller projects, but they are worth pursuing on any custom build with a significant budget. Story.law includes holdback structures in its standard development agreement templates and can calibrate the holdback amount and release conditions to the specific engagement.
What is a change order process and why does it matter?
A change order process is the contractual procedure that governs how scope changes are proposed, priced, approved, and documented after the original agreement is signed. Without one, scope expands informally, and the question of whether additional work is included in the original fee or billable as an addition becomes a dispute rather than a documented decision. A well-drafted change order clause requires that all scope changes be submitted in writing, acknowledged by the developer, and accompanied by a signed change order specifying additional fees and timeline impact before any new work begins. Story.law treats the change order process as a core commercial term, not a boilerplate addition.
What is the difference between a defect and a scope change?
A defect is a failure to meet a requirement that was included in the original specification. The developer owes you remediation of a defect within the original fee. A scope change is a request for something that was not included in the original specification. That request requires a change order and additional fees. The contract should define this distinction explicitly, because it is the line that separates work the developer owes from work you owe the developer for. Without a clear definition, every disputed item becomes a negotiation about whether it was always in scope, and those negotiations favor the party with more information about the original build.
How does Story.law help with development agreements and acceptance criteria?
Story.law provides development agreement drafting and review through its Aegis platform, which combines attorney-drafted templates with AI-assisted customization under full attorney-client privilege. The firm’s lawyers have technical fluency in software and AI, which allows them to draft acceptance criteria and specification language that is both legally enforceable and practically workable for the agency. Story.law’s Aegis platform is available at an affordable fraction of the cost of traditional legal review and is designed specifically for founders who need practitioner-quality legal protection on vendor contracts without the overhead of a traditional engagement.
We're lawyers, remember? Please read this important note:
Story LLP is a law firm, and Story's lawyers built Aegis to deliver better, standard legal services at scale so founders can choose between top-tier specialized lawyers and standardized process automations that replicate those lawyers according to their needs and budget. By definition, a standardized process may not be perfect for you. Please review our Policies page to better understand the difference, as well as how we use AI and how we manage conflicts, privilege, etc.
As a law firm, we must screen clients for conflicts of interest, and we treat all correspondence with clients seeking legal advice as privileged and confidential to the maximum extent possible in consideration of any conflicts. However, Story's law firm or our Attorney Allies do not represent you or your company as your lawyer, do not have an attorney-client relationship with you or your company, and do not provide you with legal advice absent a formal Engagement Letter signed between you and the Story LLP law firm. Please don't confuse the free knowledge we offer on this site with legal advice for you.