Scope Blueprint
One product/workflow; requirements and bounded source/API review; architecture, acceptance and next quote. No implementation.
Connect systems, build an application or improve what you already have. Start with an outcome, then choose a scope.
Packages give you a starting scope and a visible estimate. The proposal makes it specific to your project.
We confirm the existing systems, supported targets, acceptance checks and costs before work begins. An appropriate existing product can be a better fit than a custom build.
Search the full service catalog, or explore by family. Each package has defined limits and its own route to a proposal.
59 scopes across 17 groups · USD, before tax and provider costs
One product/workflow; requirements and bounded source/API review; architecture, acceptance and next quote. No implementation.
One technical question, representative data/target and test/report; may conclude no-go. Production is separate.
One maintained connector, one system and one client; supported setup, authorized sample read and handoff. No new server/code/auth flow.
One documented API; five reads; local stdio and one named client; schemas/errors/tests/source/setup.
One upstream, existing OAuth issuer, eight operations incl. two reversible writes, two existing roles; one hosted client/environment.
One source, destination, trigger and mapping with safe retry/readback. Existing documented APIs; no novel sync engine.
Five page types in one language with supplied content and assets, enquiry form, metadata and deployment.
One workflow, six views, two roles, managed sign-in/database, search/filter/CSV export and one production environment.
Two related workflows, eight views, three roles and two documented external API slots; one may be ordinary hosted checkout.
One app/workflow, managed auth, two roles, up to four entities and six bounded documented application endpoints, one production deployment and tests/runbook. No standalone admin UI.
Up to six bounded endpoints for the same existing app/database/roles; external-client token/permission contracts and fixtures. No second backend or migration.
Menu-bar/single-window local workflow; three views, persistence and one ordinary OS integration; one Mac target/direct signed-notarized release.
Five views, one existing backend/API/sign-in and offline/retry states; one Mac target/direct release. New backend separate.
One shared UI/core local workflow, up to four views; one named OS/architecture, persistence, installer and graphical checks.
One shared UI/core connected workflow, six views, existing auth/backend, offline/retry; one named OS and installer/graphical checks.
One Swift/Kotlin phone client, four local screens, persistence/preferences, one physical target and beta delivery.
One Swift/Kotlin phone client, six screens, existing auth/backend/API, scoped cache/offline/retry, beta and one public submission.
One shared-code phone UI, four local screens and one OS target; framework/plugin spike required before fixed quote. Includes beta distribution on the selected OS; routine compatibility slice included. Material uncertainty may need separately agreed $2,000 feasibility study before a fixed build quote.
Six screens, existing auth/API, one shared codebase and one phone target; provider/plugin compatibility probe first. Includes beta plus one eligible public submission on the selected OS; routine compatibility slice included. Material uncertainty may need separately agreed $2,000 feasibility study before fixed quote.
One requirement/workload/OS; minimal experiment and suitability/integration report. No production component.
Three commands, one documented input/output contract, one OS, tests/build/package/runbook. Qualify unfamiliar I/O/concurrency.
One narrowly defined native component or interactive journey on one target with representative test/demo harness; no full engine/game.
One symptom/workload/platform; measured baseline, findings and intervention/no-go report.
One agreed intervention after investigation; correctness/regressions and representative before/after measurements.
One symptom/repository/environment and reproducible sample; findings/fix quote, no guaranteed root cause if verification is insufficient.
One agreed diagnosed root cause/code path; patch, regression checks and one available test deployment/package. Diagnosis separate.
One bounded module/repository area, dependency/build/maintainability/error-path review and prioritized report. No penetration test/certification.
Existing qualified 300 USD issue agreed in writing; agreed supported release scope.
More involved but bounded eligible release fault; agreed supported release scope.
Already-buildable app; eligible signing/notarization/direct package within the agreed scope. No new product features.
Direct release plus one agreed tested update path, agreed release scope.
Eligible direct release and repeatable build/release workflow, agreed release scope.
Existing buildable app, eligible account/internal TestFlight scope.
One existing ready product/account and public submission under agreed release scope; acceptance is Apple decision.
Existing eligible build/account, internal Store beta channel.
Existing eligible product, listing/upload/submission scope.
Existing buildable Android app, signing and one testing APK/internal testing channel. Account/required testing eligibility verified.
Existing ready eligible Android app/account, listing/upload and one submission plus one metadata/config correction.
One existing repository/pipeline, up to three already-supported targets and tagged test-artifact workflow.
One existing already-buildable product, one named OS/architecture/channel, installer/archive and install/smoke verification.
One document class, one source and one destination; up to 30 documents/200 pages and ten fields, with a review queue, provenance and measured evaluation. Production operation is separate.
Same qualified pipeline including the $4,500 pilot; production retry/monitoring/retention at agreed volume.
One approved text-readable collection, up to 100 documents/1,000 pages and 30 agreed questions, with source-linked retrieval and evaluation. OCR, multiple permission domains and production migration are separate.
One repo/environment, two existing tools, one adapter if needed and 20 cases; repeat/error/recovery handoff.
One existing workstation/profile and up to three supported tool connections, project instructions/navigation and verified handoff.
One workflow/two existing systems/provider, review point, 30 cases, audit/retry/stop and test deployment.
One voice provider, one application journey/target, 20 synthetic evaluation utterances and failure/manual handoff demo.
One named browser, one ordinary site/workflow, one UI surface, minimal permissions, persistence/error checks and unpacked test package.
One browser, up to three supported site patterns in one workflow, settings and privacy/permission tests. No covert messaging/login bypass.
One supplied template, one structured input, one output up to 3 pages, fields/layout validation and reproducible renderer/source.
One structured source, two related templates/output variants up to 10 pages each, repeatable export and text/layout checks.
One source/destination family, inspected sample, inventory/count/rights/data-risk review and dry-run/rollback plan.
One assessed clean source/destination, up to 5 entities/50000 rows, mapping/reconciliation and rollback proof. No auth-provider cutover by default.
One authorized local file/application workflow, one host OS and guarded recovery/test path. No broad system/backup administration.
One browser scene or review board, up to ten ready, licensed assets, five interactions, one agreed browser/device target, and a review/sharing path. New modeling and rendering production are separate.
One technical question/reference scenario, assumptions and reproducible feasibility report.
One study-qualified algorithm/model/input/output/test/demo, separately priced after the $2,000 study.
One supported product, up to 3 engineering/review hours, scheduled review/minor corrections; no 24/7 SLA.
One product/queue, up to 16 engineering/review hours and scoped release when feasible.
These amounts are service estimates, not an automatic commitment. Technical fit, target access, reuse conditions and actual third-party costs are reviewed in the written proposal. Custom requirements can be included for review.
A shared foundation can connect your browser, mobile and desktop experiences.
A backend, data contract or design can be reused when it fits. Each native client and named operating-system target still needs its own implementation, integration and checks.
Explore combined packages in the configurator. New backend work, additional architectures, special hardware and complex sync need an inspected scope.
Understand estimates and reuseYes. A defined feature, connector, diagnosis or release milestone can fit within an existing product or team. Access, ownership, communication and handover are agreed in the scope.
Each package names its platforms and targets. Native iOS and Android clients are separate from a shared-code app. A shared desktop product still needs an artifact and graphical checks on each agreed operating system.
The listed scope and its stated limits. Provider costs, accounts, usage, hardware and new requirements are separate unless included in the proposal. “From” amounts and review-required estimates need qualification.
The desired result, what already exists, a public link if available, and any budget or timing constraints. Keep passwords, keys, private logs and sensitive material out of the initial form.
Configure the work, then add the details for a proposal.
Configure your project