Thirteen commitments every Ettikar client can hold us to, from the first discovery call through handover and beyond.
What You Can Expect.
This page describes Ettikar's general delivery approach and operating practices. Exact deliverables, responsibilities, timelines, warranty terms and support commitments are defined in each project's signed proposal, statement of work or service agreement. If anything here conflicts with the signed agreement, the signed agreement governs.
In short
- 01
Scope is agreed in writing before work starts; changes are priced and agreed first.
- 02
Work moves in milestones you review and sign off.
- 03
Ownership and handover follow your signed agreement.
- 04
Warranty and support are defined in each project agreement.
01Discovery & Scoping
Every project starts with a discovery session: a structured conversation about your business goals, technical constraints and what success looks like. Before any code is written, we produce a scoping document that sets out what is being built, the technology approach, the delivery timeline and the project phases.
This document becomes the reference point for the contract. Changes to scope after sign-off go through a clear change-request process: revised cost and timeline estimates are provided and agreed before any additional work begins. Nothing proceeds without your approval.
Core Practice02Project Governance & Milestones
Projects are divided into milestones: distinct, reviewable stages with defined deliverables. Each milestone requires your sign-off before the next begins, and progress is shared at agreed intervals throughout.
There is no hidden development phase. You can see what is being built, what has been completed and what comes next. If a milestone is at risk of slipping, we tell you before it slips.
Core Practice03Technical Architecture
Technology decisions are based on your project's requirements: expected traffic, integration needs, long-term maintenance and your team's technical capacity. We do not apply a single stack to every project.
Where a choice trades short-term build speed for long-term maintenance cost, we explain that before the decision is made. Major architectural decisions are documented before implementation begins, so you always know why a technical choice was made.
Core Practice04Code Quality & Review
Code follows consistent naming conventions, is structured for readability and is written so that an external developer can maintain it. We write clear, well-organised code rather than code that only its author can follow.
Third-party libraries are used deliberately: dependencies are kept to what is necessary and documented. Code is reviewed internally before delivery. The goal is a codebase that a developer who was not on the project can pick up without difficulty.
Core Practice05QA & Device Testing
Every deliverable is tested on the devices and browsers agreed in the project scope. Standard testing covers current versions of Chrome, Safari and Firefox, iOS Safari and Android Chrome.
Additional coverage, such as older browser versions, specific screen sizes or non-standard environments, is defined in the scoping document. Edge cases and error states are tested, not just the expected path, and QA is carried out before each milestone sign-off, not only at launch.
Core Practice06Performance
We optimise production websites for performance and treat Core Web Vitals (LCP, CLS and INP) as delivery criteria. Specific targets depend on the project's scope, approved media, hosting environment, third-party integrations and features. Benchmarks are agreed during scoping and reflect what is achievable within the approved design and feature set.
Standard practices include image optimisation, code splitting, lazy loading, server response monitoring and a performance audit before launch. Where a design decision or approved feature has a measurable performance cost, we explain that trade-off before implementing it.
Core Practice07Security Practices
Standard security practices on every project: HTTPS on all environments, secrets stored as environment variables (never in source code), input checks on all user-facing forms, database access controlled through row-level security or an equivalent, and a dependency audit before production launch.
These development checks reduce risk. They are not an independent penetration test or a formal compliance assessment, and no system can be guaranteed completely secure.
Core Practice08Source-Code Ownership
Ownership of the original work Ettikar develops for your project transfers to you according to the terms of the signed agreement and once the applicable payments are complete. This is written into every contract.
Third-party libraries, open-source components, fonts, licensed stock media, APIs and other external assets remain governed by their original licences; we cannot transfer ownership of intellectual property we do not own. As part of handover, we document the key third-party dependencies so your team understands what those licences cover. Your own brand assets, content and IP contributed to the project remain yours throughout.
Core Practice09IP & Asset Handover
Handover includes access to the source-code repository, environment configuration documentation (production secrets are transferred separately and securely), editable design source files, and access details for third-party accounts created specifically for the project. The exact handover package is defined in the signed scope.
Third-party libraries, open-source frameworks and external services included in the project remain subject to their own licence terms. We identify and document significant dependencies at handover so you understand what your team inherits and what obligations those licences may carry.
Core Practice10Documentation
Documentation is proportional to the project and defined in the signed scope. It may include setup instructions, deployment procedures, an environment-variable reference (without secret values), admin panel guidance, architecture notes, API integration summaries, a handover checklist and post-launch support instructions.
The documentation package is not identical for every project: a single-page admin guide and a multi-section technical reference are both appropriate, depending on the scope. Where a system is complex, we provide a recorded walkthrough alongside the written documentation.
Core Practice11Warranty & Support
Warranty coverage and duration are defined in your project agreement. Within those terms, we address defects where the delivered work does not function as agreed.
Unless your project agreement states otherwise, the warranty does not cover new features, design changes, new integrations, content updates, third-party service failures, hosting-provider issues, problems introduced by client changes after delivery, or any work outside the signed scope. After the warranty period, ongoing support and maintenance are available under a separate support agreement with defined response times and scope.
Warranty per Project Agreement · Extended Support Available12Confidentiality & NDA
Client information shared during a project, such as business logic, unreleased products, customer data, financial information or anything a reasonable person would consider sensitive, is treated with discretion by default, whether or not a formal agreement is in place.
A Non-Disclosure Agreement is available on request before discovery begins. We do not share confidential client or project information with external parties without written consent, except where disclosure is required by law or information is processed by the hosting, email and infrastructure providers needed to carry out the agreed work, as described in our Privacy Policy.
Available by Agreement13No-Lock-In Policy
You are not locked in to Ettikar after handover. We do not build systems that only we can maintain, and we do not use proprietary tools that create a forced vendor relationship, unless a tool is the right choice for your project, in which case the dependency is explained and agreed upfront.
After handover, you can continue working with us, move to another team or maintain the system internally. Clear documentation and readable code make all three options possible. This commitment applies to every client from the first conversation.
Core Practice