Questions, answered plainly.

You send a short brief through the contact form. We reply with questions or suggest a call and hold a discovery conversation about your goals, users, current situation and constraints. After that you receive a written proposal; work starts only after you approve it.

Your goals, the tools or website you use today, examples you like and any known constraints. Content and brand assets are needed later, during design.

Six: discovery, strategy, design, development, testing & quality, and launch & support. The Process page shows what you provide and what you receive at each step.

Yes. Key screens are designed for desktop and mobile and approved by you before development; a clickable prototype is prepared where it is useful.

Work is delivered in milestones with working previews on a staging link. You have a direct contact, regular updates in plain language and written confirmation of any scope change.

It depends on scope. A focused website and a multi-module platform have very different timelines, so the proposal contains a milestone plan for your specific project.

Yes. We work in Turkish and English and communicate remotely; meeting times and time zones are agreed at the start.

By scope, complexity, integrations, content readiness and timeline. You receive a written estimate after discovery.

Two projects with the same name can differ greatly in scope. Publishing a fixed number would either mislead you or force a template solution, so the cost is set per project in the written proposal.

Payment terms and milestones are set per project in the contract.

Scope changes are confirmed in writing before they are built, together with their effect on timeline and cost.

Yes. Discovery is there to understand your needs; there is no commitment until you approve a written proposal.

Ownership and handover are defined in the contract. Our default approach is that what we build for you belongs to you.

Source code delivery is defined in the contract; handover with documentation is part of the launch step.

Modern, widely supported technologies chosen per project. The Technologies page lists the tools we work with and why.

That is the goal of typed, reviewed code and handover documentation: the product should not depend on a single person or company to be maintained.

Usually yes, if the service offers a documented API and you have account access. We check documentation and limits before confirming scope.

Yes. Maintenance can cover updates, security patches, fixes and improvements. Scope and duration are set per project in the contract.

Launch includes deployment, monitoring of the go-live and the support period agreed in the contract.

Yes. We first review the existing code, infrastructure and data, then recommend improving, refactoring or rebuilding parts of it — whichever is most sensible.

We need access to the domain and hosting to go live. Who holds the accounts and who pays for them is set per project in the contract.

It is used to respond to your request, stored in a database and viewed only in a password-protected admin panel. Details are in the KVKK Information Notice and the Privacy Policy.

No. The site sets no cookies for visitors. It uses cookieless, first-party visit statistics that store no IP address; you can turn them off under Cookie preferences, and browsers sending Do-Not-Track or GPC are not measured.

Yes: privacy notices, consent flows where they are needed, data minimisation and access controls can be part of the scope. The legal assessment itself should be done by your legal advisor.

Usually you are the data controller for your product. Roles and responsibilities, including any data processing agreement, are set per project in the contract.