Project FAQs

We work on public-facing websites and the digital tools a business uses internally. Alongside design and development, a project may involve data connections, mobile use, or search and advertising work after launch. These areas are not automatically bundled together; we discuss whether each is needed and where its delivery scope ends. The services page helps you identify which area matches your requirements.

We provide project-based services with scope defined around your business requirements, rather than selling fixed software packages. A feature name alone does not establish what a project includes. Explain how you intend to use the functionality in a free quote request, and we will assess the relevant service against your current needs.

Yes. Our remote development model for businesses across Turkey also supports projects for companies in the UK, US, Ireland and EU, as well as businesses in the DACH region, Gulf and Arab markets, Russia and the CIS, and French-speaking markets. This describes where we can work, not local offices or completed client projects in every country. We hold the first meeting in English or Turkish and agree on meeting windows around your time zone. Acceptance and technical handover are explained in our software outsourcing guide.

Labels such as business website or stock management software do not explain the work in enough detail. Publishing ready-made content takes different effort from organizing text and data from the ground up. User roles, external systems, migration, and acceptance checks also affect the workload. To assess the price, review the deliverables alongside the work your business will handle. Comparing costs from a project name alone is not reliable.

Content is not independent filler added after screens are complete. Long service names, product images, and different amounts of text affect page layouts. We therefore plan who will supply the content and when it will be approved. If text is not ready, that should be noted during design review. The target launch date depends on content and business approvals as well as development tasks.

Core content and functions should remain consistent, but their presentation may differ. On a phone, menu usability, touch targets, text readability, and form steps are especially important. A screen that looks right on desktop has not necessarily passed those checks. We assess real content and core user tasks. Speed measurements also depend on the device, network conditions, and page content; a single measurement does not represent every use case.

Content you need to manage day to day is included in the initial scope. Editing text, images, or product records is not the same permission as changing page designs or business rules. Knowing who will use the dashboard and how often they will make updates helps us choose the right screens. It is useful to perform a sample update during delivery review: this shows not just that the dashboard exists, but that it suits your work.

No. Search results can be affected when content and URLs change alongside the design. Existing pages, their new equivalents, and redirect requirements should be assessed before migration. Keeping a URL alone does not address a change in content meaning. Crawl and indexing data need to be monitored after launch. The aim is a controlled transition; it would not be right to promise that a particular ranking will stay the same or improve.

We first identify the business rule your existing tools cannot support. If training, configuration, or a simple data connection can close the gap, rewriting the whole system may be unnecessary. Requirements such as multiple people working on the same task with different permissions, or keeping a record history, need separate assessment. A custom software decision should be based on measurable limits of your current approach, rather than a desire for something new.

Dividing the work into phases does not mean developing half of every screen. At the end of a phase, a defined user task should work from start to finish. We consider in advance which data the first phase creates and what it passes to later phases. Acceptance examples are defined for each delivery. Your business can then assess a working part of the system without unfinished work being presented as complete. The schedule reflects phase dependencies and external system conditions.

Source code, the database, and project access are handed over; rights to use the developed work are explained in the contract. For the handover to be useful, setup requirements and external service dependencies also need to be understood. Ownership of business accounts is separate from third-party license terms. This information helps the next team understand the system; sending a file archive alone is not the whole technical handover.

We confirm feasibility by reviewing the provider’s data-sharing method, access permissions, and the fields to transfer. An API may support some operations but not every one you need. Account type, permissions, or provider restrictions can affect scope. When assessing integration solutions, we distinguish changes to an existing system from connections to it. The project plan also defines who will obtain the necessary access.

A total count is hard to interpret without knowing the search queries and landing pages behind the visits. Unrelated traffic may rise while relevant inquiries stay unchanged. Content purpose, search intent, and the contact step need to be assessed together. Measurement tools also collect data differently, so their figures may not match exactly. A report should explain how the work relates to reaching relevant users, rather than present one impressive number.

It is meaningful to define work we can control: pages to review, technical fixes to make, and content topics to assess, for example. Positions in Google results depend on competitors, the query, user context, and decisions made by search systems. The scope of SEO services is described through the work to be done. Presenting a particular ranking as a purchased deliverable or promising a definite result by a set date would not be honest.

The advertising budget spent in a Google Ads account is separate from the work involved in managing it. Account ownership, payment methods, goals, and reporting boundaries should be clear from the start. Running an ad does not automatically generate sales. The landing page, how inquiries are handled, and measurement quality are also part of the assessment; responsibility for each needs to be understood.

Design feedback and acceptance of a defined scope serve different purposes. We record the approved deliverable, date, and reviewer in writing. Work is done under a contract with invoices, with payment stages and acceptance responsibilities defined. If a new request arises, this record helps distinguish incomplete implementation of an earlier requirement from an expanded scope. An idea raised in a meeting becomes an implementation instruction only when it is agreed as part of the work.

One year of technical support after delivery covers correcting defects in the developed work and answering questions about its use. When an issue arises, we first compare the agreed behavior with the observed behavior. A request for a new screen, business rule, or external system connection is new scope. Terms for ongoing maintenance and third-party changes need separate discussion; support does not mean unlimited feature development.

We recommend opening business accounts in your business’s name with contact details you can access. Granting technical access does not require a change of account ownership. If an existing account may be used, deployment requirements and available access need assessment. Renewal dates, payment responsibilities, and recovery details also need to be known. This arrangement makes it easier to move to another server or team later; hosting services may be separate from project development.