Early in my career as a software architect and technology founder, I noticed a painful pattern recurring across our industry:
A client hires a software agency or dev shop. The sales team promises the moon with an estimated "hourly bucket." Two months in, the client has spent 70% of their budget, attended dozens of Jira status calls, and has yet to see a single line of working software running in their own environment.
The client feels burned. The developers feel burnt out from shifting requirements. And nobody is happy with the result.
When I founded AnyPlace, I made a deliberate choice to ban "black-box" hourly billing and ambiguous retainers. Instead, we instituted four strict engineering rules that fundamentally transformed our delivery velocity and client trust across 50+ builds.
Here is what we learned—and why I believe modern software teams need to adopt these practices.
Rule 1: Working Software in the Client's Repo Every 7 Days
If code only exists on a local dev machine or a staging server the client can't inspect, it doesn't count as progress.
Every single week, we enforce a hard checkpoint:
- Every sprint ends with tested pull requests merged directly into the client’s private repository.
- We schedule a live 20-minute screen share demo showing actual functionality passing acceptance criteria.
- If a feature is 90% done, we don't present a slide deck explaining why—we demonstrate the working 90% and document the remaining 10%.
Why this matters: When clients see working code continuously progressing in their own GitHub or GitLab repos, anxiety evaporates. More importantly, it forces engineers to write modular, runnable, deployable commits every week rather than hoarding monolithic codebases until the night before a deadline.
// Good software delivery is continuous integration of business value:
interface WeeklySprintDelivery {
pullRequest: "clean, reviewed, tested";
destination: "client_owned_repository";
demoVerification: "real data, actual user flow";
surprises: 0;
}
Rule 2: Fixed Scope Over "Open-Ended" Retainers
The tech industry loves "time-and-materials" because it shifts 100% of the risk onto the customer. But open-ended hourly billing incentivizes slow delivery and perpetual refactoring.
Instead, we invest heavily in a 1–2 week Discovery Phase upfront:
- We map data flows, authentication boundaries, and third-party API dependencies.
- We draft a written architectural specification with strict milestones.
- The Golden Rule: If it isn't in the scope document, it isn't built. If it is in the scope document, it is delivered for the agreed price.
Does scope ever need to change mid-project? Of course. But with a fixed scope in place, scope changes become conscious business trade-offs: "Feature X can replace Feature Y in sprint 4 without increasing budget, or we can add Milestone 5 after the core release."
No passive-aggressive budget creep.
Rule 3: 100% Client Code & Asset Custody From Day 1
One of the dirtiest secrets in traditional IT outsourcing is "vendor lock-in." Agencies hold code hostage in private cloud accounts or build convoluted proprietary setups so the client can never leave.
We take the opposite approach:
- We build in the client’s GitHub/GitLab org.
- We provision cloud environments (AWS, Azure, Supabase, Cloudflare) directly inside the client's accounts.
- Handover isn't an afterthought—it includes automated CI/CD pipelines, architectural READMEs, environment variable dictionaries, and seed scripts.
The counter-intuitive result: When clients know they can walk away at any time because they own everything, they almost never walk away. They stay because the delivery is dependable.
Rule 4: Plain-Language Architectural Honesty (The "No-Go" Rule)
As engineers, it is tempting to build shiny, complex things. When a client comes to us asking for a distributed microservices setup or a custom fine-tuned LLM, our default response isn't immediately: "Sure, let's build it!"
Our job is to ask:
"Does your current traffic volume warrant the operational overhead of Kubernetes?"
"Can this problem be solved with a clean PostgreSQL query and a cron job instead of an expensive event-driven architecture?"
Saying "No, you don't need this yet" has cost us short-term deal sizes, but it has earned us lifelong technical partnerships.
Engineering leadership is not about showing off how complex you can make a system; it is about finding the most resilient, maintainable path to business value.
Final Thoughts: Craft Over Chaos
Software doesn't have to be a gamble.
When you combine fixed milestone scoping, weekly repository commits, and zero-ego architectural discipline, software delivery becomes predictable, enjoyable, and genuinely valuable for everyone involved.
I'd love to hear from other tech leads and developers in the comments:
- How does your team handle client demos and repository ownership?
- Have you moved away from hourly billing toward milestone-based execution?
Let's discuss!
Dr. Shruti Mehta is a technology strategist and the founder of AnyPlace, a senior-led software studio building web platforms, mobile apps, and AI solutions for global businesses.
Top comments (0)