Frequently asked questions

Six: 01 Analysis, 02 Strategy, 03 Content Planning, 04 Production, 05 Optimisation, 06 Reporting. Analysis produces a digital asset inventory and a technical audit report; strategy produces the keyword and question map, the architecture decisions and the roadmap.

Production covers the design system, development, structured data and the multilingual structure. The deliverable and the acceptance criterion of every phase are written out item by item on the how we work page.

The first deliverable arrives at the end of the analysis phase, typically within the first two weeks of the contract: a digital asset inventory and a technical audit report. It contains no design and no code, only the measured state of what exists and a prioritised list of findings.

If you expect something visual, the first design system draft arrives at the end of the strategy phase. To see how we report before signing, you can request the free digital asset audit: a narrower report built with the same measurement approach.

It depends on scope, and the duration is written into the contract alongside the scope. A single-language corporate website typically goes live in eight to twelve weeks; multilingual and multi-location structures take longer.

The variable that moves the launch date most is not the agency side but content and approval speed: when copy, images and technical documents arrive late, the launch date moves with them. We write that dependency into the schedule from the first day.

If you have an in-house team, the split is written as a RACI table: who does the work, who approves it and who is informed is set out in an annex to the contract.

In companies that have their own developers we usually take architecture, structured data, the performance budget and the visibility side, while the in-house team runs development. Acceptance criteria are defined together and measured by us. The detail sits on the digital transformation consulting page.

Each phase carries a defined number of revisions and that number is written into the contract. Changes inside the agreed scope carry no extra cost.

Requests that widen the scope, such as a new page type, a new language or a new integration, are priced in a separate scope note and their effect on the schedule is confirmed in writing. We do not grow scope on a verbal approval; that is where end-of-project surprises come from.

No. What sets the price of corporate work is not the name of the service but its scope: the number of page types, languages, locations and integrations, and the state of what already exists.

A figure quoted before the scope is known misleads either you or us. Instead, after the discovery call we issue one written proposal carrying the deliverable list, the acceptance criteria and the schedule.

We work at corporate scale and on a project basis. We state our entry budget threshold openly in the first minutes of the discovery call, before any proposal is prepared. We do not publish it on the site, because a single figure is misleading across scopes that differ this widely.

If your budget is below the threshold we say so in that first call and refer the request to smaller studios at no charge. Who we work with is set out on the why Baki Bilisim page.

Yes. All eleven services can be bought individually; there is no mandatory bundle. Projects consisting only of a Core Web Vitals fix, only a structured data implementation or only a brand identity are within our scope.

The contract lists the deliverables and acceptance criteria of the services you actually bought, and nothing binds you to a service you did not buy.

Fixed price for project work. Because the deliverable list and the acceptance criteria are written into the contract, the estimation risk stays with us and you see a single number.

For ongoing visibility, maintenance and reporting work we charge a fixed monthly fee, and the scope of that month is written at the start of the month. We do not bill hourly, because in a model measured in hours the buyer cannot read from the contract what they are buying.

Maintenance covers keeping what we launched working and measurable: security and dependency updates, performance budget checks, structured data regression checks, broken link and indexing monitoring, and small content changes.

It is priced as a fixed monthly fee and its scope is itemised in the contract. Maintenance is not compulsory; because the source code is yours, another team can run it.

The client owns the source code. Once delivery and payment are complete, repository access, build and deployment documentation and environment variables are transferred into the client's name.

You can host the code on your own server, continue development with another team, or stop working with us. We do not use a licence model that rents you the right to use your own site and manufactures dependency on the agency.

The client owns it as well: source design files, the design token file, vector versions of the logo and identity assets, and the usage guide are all handed over.

The single exception is third-party licensed assets, a commercial typeface for example. The licence holder and the renewal terms for those assets are stated separately in the handover document; we do not leave a surprise licence debt behind us. The delivery list is on the brand identity page.

An SLA is the service level commitment written into the contract. Ours has three thresholds: first response time for requests received on a business day, time to begin work on a critical fault that stops a live site, and completion time for planned work.

The figures behind those thresholds are set per scope in the contract and issued in writing with the proposal. Pre-contract general enquiries sent through the contact page are answered within two business days.

The source code repository and build documentation, design files and the token set, content sources, structured data schemas, measurement setups and report history, and domain and hosting access.

The handover period is written into the contract and a transfer meeting is held during it. You do not need to give a reason to leave and there is no exit penalty.

We are a small, focused team and we do not always run the entire scope in-house. On specific work, heavy content translation or a specialised integration for example, we may engage a subcontractor.

When we do, we tell you in advance which part is going outside, confidentiality and data processing obligations are passed through to the subcontractor unchanged, and your counterparty does not change: responsibility stays with us.

The answer depends on who updates the content and how often. If the page structure rarely changes and performance is the priority, a static or headless build means less maintenance and a lower load time. If a marketing team ships pages several times a week, a build with an admin panel is more realistic.

Set up correctly, both can clear the Core Web Vitals thresholds. What is wrong is making the decision first and looking for the reasoning afterwards.

Yes. Content, media, URL structure and search visibility can all be migrated. Three things decide whether it goes well: mapping old URLs to new addresses with 301 redirects, rebuilding structured data, and monitoring indexing after the move.

When those three are skipped, the traffic loss that follows comes from the incomplete redirect map rather than from the migration itself. The migration plan is shared in writing before go-live.

On the web we start from standard HTML, CSS and framework-free JavaScript, adding a static site generator or headless content management when the requirement calls for it. In commerce, the choice between an off-the-shelf platform and custom development is set by scope.

