Why We Stopped Taking One-Off Projects

We stopped taking one-off software projects in 2024. The math was simple: a $40K build-and-handoff project costs nearly as much to sell, scope, and onboard as a $100K/year embedded partnership — but the partnership compounds while the project ends.

This isn't a thought piece about the theory of recurring revenue. It's the specific story of why a boutique engineering team in Bengaluru changed its entire business model — and what it means for clients who are evaluating us.

What was wrong with the project model?

Nothing, in isolation. We built good software on project contracts for seven years. Custom CRMs, eCommerce platforms, enterprise workflow systems — delivered, deployed, handed off. Clients were satisfied. Reviews were strong. The work was real.

The problem was structural. Every project followed the same cycle: 2–4 weeks of sales and scoping, 3–6 months of development, a handoff, and then silence. We'd invest significant effort understanding the client's business, build institutional knowledge about their systems, train a team on their domain — and then throw all of that away when the invoice was paid.

Then the client would come back in 8 months with a new requirement. We'd re-scope. The original engineers had moved to other projects. The context was gone. We'd spend 3–4 weeks rebuilding knowledge we'd already had. The client paid for that ramp time. We burned capacity on it. Nobody won.

What does the math actually look like?

Here are real numbers from our own books, anonymised but accurate.

A typical one-off project: $40,000–$80,000 in revenue. Sales cycle: 3–6 weeks. Onboarding and context-building: 2–3 weeks. Development: 3–5 months. Post-launch support: 30 days included, then the client is on their own. Total internal cost to deliver (including sales, scoping, onboarding, development, QA, deployment): roughly 70–75% of the revenue. Margin: 25–30%.

A typical partnership engagement: $8,000–$15,000/month. Sales cycle: 2–4 weeks. Onboarding: 3–4 weeks (longer, but amortised over years). Development: ongoing. Annual revenue per partnership: $96,000–$180,000. Total internal cost: 55–65% of revenue (lower because there's no repeated sales and onboarding cycle). Margin: 35–45%.

The partnership generates 2–3x the revenue of a project with better margins. And it compounds: year two of a partnership has zero sales cost and near-zero onboarding cost. The margin improves every year the relationship continues.

Why are partnerships better for clients too?

The argument so far is about our business model. Fair. But the shift also produces better outcomes for clients, and that's the part that convinced us.

Software needs maintenance. A $60K custom system that gets no updates, no dependency patches, no security fixes, and no feature iteration for 12 months after handoff is a liability, not an asset. In a project model, the client either hires internal engineers to maintain it (expensive) or lets it degrade (risky). In a partnership model, maintenance is built in.

The team gets better over time. An engineer who's been on a client's codebase for 12 months ships features 3–5x faster than a new engineer in month one. That accumulated knowledge is the most undervalued asset in software development. The project model destroys it every time.

Priorities change, and the team adapts. In month four, the client realises the reporting module matters more than the mobile app. In a project model, that's a change order — re-scoping, re-quoting, delays. In a partnership model, the team shifts priorities in the next sprint. The work continues without friction.

The proof is visible in our longest engagements. One enterprise client — Tejas Networks, a publicly listed company — has worked with us across four separate systems over multiple years. Each system built on the knowledge from the previous one. The fourth system was scoped and delivered twice as fast as the first, not because the work was simpler but because the team understood the business deeply.

What did we stop doing specifically?

We stopped accepting engagements structured as "build X, hand it off, done." If a potential client wants a one-time build with no ongoing relationship, we refer them elsewhere. We have a network of firms that do great project work. We don't compete with them anymore.

We stopped quoting fixed-price projects without an ongoing phase. Every proposal now includes a build phase (the initial system) and a partnership phase (ongoing development, maintenance, and iteration). The client can choose not to continue after the build phase, but the engagement is structured to make continuation natural.

We stopped working with clients who don't have a product roadmap beyond the first release. Not because we're selective for its own sake — because a client who thinks the first release is the finish line will be disappointed when the software needs updates, and we'll be stuck choosing between providing unpaid support or watching the system degrade.

Doesn't this limit who you can work with?

Yes. Deliberately.

We turn away roughly 40% of inbound inquiries that would have been viable projects under the old model. Most of those are sub-$30K one-time builds from the domestic Indian market. Some are US or UK companies looking for a quick, cheap build without a long-term plan.

The clients we work with now are SaaS founders who need an ongoing engineering team, agencies that need a white-label development partner for their client work, and enterprises with multi-year technology roadmaps. These clients want a team that stays. That's what we provide.

The result: our average engagement length has grown from 4.5 months (under the project model) to over 18 months (under the partnership model). Revenue per client has tripled. And the quality of our work has improved because the team understands each client's business at a depth that three-month projects never allowed.

What does a partnership engagement actually look like?

Month 1: onboarding and first sprint. The team learns the business, the codebase (if one exists), and the product vision. The first sprint ships something small and real — not to prove we can code, but to establish the working rhythm.

Months 2–4: building the core system. This is the equivalent of the old "project" — but with a team that knows they'll be maintaining and extending this code for years. The architecture decisions are different when you know you'll live with them. Less cutting corners. More investment in testing, documentation, and clean interfaces.

Months 5+: iteration and extension. New features based on real user feedback. Performance improvements. Integrations with other systems. AI capabilities layered in where they add value. This is where the partnership model pays off — the velocity in month eight is dramatically higher than month two because the team knows the system inside out.

Throughout: weekly sync calls, sprint demos, monthly reviews. Our founder is on every account. The client knows who's responsible, and it's a named person with the authority to make decisions — not a project manager relaying messages.

What if I only need a one-time build?

Then we're probably not the right fit, and that's fine. The market has plenty of capable firms that specialise in project-based delivery. We can refer you to firms we trust.

But before you decide you only need a one-time build, ask yourself: what happens after launch? Who fixes the bug a user finds in week three? Who updates the dependencies when a security vulnerability is disclosed? Who builds the feature your biggest client requests in month four? If the answer is "my internal team," you're set. If the answer is "I'll figure it out later," you need a partner, not a project.