At AnyPlace, we stopped using open-ended hourly retainers as our default and built delivery around four commitments: put working software in the client’s repository every seven days, define milestones before implementation, keep code and cloud accounts in the client’s control, and speak plainly when a proposed architecture seems more complex than the problem requires. The aim is to make progress visible and reduce dependence on a vendor—not to claim that one contract model suits every project.
Why change the way software work is contracted?
Hourly billing can describe how a team charges without telling a client what will be delivered, when progress will be visible, or how a change in requirements will affect the plan. AnyPlace’s alternative is an operating policy, not merely a different invoice: agree on what a milestone covers, show working increments, and leave the client with control of the software and the accounts it depends on.
As an Amazon Associate I earn from qualifying purchases.
Shruti Mehta, AnyPlace’s founder, says the approach shaped delivery and client trust across “50+ builds.” That is her reported experience; the article provides no measurement definitions, before-and-after figures, comparison group, or independent corroboration. It should be read as an account of one company’s practice, not proof that the same approach will produce the same result for every team.
Rule 1: Put working software in the client’s repository every seven days
A weekly checkpoint makes progress inspectable. In Mehta’s approach, the team merges tested pull requests into a private repository belonging to the client and demonstrates the working functionality against agreed acceptance criteria. The point is to avoid letting a large amount of work accumulate out of sight until a late-stage reveal.
#1 Best Overall
A useful checkpoint is more than a status update or a slide deck. The client should be able to see what changed in the code and observe the relevant behavior in a live demonstration. Acceptance criteria give both sides a concrete basis for discussing whether the increment does what the milestone requires.
- Before the checkpoint: agree which acceptance criteria the increment is meant to address.
- At the checkpoint: review the tested, merged work and demonstrate the functionality.
- If something is incomplete: identify what remains and how it affects the next milestone rather than presenting activity as completed value.
Rule 2: Define scope and milestones before implementation
Mehta describes a one-to-two-week discovery phase to map data flows, authentication boundaries, and third-party dependencies. The output is an architectural specification and a set of milestones that make the intended work explicit before the main build begins.
Fixed scope does not mean requirements can never change. It means a change is handled openly: the team and client agree on a trade-off against existing work or define an additional milestone. This makes the impact on scope and delivery a decision rather than an implicit expansion of an open-ended engagement.
What the discovery phase should clarify
- How data moves through the system and where it is stored or transformed.
- Which users, services, and systems can authenticate, and across which boundaries.
- Which third-party services the product depends on.
- What each milestone is expected to deliver and how completion will be reviewed.
How to handle a new request
When a request appears after milestones are agreed, decide whether it replaces or changes already planned work, or whether it belongs in an added milestone. That conversation keeps delivery expectations aligned without pretending the original scope still covers more than it did.
Rule 3: Keep code, assets, and cloud accounts in the client’s custody
The proposed default is to build in a GitHub or GitLab organization controlled by the client and provision cloud environments in accounts that belong to the client. Repository access and account ownership from the beginning reduce the risk that essential assets are available only through a vendor’s systems.
Custody also includes making the work usable by the next person who needs to operate or maintain it. Mehta lists CI/CD pipelines, architecture READMEs, environment-variable dictionaries, and seed scripts as handover materials. These should make it possible to understand how the application is built, configured, and brought into a useful state—not just where its source code sits.
Rule 4: Be candid about architectural complexity
Engineers should explain when a proposed solution may impose more operational or maintenance work than the requirements justify. Kubernetes and a custom fine-tuned large language model are examples Mehta uses to prompt that discussion; they are not blanket recommendations for or against those technologies.
Her test is whether the complexity creates enough business value to warrant its cost. She asks, “Does your current traffic volume warrant the operational overhead of Kubernetes?” and whether a clean PostgreSQL query and a cron job could solve a problem instead of an expensive event-driven architecture. The right answer depends on the actual requirements; the useful practice is to make the trade-off explicit rather than treating the most elaborate design as automatically superior.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How this differs from open-ended hourly work
The distinction is not simply hourly versus fixed billing. A client evaluating an engagement should look at how changes are approved, how work is demonstrated, who controls the repository and cloud accounts, what handover includes, and who carries the risk when estimates or requirements change. The four rules make those questions part of the delivery arrangement.
| Decision area | Open-ended hourly retainer | Milestone-based approach described by AnyPlace |
|---|---|---|
| Scope changes | How changes are approved depends on the agreement; the article does not prescribe a universal hourly-retainer process. | Handle changes as explicit trade-offs or add milestones. |
| Progress visibility | Depends on the team’s delivery and reporting practices; hourly billing alone does not specify a demonstration cadence. | Show working software against acceptance criteria every seven days. |
| Repository and cloud custody | Depends on the contract and account setup; billing method alone does not determine ownership. | Use the client’s code organization and cloud accounts from the beginning. |
| Handover | Depends on what the parties agree to provide. | Include practical materials such as CI/CD pipelines, architecture READMEs, environment-variable dictionaries, and seed scripts. |
| Estimation and change risk | The article does not establish who bears this risk; it must be defined in the agreement. | Scope changes are surfaced as trade-offs or additional milestones, making their impact a joint decision. |
This comparison describes the practices in Mehta’s article, not every hourly or milestone contract. Either structure can be written well or poorly. The operational details matter more than the billing label alone.
When these rules are useful—and what they do not guarantee
The approach is especially relevant when a client needs frequent visibility, wants to retain control of its software and infrastructure, or expects requirements to evolve and wants a clear way to decide what changes. It also gives technical teams a reason to explain architectural choices in terms of maintainability and business needs.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteIt does not remove uncertainty from software development. Discovery, acceptance criteria, milestones, repository access, and handover all need agreement and follow-through. Nor does Mehta’s account establish that these policies independently caused better outcomes across the industry. Her article, “Why We Banned Hourly Retainers: 4 Engineering Rules That Changed How We Ship Software,” appeared on DEV Community on September 18, 2026, and says it was originally published at anyplacehub.com: read the article on DEV Community.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