On mobile, native and cross-platform options are compared against device API needs, release frequency and team structure; the comparison table is on the mobile app development page. The reasoning behind the choice is delivered in writing in every case.

Domain and hosting accounts are opened in the client's name; billing and administrative access stay with you. The only thing we need is deployment permission, and you can withdraw it at any moment.

Registering the domain in the agency's name is common practice, but it turns into a bargaining chip the day you leave, so we do not do it. The same rule applies to app store accounts and analytics properties.

Yes, and that is the intended state. At handover we run content management training and leave a written administration guide. Your content team does not need technical support to add a page, update copy and images, or open a new language version.

Work with a lasting effect, such as structured data, the performance budget and template changes, is better kept inside maintenance; there, one mistake propagates across an entire page type.

AEO, Answer Engine Optimization, is the work of making a page directly quotable in search engine answer boxes and in AI assistants. Its method is question-form headings, a direct answer immediately under the heading, passages that make sense on their own, and FAQPage and HowTo schema.

Its measure is not ranking but being shown as the source of the answer. The full explanation is in the what is AEO guide; the service scope is on the AEO service page.

GEO, Generative Engine Optimization, is the work of getting generative engines such as ChatGPT, Claude, Perplexity, Gemini and Google AI Overviews to recognise a brand correctly and cite it as a source. Its scope is AI crawler access policy, llms.txt, entity clarity, the sameAs network and consistent identity signals.

It is a different channel from backlink authority: what decides the outcome here is machine readability. The detail is in the what is GEO guide.

SEO targets appearing high in the list of search results; its measures are ranking, clicks and indexing. AEO targets being the source when the user takes the answer without ever looking at the list. GEO targets the brand being named correctly when a language model composes the answer.

The technical foundation is shared across all three; the divergence is in content structure and schema. That is why splitting the three across separate agencies produces contradictory decisions on the same page.

No. Ranking depends on the changing judgement of a third-party system and nobody can commit to it. What we commit to is what can be measured: technical acceptance criteria, structured data validity, page speed thresholds, the content publishing calendar and the reporting rhythm.

When you see a proposal that guarantees rankings, ask in writing which metric it commits to and at which threshold. The full list of what we do not commit to is on the how we work page.

The decision is yours and we explain both outcomes neutrally. Allow them and your content can be used as a source in generative answers, which can raise brand visibility. Block them and your content stays out of those answers, but also out of model training.

For most companies publishing corporate content the visibility side outweighs. On this site GPTBot, ClaudeBot, PerplexityBot and their peers are deliberately allowed; you can verify that decision in our robots.txt file.

On the technical side: LCP, INP, CLS, the Lighthouse Performance, Accessibility, Best Practices and SEO scores, structured data error count, page weight and third-party request count.

On the visibility side: indexed URL count, coverage errors, query-to-page matching, click share and brand citation sampling across a fixed question set. Which of these become contractual acceptance criteria is written separately; the terms themselves are defined in the glossary.

For ongoing work our standard is a written monthly report and a quarterly governance meeting. For project work the report is issued at delivery: the measurement record, the status of each acceptance criterion and any open items.

A report is not a collection of screenshots; every line carries the measured value, the measurement tool, the measurement date and the difference against the previous measurement.

Every tool we use is publicly available and you can repeat the measurement yourself: PageSpeed Insights for Lighthouse scores and field data, the Rich Results Test for structured data, Search Console for indexing and query data, WAVE or axe for accessibility.

Because our reports name the tool and the measurement date, you can re-run the same measurement under the same conditions. The step-by-step method is on the proof page.

Because the most verifiable proof we can offer is our own measurement. This site's Lighthouse scores, Core Web Vitals values, page weight, structured data validity and accessibility results are published on the proof page together with the measurement tool and the measurement date.

It would be inconsistent for an agency to commit to a threshold on your site that it cannot meet on its own.

We do not yet have a published corporate case study and we do not present something we do not have as if we did. For trust we offer three verifiable footholds: our own site's scores, which independent tools can re-measure; contract terms written out on the site in advance; and a free digital asset audit.

The audit creates no obligation to work with us, so you decide by looking at a concrete output. The full reasoning is on the why Baki Bilisim page.

Yes, remotely. Our office is in İzmit, Kocaeli, so on-site meetings are practical inside Turkey. For organisations based abroad the working method is a written scope, a shared repository, scheduled video reviews and written reports, which are the same artefacts we produce for Turkish clients.

A large share of our English-language work also runs in the other direction: Turkish manufacturers and exporters whose buyers sit abroad. That case is covered on the export industry solutions page.

We write and deliver in Turkish and English. Additional languages are treated as an architecture problem rather than a translation problem: hreflang mapping, per-language URL structure, per-language structured data and locale-specific metadata are our scope.

The translation itself is produced by a specialist translator or by your own local team and we integrate it. We do not publish machine-translated pages without human review, because a page that reads wrong is quoted wrong.

When the counterparty is not Turkish the contract is drafted in English, and the governing law, jurisdiction, currency, payment schedule and delivery milestones are named in it before signature. Invoicing is issued from Turkey by Baki Bilişim.

We are not tax advisers: how withholding, VAT or reverse charge applies in your country should be confirmed by your own accountant before signature. We supply whatever documentation your finance team needs for that check.

Turkey observes UTC+3 all year and does not change clocks for daylight saving, so the working day overlaps continental Europe by most of its length and the Gulf almost entirely. Scheduled video reviews are set inside that overlap.

Meetings are not the primary channel. Decisions, scope changes and acceptance are recorded in writing so that a reader in another time zone can act without waiting for a call.