xDD vs. Turnkey: Which Engagement Model Fits Your Project

The question we hear most from a prospective client, once they're past "can you build this," isn't really about capability. It's "how do we actually work together" — and BlastAsia has two honest answers, not one, because the right answer depends on something about the project itself, not on which one sounds better in a sales conversation.

Turnkey and xDD are BlastAsia's two engagement models, and they run on the same underlying pipeline — DesignStudio for scoping and design, XamunForge for build and orchestration, SonarQube quality gates throughout. The technology isn't what's different between them. What's different is the shape of the commitment: one delivers a defined project once, the other delivers continuously for as long as the engagement runs.

Turnkey: One Scope, One Price, One Delivery

Turnkey is a fixed-scope project. Requirements get defined and agreed upfront, the price is fixed against that scope, and the whole system — anywhere from two to four weeks for a focused application to several months for a larger one — gets built and delivered as a single release, priced and scheduled against milestones agreed at contract signing. Full source code ownership transfers at completion.

This is the right model when the requirements are genuinely knowable in advance: a well-defined system with a clear feature list, a budget that needs to be locked before the project starts, and a team that doesn't need or want an ongoing relationship with the delivery partner once the system ships. It's the closest thing to a traditional software project — the difference is that BlastAsia's version runs on an AI-accelerated build pipeline instead of a purely manual one, which is why a scope that would take a traditional shop many months can often be delivered in weeks.

xDD: Continuous Delivery, Priced by What Ships

xDD is different in shape entirely. Instead of one fixed scope, a client gets full engineering, business analysis, and QA coverage on an ongoing basis, working in two-week sprints, with a working release at the end of every sprint. The first version of the product typically ships within 30 days — as fast as 21 in some engagements — and from there, the roadmap keeps evolving sprint over sprint rather than locking at contract signing.

Pricing follows the same logic: xDD is priced by features actually delivered, not hours logged or a headcount roster. And because the commitment is ongoing rather than a single fixed project, a client can step away after the sixth month if the engagement isn't earning its place — there's no multi-year lock-in on the other side of the decision.

This is the right model when the roadmap is genuinely still evolving — a product that will keep changing based on user feedback, a team that wants continuous delivery rather than a single release, or an organization that would rather pay for an ongoing engineering capability than negotiate a new fixed-scope contract every time priorities shift.

Same Factory, Different Commitment Shape

It's worth being direct about what doesn't differ between the two: the AI-accelerated build pipeline, the quality gates, the compliance scanning that runs at every module rather than just at release. A client isn't choosing between "the fast option" and "the careful option" — both are built the same way, by the same underlying Xamun Software Factory. What a client is actually choosing is a commercial and engagement shape: locked scope and price paid in milestones, versus continuous delivery priced by what ships, with the freedom to stop after six months.

How to Actually Decide

A few honest questions tend to settle it faster than a feature-by-feature comparison:

Is the scope genuinely fixed, or does it just feel that way right now? A scope that's fixed because requirements are well-understood and stable is a Turnkey scope. A scope that's fixed because nobody's had time to think past the first release is usually an xDD project wearing a Turnkey label — and it tends to reveal itself in change requests a few weeks after a Turnkey contract is signed.

Does the budget need to be locked before the project starts, or does the organization prefer to fund an ongoing capability instead? Boards and finance teams that need a defensible fixed number to approve tend to gravitate toward Turnkey. Teams that think in terms of an ongoing engineering budget, the way they'd think about a headcount line, tend to gravitate toward xDD.

Is this a project with an end state, or a product that keeps evolving? A compliance system built to a known spec has an end state. A customer-facing product that will keep responding to usage data doesn't — and forcing it into a fixed-scope contract usually means paying for change orders later that xDD's continuous model would have absorbed as part of the next sprint.

Neither model is the "better" one in the abstract. The mismatch — a genuinely evolving product forced into a fixed-scope contract, or a genuinely fixed scope kept on an open-ended continuous engagement — is where most engagement-model regret actually comes from, not from either model itself being worse.

If you're not sure which shape fits your project, that's a reasonable thing to bring to a conversation rather than decide alone — let's talk through your scope.