GnosisCraft
Engagement rules
Good work depends on clear expectations and timely collaboration. These principles apply to every engagement, while project-specific terms are documented in the proposal and statement of work.
1. Every engagement begins with a written scope
Before work begins, we agree on the problem to solve, expected outcomes, deliverables, timeline, responsibilities, and commercial terms. Work starts once the statement of work is approved, the required access is available, and the initial payment has been received.
2. Discovery is a paid engagement
Assimilation and discovery require technical analysis, stakeholder time, and professional judgment. This phase is billed independently and produces a detailed assessment report. Completing discovery does not require the client to continue into development.
3. The roadmap guides development
The roadmap defines the initial priorities, milestones, dependencies, and sprint objectives. It is a working plan rather than a guarantee that every early assumption will remain unchanged. New technical findings, user feedback, business decisions, and external dependencies may require the roadmap to be updated.
4. Work is delivered in focused sprints
Development is organized into short sprints with defined objectives and deliverables. At the end of each sprint, we review completed work, discuss findings and blockers, and agree on the next priority. Clients receive regular visibility into progress, risks, and decisions.
5. The client provides access and context
The client is responsible for providing timely access to stakeholders, source code, documentation, systems, credentials, data, vendors, and other resources required for the engagement. Access should follow appropriate security controls and provide only the permissions necessary for the work.
6. The client appoints a decision maker
Each engagement needs one person who can clarify priorities, approve deliverables, resolve conflicting requirements, and make business decisions. Feedback and approvals should be consolidated through this person so the project can move forward efficiently.
7. Feedback is part of the schedule
The client agrees to review deliverables and provide consolidated feedback within the response period defined in the statement of work. Delayed decisions, missing access, or unavailable stakeholders may affect sprint objectives and delivery dates.
8. Changes are evaluated before they are added
Requests outside the agreed scope are documented and assessed for their effect on cost, schedule, architecture, and existing commitments. Small adjustments may be included within a sprint when capacity allows. Larger changes require an updated roadmap, a change order, or a separate statement of work.
9. Estimates are based on current information
Software estimates depend on the information available when they are prepared. Legacy systems, undocumented behavior, third-party services, data quality, security requirements, and newly discovered dependencies can affect the effort required. When an estimate needs to change, we explain the reason and present the available options before proceeding.
10. Technical concerns are communicated openly
We communicate material risks, blockers, tradeoffs, and limitations as soon as they become known. When several solutions are possible, we explain their practical consequences and recommend the option that best supports the project’s objectives.
11. Collaborators are introduced transparently
Every engagement remains directly led and supervised by us. When additional expertise or capacity is needed, trusted collaborators may be proposed for the project. The client is informed about who will participate, what they will be responsible for, and how their work will be coordinated. Collaborators are subject to the same confidentiality and security obligations as the rest of the engagement.
12. Security and confidentiality are shared responsibilities
Client information is used only for the agreed work and handled according to the security requirements established for the engagement. Credentials should be shared through approved secure methods and revoked when they are no longer required. Confidential client data will not be submitted to external AI services without prior authorization.
13. Third-party services require client approval
Projects may depend on cloud platforms, software licenses, APIs, data providers, or other third-party services. We explain the purpose and expected cost of significant dependencies before introducing them. The client is responsible for fees charged directly by approved third-party providers.
14. Quality is built into development
Code review, appropriate testing, security considerations, and documentation are included throughout development. The final validation phase focuses on complete workflows, release readiness, remaining defects, deployment, and operational support.
15. Deliverables are accepted against agreed criteria
Deliverables are reviewed using the requirements and acceptance criteria defined for the relevant sprint or milestone. A deliverable is considered accepted after written approval or after the review period has passed without a documented material issue.
16. Ownership transfers after payment
Once all related invoices have been paid, the client owns the custom deliverables created specifically for the engagement, unless the statement of work specifies otherwise. Pre-existing tools, reusable components, open-source software, and third-party materials remain subject to their existing ownership and licenses.
17. Payment terms are defined before work begins
Fees, invoicing cadence, expenses, taxes, and payment deadlines are stated in the proposal. Discovery may be priced as a fixed engagement, while development may be billed per sprint, by milestone, or on a time-and-materials basis. Overdue invoices may result in work being paused until the account is brought current.
18. Either party may pause or end the engagement
Either party may end the engagement according to the notice period in the statement of work. The client remains responsible for work completed, approved expenses, and committed resources through the effective end date. We provide completed deliverables and reasonable transition documentation once outstanding invoices have been paid.
19. Production support has a defined boundary
The development engagement includes the validation and support period described in the roadmap. Ongoing monitoring, maintenance, incident response, feature development, and service-level commitments require a separate support agreement or continuing engagement.
20. Respectful collaboration is required
We work with honesty, professionalism, and respect, and expect the same from clients and collaborators. Harassment, discrimination, abusive conduct, unlawful requests, or deliberate misuse of technology are grounds for ending an engagement.