How we begin an engagement
A clear path from the first problem statement to an assigned project team
Our onboarding process is designed to move quickly while giving the development team enough information to assess the requirement. The opening milestones establish the problem, bring the right specialists into the conversation and prepare the project for contracting.
| Stage | Timing or trigger | What happens |
|---|---|---|
| Client questionnaire | At the start | The client describes the problem, current systems, desired outcome and key constraints |
| Development meeting | Within 24 hours of a complete submission | The development team discusses the requirement and the main technical questions |
| Dedicated team assignment | Within 3 days after the initial technical meeting | A project team is assigned around the identified scope and required skills |
| Financial terms and contract | After scope alignment | The parties agree pricing, milestones, responsibilities, acceptance and any assurance arrangement |
| Work begins | After signing and agreed prerequisites | The team starts the approved plan with named owners and a delivery schedule |
What the initial questionnaire covers
The questionnaire gathers the business problem, intended users, target markets and the systems already in place. For digital asset projects it also covers assets, networks, custody arrangements, anticipated transfer values, expected volumes and authorization requirements.
The client can identify preferred providers, regulatory dependencies, target dates and available technical documentation. Sensitive operational information is handled through the agreed confidentiality process.
The first development meeting
The initial session tests the problem statement, clarifies missing information and identifies dependencies that could affect the solution. The outcome is a shared understanding of the work to be scoped and the specialists required for the next stage.
Mobilization conditions
The 24-hour and three-day timings are onboarding targets based on complete information and participant availability. The delivery schedule itself is confirmed after scope, dependencies and contracting are agreed. Client-side access, provider onboarding and required approvals are identified before implementation begins.
Engineering delivery and quality
Progress through defined stages with evidence at each decision point
After mobilization, XCusty organizes delivery around an agreed plan and clear acceptance criteria. The plan can be adapted to a new platform, an integration project or an improvement to an existing system.
Discovery and solution design
The team documents requirements, asset flows, user roles and external dependencies. Architecture decisions identify the components to build, integrate or configure. The client reviews the proposed design before implementation commits to assumptions that materially affect cost or operations.
Iterative implementation
Development is organized into reviewable increments. Regular demonstrations allow stakeholders to assess working functionality and resolve questions early. Changes are evaluated for their effect on scope, dependencies, security and delivery dates before they are accepted into the plan.
Testing and integration validation
Testing follows the risk and function of the component. It can cover contract behavior, application functions, permissions, interface compatibility and transaction reconciliation. For critical transfers, tests include duplicate requests, delayed responses, failed approvals and recovery from agreed failure conditions.
Performance testing uses the client's expected workload and agreed targets. Results are tied to the tested configuration; they do not automatically establish capacity for every network or future deployment.
Readiness and acceptance
Before production release, the parties review acceptance results, unresolved defects, security findings and operational dependencies. User acceptance testing confirms whether the delivered functions meet the agreed business requirements. A release decision identifies any accepted limitations and the people authorized to approve launch.
Deployment and handover
The release plan defines deployment steps, monitoring, rollback or containment options and the transition to support. Handover provides the agreed source materials, architecture records, configuration guidance and operating procedures.
Quality is demonstrated through these artifacts and decisions. The client can see what was delivered, how it was assessed and which responsibilities continue after launch.
Dedicated teams and senior workshops
Give the project direct access to the people responsible for its architecture and delivery
XCusty's team of more than 39 employees supports a dedicated-team approach to client engagements. Team composition is matched to the scope and can evolve as the project moves from architecture to implementation and operation.
A typical project structure
| Role | Primary responsibility |
|---|---|
| Client sponsor and product owner | Business priorities, decisions and acceptance |
| XCusty delivery lead | Planning, coordination, progress reporting and escalation |
| Senior solution engineer | Architecture, integration decisions and technical alignment |
| Technical lead | Implementation direction, code quality and release readiness |
| Blockchain and software engineers | Contracts, services, applications and integrations |
| Security and quality specialists | Defined review scope, testing and issue verification |
| Operations and support specialists | Deployment, monitoring, handover and ongoing service |
The client and XCusty confirm the actual roles, named contacts and time commitments for the engagement. External specialists are included when the agreed scope requires them.
In person workshops
Senior solution engineers and technical leaders are available for in-person workshops. These sessions are useful when multiple stakeholders need to align on architecture, custody responsibilities or a complex transfer workflow.
A workshop can examine the current system, map asset movements, define approval requirements and compare implementation options. The discussion connects commercial priorities with technical decisions, so the client can understand the implications before development begins.
Practical workshop outputs
Expected outputs can include a problem map, architecture outline, decision log, dependency list and prioritized next steps. The participants leave with named owners for unresolved questions and a shared understanding of the next decision required.
Workshop location, participants and preparation materials are agreed in advance. Confidential technical information is shared only with the people who need it for the defined engagement.
Engagement models and delivery outputs
Match the commercial structure to the maturity and complexity of the work
XCusty offers several ways to engage, from a focused technical assessment to the development and support of a complete platform. The agreement defines scope, commercial terms, responsibilities and the outputs the client will receive.
| Engagement model | Appropriate use | Typical output |
|---|---|---|
| Advisory and discovery | Requirements or architecture need clarification | Assessment, architecture options and a delivery roadmap |
| Custom development | The product requires tailored functions and controls | Application, contracts, integrations and handover documentation |
| White label configuration | An available component fits the operating requirements | Branded, configured solution with agreed adaptations |
| Dedicated project team | A product needs an ongoing sequence of releases | Assigned capacity, delivery governance and iterative development |
| Integration engagement | Existing systems need to connect | Interfaces, adapters, testing and operational guidance |
| Support and maintenance | A production system needs continued care | Agreed support coverage, maintenance and improvement work |
Contract and commercial structure
The agreement records deliverables, milestone payments, acceptance criteria and the process for requesting changes. It also identifies third-party fees, infrastructure costs, provider access and any client responsibilities that affect delivery.
Source-code access, intellectual property, reuse of existing components and software licensing are addressed explicitly. The client should understand what is transferred, what is licensed and what remains dependent on an external service.
A practical handover package
Depending on the scope, handover can include architecture diagrams, source repositories, deployment configuration, API documentation, test records, contract addresses and operational procedures. Administrator training and technical knowledge transfer can be included where required.
Financial assurance as a separate workstream
When selected, the financial assurance structure is documented alongside the project agreement with its own parties, coverage and conditions. Its value and terms are evaluated directly; they are not implied by the delivery model or a standard software support commitment.
Support maintenance and operating visibility
Keep the platform understandable and maintainable after launch
XCusty provides continuing support and maintenance under an agreed service arrangement. The support model is aligned with the importance of the system, the client's internal capability and the responsibilities retained by external providers.
Maintenance scope
Work can include defect resolution, dependency updates, compatibility changes and improvements to agreed platform components. Contract updates, new network support and material product changes are assessed as separate changes when they alter the original scope or risk profile.
Maintenance planning accounts for provider changes and the effect of upgrades on connected systems. Critical changes are tested before production release, with communication to the relevant client contacts.
Incident management
The service agreement defines support channels, coverage hours, severity levels and response targets. A production incident is recorded with its affected services, business impact and responsible owners. Containment and recovery actions follow the permissions established for the platform.
Communication should distinguish what is known, what remains under investigation and the next planned update. After resolution, a review can identify the cause, corrective action and any change needed to reduce recurrence.
Operating indicators
| Indicator | What it helps the client understand |
|---|---|
| Processing success and exceptions | Whether instructions progress through the intended lifecycle |
| Confirmation and settlement time | How network and provider dependencies affect completion |
| Reconciliation differences | Where records require investigation or correction |
| API availability and response behavior | The reliability of the tested service interfaces |
| Open security and quality findings | Outstanding remediation and accepted limitations |
| Support volume and resolution | Recurring issues and maintenance priorities |
Targets, definitions and reporting frequency are agreed for the engagement. The indicators support decisions about capacity, reliability and future investment without substituting for the underlying records.
References and the next conversation
Evaluate the working relationship and define a practical first step
Clients can ask to speak with companies that have worked with XCusty. Where the relevant company agrees, we can facilitate a direct reference conversation about our performance and the experience of working with the team.
Making reference discussions useful
A reference is most useful when it relates to the requirement being evaluated. Prospective clients can describe whether they want to understand technical delivery, communication, change management or support. We then assess which available reference is most relevant and what information may be shared.
The reference company can discuss its own experience in its own words. Confidential project information, technical access and commercial terms remain subject to the permissions of the parties involved.
Preparing for an XCusty workshop
To begin, the client can provide a short description of the operational problem, the current platform and the intended outcome. For custody or transfer projects, useful information includes supported assets and networks, the parties that control funds, transfer frequency and the approval process.
An initial discussion can also identify the people who need to participate: business owners, treasury or finance, technology, security and relevant legal or compliance advisers. This helps ensure that the design addresses the actual decision-making structure.
A clear first decision
The first decision is the appropriate next step. That may be an architecture workshop, a scoped integration, a technical assessment or a full project proposal. Financial assurance requirements can be raised at this stage so that their feasibility and contractual structure are evaluated early.
Working with XCusty
We bring together specialist digital asset infrastructure and a wider product development capability. Our role is to help clients define the system they need, build it with clear responsibilities and support its operation through a structured working relationship.
Senior solution engineers and technical leaders are available to discuss the requirement and plan the first workshop through the client's XCusty point of contact.