How we work
Work with Salt through a managed development team, dedicated developers, or a project with a defined scope. We help you choose based on your internal capacity and the work ahead.
A good fit when you need a coordinated team to deliver a product or workstream. The proposal defines development, testing, technical leadership, and reporting responsibilities.
A good fit when you already have delivery leadership and need specific engineering skills. Your team manages priorities and day-to-day work.
A good fit when the deliverable can be defined clearly. We agree on scope, assumptions, milestones, and a process for handling changes.
A focused starting engagement can help clarify an existing system or test how we work together. Scope and success criteria are agreed before it starts.
Choose a useful starting point
You can begin with a defined project, dedicated engineers, or a managed team. An assessment or pilot is optional when it resolves a real uncertainty.
For an existing system where the next step is unclear, agree what to review: architecture, code, tests, CI/CD, or the delivery workflow. The output can include prioritized findings, risks, and recommended next steps. Confirm access, review depth, deliverables, fees, and timing before starting.
Choose a specific feature, integration, automation, or migration slice. Define the deliverable, technical question, acceptance criteria, review cadence, and testing expectations. At the end, review the evidence together and decide whether to extend, change direction, or conclude with an agreed handover.
The next engagement is agreed separately. There is no automatic move from an assessment or pilot into a long-term team.
Discuss a starting pointResponsible Digital Catalyst, in practice
SPARK is Salt’s software delivery framework. It connects business priorities, reviewable work, release ownership, and ongoing improvement—with the depth adapted to your engagement.
Working with US companies
Choose who will lead delivery, then define the working arrangements. The operating model below separates your responsibilities from Salt’s; commercial terms are specific to your engagement.
| Responsibility | Dedicated engineers | Managed development team |
|---|---|---|
| Business priorities | Your product owner sets priorities and accepts business outcomes. | Your product owner sets priorities and accepts business outcomes. |
| Day-to-day delivery | Your team directs the engineer’s tasks, reviews, and delivery process. | Salt coordinates the agreed workstream and reports progress to your decision owner. |
| Technical leadership & QA | Your team supplies leadership and testing unless separately included. | The proposal identifies the leadership and testing included in Salt’s scope. |
| Changes and blockers | Your delivery lead manages prioritization and dependencies. | Salt raises delivery blockers and scope changes for your decision. |
Your proposal and agreement need to identify the legal contracting entity, scope, billing currency, payment schedule, and change process. US presence does not by itself determine the entity signing your contract.
Identify your time zone, essential live meetings, delivery contacts, and escalation owner. Record the overlap window in both US local time and India time, including how daylight-saving changes are handled. Full US-day or 24/7 coverage is not a default commitment.
Separate repository access from legal ownership. Specify who administers the repository and deployment accounts, what code and assets are delivered, any pre-existing or third-party components, and the applicable IP terms.
Define a review cadence, a shared view of work and blockers, and the person authorized to accept a deliverable. For each release, identify the acceptance criteria, known limitations, and unresolved issues.
List the handover deliverables: source access, setup and deployment instructions, environment requirements, outstanding issues, and a walkthrough. Identify the people receiving access and the system owner after delivery.
Distinguish defect correction from new features and ongoing operations. Specify the support period, coverage hours, severity definitions, response targets, and escalation route. An ongoing support arrangement must be included explicitly.
We agree on communication hours, access to your systems, source-code ownership, confidentiality, replacement arrangements, and support responsibilities. Exact terms belong in your proposal and contract.
Compare developers and managed teamsA good place to start
Share the challenge. We'll help you work out the next step.
