Five stages for API delivery and acceptance
Start with requirements, fields and access; agree API design, failure handling and source handover. Stage durations are planning references, subject to scope, platform review and input readiness.
Scope
A 30–45 minute call and a questionnaire: business operations, target APIs, existing software, account access, data volume, launch window and budget.
- ✓Scope split (phase 1 / phase 2)
- ✓Feasibility and risk list
- ✓Price range and timeline
Architecture & prototype
Define architecture, field mappings, permissions, failure flows and API specifications. Check platform access and test environments; prototype key screens where a UI is included.
- ✓Architecture, field mappings and API specification
- ✓Key workflow or screen prototype
- ✓Access and risk checklist
Build & adapt
Deliver access, field transformations, business processing, callbacks and recovery in milestones. Content systems can split accounts, publishing queues, monitoring and reports. Weekly sync, shared repository.
- ✓Runnable system per milestone
- ✓Weekly progress and blockers
- ✓API documentation draft
QA & acceptance
Use client-authorized accounts and redacted samples to verify mappings, isolation, timeouts, duplicate requests and out-of-order callbacks. Test agreed workloads and verify final business outcomes separately.
- ✓Integration report and issue list
- ✓Load test results
- ✓Signed acceptance checklist
Launch & care
Deploy to your environment, migrate data, initialise permissions, train operators and engineers, start the adaptation period.
- ✓Deployment and operations docs
- ✓Training recording
- ✓Care plan
How we work together
Cadence
A 30-minute weekly sync; day-to-day questions answered within 24 hours.
Documents
Scope, prototype, API and acceptance live in documents, not chat history.
Code
Your repository or a shared private one, committed weekly — never a single handover at the end.
Changes
Scope changes are assessed in writing: impact on time and cost confirmed before work starts.
Milestones and change control
Each stage has a defined deliverable and acceptance gate; scope changes are assessed in writing.
| Stage | Gate to next stage |
|---|---|
| Kickoff | Kickoff approved, prototype signed off |
| Core | Agreed APIs and business workflows run, with demonstrable failure handling |
| Launch | Deployed, acceptance checklist signed |
Scope changes are assessed in writing first: impact on schedule and scope, then execution. No verbal add-ons.
Risks we surface early
Platform app reviews take weeks. Then what?
Check the target platform, application type and account conditions first. External review has no fixed delivery guarantee. Field mapping, internal workflows and test preparation can proceed while waiting; validate production capability after access is granted.
What if requirements change mid-project?
Small adjustments are absorbed. Changes affecting architecture or timeline are assessed in writing, with cost and schedule confirmed before execution.
What if accounts or assets are not ready?
Development and integration can use test accounts, but acceptance needs real ones. Delays there directly delay launch — we assign owners in Stage 1.
What happens when a platform changes its API?
Minor version changes are covered during care. Major changes — a capability being withdrawn or an authorization model changing — are assessed separately, usually billed per person-day.
Working with us
Can we start with a small version?
Yes, and we recommend it. The Starter scope is one platform, one workflow, 3–4 weeks, to prove the authorization → publish → result loop before expanding.
Where are you based? Do you work remotely?
Remote-first. Everything runs online: documents, shared repositories, weekly calls. On-site visits can be arranged when needed.
What happens after the care period?
Renew annually (typically 12–18% of project value) or take it in-house. The source code and documentation are complete either way.
Step one is a 30-minute call
You leave with a scope breakdown and a price range. No obligation.