Can you split the app and the back office between two vendors? Use a 'split-risk score': 8 items, 16 points max; at 9 or more, give it to one vendor or appoint a lead contractor, because splitting often adds 15–25% in coordination and integration cost

Short answer: You can split, but most small businesses shouldn't. Score 8 factors from 0 to 2 on a split-risk score; at 9 or more, give the work to one vendor or appoint a lead contractor. Splitting between two vendors often adds 15–25% in coordination and integration cost, and when something breaks, each blames the other.

A real client problem: two quotes were cheaper, then cost three extra months

A 25-person fitness chain needed a member app and a booking back office. Vendor A quoted NT$450K for the app, vendor B NT$380K for the back office: NT$120K less than one vendor's NT$950K. After kick-off the API spec went through 6 versions, each side waited on the other, and launch slipped 3 months. When billing errors appeared, each vendor said it was the other's fault. The owner then paid a consultant NT$80K for integration testing, and most of the savings were gone.

Myths, busted

Splitting saves on the quote, not on total project cost.

• Myth 1: picking the best at each part means better quality. Reality: quality usually breaks at interfaces and data definitions; two well-built halves can still fail when joined.
• Myth 2: an API document is enough to divide the work. Reality: documents list fields, not flows. Refunds, cancellations and offline retries must be defined together to stay consistent.
• Myth 3: splitting avoids lock-in. Reality: lock-in is avoided by owning the source code, documentation and hosting access.

Core framework: the split-risk score

Score 8 items from 0 to 2; the higher the total, the less you should split.

0–5: you can split; 6–8: split only with a lead contractor; 9+: one vendor.

Three typical scenarios

The same split leads to different conclusions depending on size and maturity.

• Scenario A | Stable back office, adding an app (4 points): split; the app vendor builds to the existing API.
• Scenario B | E-commerce site plus separate campaign pages (6 points): split, with the site vendor as lead owning member and order data specs.
• Scenario C | New member app plus booking and billing back office (12 points): one vendor. Payments, bookings and notifications interact heavily, and splitting almost always means delay.

The full list of hidden costs

Most of the extra cost of splitting never appears on either quote.

• Interface meetings: 1–2 hours a week × 3 parties, about 40–70 hours over 3 months.
• API spec rework: often 10–15% of both vendors' hours.
• Integration testing: a third party or your own team, about NT$50K–150K.
• Blame resolution: 1–3 extra days per incident deciding whose problem it is.
• Two maintenance contracts: combined fees often 20–40% higher than one vendor's.

KPI scorecard for outsourcing partners

Split or not, score vendors 1–5 on 8 dimensions.

• Proactively provides API specs with version control
• Has an integration test plan and staging environment
• Error logging and monitoring (e.g. Sentry)
• Designs exception flows (refunds, cancellations, offline)
• Weekly reports and progress transparency
• Source code and documentation handover terms
• Post-launch response times (SLA)
• How change requests are priced

ScriptWalker's offer and when we're not a fit

ScriptWalker (a Taiwanese Laravel/Flutter custom development studio) builds both Laravel back offices and Flutter apps, which suits projects where one vendor owns everything (Project model). We can also act as lead contractor for the back office and API when a client already has an app vendor, and move to monthly maintenance (Retainer) after launch. System projects start at NT$80,000 and app projects at NT$150,000.

We're not a fit when:

• You only want a cheap vendor for app screens and don't care about the back office or data structure.
• You have a large in-house IT team and need short-term contract engineers only.
• You need deep native hardware features on a budget under NT$500K.

Kick-off playbook: if you still split, do this in the first 6 weeks

If you decide to split, lock the rules before work starts.

• Week 1: appoint a lead contractor responsible for API specs, staging and final integration.
• Weeks 2–3: write version one of the API in OpenAPI and have both sign off.
• Week 4: set up a shared staging environment and test data; the back office ships mock APIs so the app can start.
• Weeks 5–6: one three-way stand-up a week, handling only the spec-difference list.

Decision checklist

• ☐ Split-risk score under 9?
• ☐ A stable back-office API already exists?
• ☐ Someone in-house can read API docs?
• ☐ One vendor is appointed to integrate?
• ☐ Both agree to one OpenAPI spec?
• ☐ Shared staging environment in place?
• ☐ Contract assigns responsibility for interface errors?
• ☐ Budget reserves 15–25% for integration?
• ☐ Timeline longer than 4 months?

Frequently Asked Questions

Is it cheaper to give the app and back office to different vendors?

The quotes usually are; total cost often isn't. Splitting tends to add 15–25% in coordination and integration, plus integration testing and two maintenance fees.

When does splitting make sense?

When a stable back-office API exists and you are only adding an app or campaign pages. Light interaction, a frozen spec and an in-house technical contact keep the risk low.

Who handles integration if we split?

Always appoint a lead contractor. The lead owns the API spec, staging and final integration, and the contract states who fixes interface errors.

Next step

Holding two quotes and thinking of splitting? Send us the quotes and requirements and we'll calculate your split-risk score for free, then tell you whether to split, appoint a lead contractor or use one vendor.

• Email: [email protected]
• Phone: 0916-224-047
• LINE: @ufv9089p