The software engineering standards we follow

A shared, explicit statement of what must be true before work counts as finished.

How we apply it The same check runs before every change: template, YAML and service container lints, static analysis, the tests and a check of the live pages. If one of them fails, the work is not done.

Documentation lives in the repository as plain text and goes through the same review as code.

How we apply it Architecture decisions, module documents, release steps and work plans are kept in the repository as Markdown and updated in the same change as the code.

Every change is read by someone other than its author before it merges.

How we apply it Changes go through a written review checklist, and some are merged through a GitLab merge request. On work with a single developer the review is tool-assisted, not done by a second person.

Four values and twelve principles for iterative, collaborative delivery.

How we apply it We release work in small increments, measure the result on the live system and keep the owner's decisions in writing at every stage.

A framework that splits documentation into tutorials, how-to guides, reference and explanation.

How we apply it The reasons behind decisions, the module reference documents and the step-by-step release guides live in separate places; the documents are not labeled by type and there are no tutorials.

Twelve rules for portable services: configuration in the environment, build, release and run kept apart, development and production alike.

How we apply it Configuration is read from environment variables, the package is built once and released, and development, testing and production use the same PHP version. The one deliberate exception: logs go to files because of how the server works.

Short numbered documents with context, decision and consequences, kept next to the code.

How we apply it Decisions such as the stack, the fonts, the release pipeline, market-based localization and the language policy are kept in the repository as numbered decision records.

The core of an application talks to the outside world only through ports; adapters implement them for mail, HTTP and third-party services.

How we apply it We use ports, and adapters that implement them, for email, the CRM and bot verification; there is no test that checks the dependency rule yet.

Dependencies point inward toward the business rules; the framework and input and output stay at the edge.

How we apply it Inputs and results travel in immutable data objects, and the services that run the business logic do not know the HTTP request.

HTTP methods, status codes, content negotiation and headers such as Retry-After.

How we apply it The contact form answers each outcome with the right status code: 200, 303, 403, 422, 503 and 429 with Retry-After; we honor the Retry-After header of the remote service as well.

Remote calls get a timeout, failed calls are retried later with growing delays, and the work survives in a queue meanwhile.

How we apply it The CRM call has a five-second timeout; on a temporary error the submission is queued and retried by a scheduled job. Email and the CRM work independently of each other.

An authorization framework in which a server-side client exchanges its credentials for an access token.

How we apply it This site connects to the ONLINEKURUM API with client credentials, keeps the token for its lifetime and refreshes it once on a 401 response.

Stateless client-server interaction over cacheable resources; the model grades HTTP APIs by maturity level.

How we apply it The site is stateless, its GET pages can be cached and the form answers on a single resource with a separate status code per outcome.

Building software on a model of the business domain with a shared language, value objects and explicit boundaries.

How we apply it We name our classes after the business domain and model concepts such as the language as value objects; the site is one small context, so there are no separate boundaries.

MAJOR.MINOR.PATCH numbers whose parts mean an incompatible change, a new feature or a fix.

How we apply it We declare dependencies with semantic version constraints; the site itself carries no version tags.

declare(strict_types=1) turns silent type coercion into a TypeError.

How we apply it Every class file in the application and test code, except the framework's Kernel class, starts with strict types, and the review checklist checks it.

Analysis without running the code, with rule levels that set how strictly it is checked.

How we apply it PHPStan scans the application, test and configuration code at level 6; it runs before every change and in continuous integration.

The living formatting standard of PHP-FIG that replaced PSR-12 and that Symfony's coding standard builds on.

How we apply it We write code in this style: strict types first, four spaces through EditorConfig, Symfony conventions. There is no automated fixer yet, so the standard is applied but not enforced.

Maps a namespace prefix to a directory, so a class is found from its fully qualified name.

How we apply it Application and test classes are loaded through Composer with PSR-4.

The official guide that recommends thin controllers, services for logic, attributes for routing and environment variables for infrastructure.

How we apply it Controller actions stay under twenty lines, routes are defined with attributes and infrastructure settings come from environment variables.

Single responsibility, open-closed, Liskov substitution, interface segregation and dependency inversion.

How we apply it Services do one job and depend on interfaces for outside dependencies such as email, the CRM, bot verification and the language settings; no architecture test checks this.

A naming method that ties styles to one component through block, element and modifier names.

How we apply it Our components are named with BEM, and a test checks that every class used in a template is defined in a stylesheet.

A file that keeps the charset, the indentation and the line endings the same in every editor.

How we apply it The EditorConfig file in the repository sets UTF-8, LF line endings, four-space indentation and a final newline.

Basic rules for PHP files: one declaration per file, class and method naming, no side effects next to declarations.

How we apply it Application and test code is written to these rules; there is no automated checker.

A logging interface, so services depend on a shared interface rather than on a library.

How we apply it Services receive the PSR-3 interface for logging; contact records are kept in a separate channel.

A shared interface for dependency injection containers.

How we apply it Services are wired automatically through their constructors by the Symfony container.

Readable names, small functions, no duplication and comments that explain why rather than what.

How we apply it We use immutable services and data objects, intention-revealing names and class comments that record the reasons behind decisions; no tool measures this.

Many fast unit tests, fewer integration tests and very few end-to-end tests.

How we apply it The tests run in two suites, unit and integration; on top of them sits a single HTTP check against the live pages.

Automated tests with fixtures and assertions; application tests send requests through the real kernel.

How we apply it PHPUnit fails a test on a deprecation, a notice or a warning, and the integration tests render the pages through the real kernel in both markets.

Automated checks that keep an architectural or project rule true as the code changes.

How we apply it Guard tests cover the coverage of style classes, the copy rules, the translation parity of both markets, English URLs, the page cache and the content security policy; the guards for style classes, copy rules, translation parity and English URLs also prove that their own check can fail.

A small set of checks that the main function of a build works before anything else is tested.

How we apply it The same list of addresses is called locally and on the live site after every release; every page must carry a marker that only PHP produces.

Write a failing test, make it pass, then refactor.

How we apply it Every change ships with its tests, and every service and data object has a test; whether the test was written before the code is not recorded.

Describe behavior in business language and derive the tests from it.

How we apply it We write our tests with names that describe the behavior; we do not use Behat or Gherkin.

A method and tools for checking how a site conforms to WCAG.

How we apply it We measured the Lighthouse accessibility score and recorded the result (100); there is no automated accessibility test in continuous integration yet.

Every push is built and tested automatically against the shared branch.

How we apply it On every branch the continuous integration job runs the lints, the static analysis and the tests.

Software is always releasable; one package is built once and moves through an automated pipeline.

How we apply it The package is built once and that package goes live; the release scripts can be rehearsed end to end against a fake server.

A new release is prepared next to the live one, traffic moves with one link switch, and rollback is the switch back.

How we apply it Every release is prepared in its own folder and goes live with a single link switch; the last five releases are kept and a rollback is one step.

Commit subjects carry a type and a scope, so the history is readable by people and tools.

How we apply it Our commit subjects use types such as feat, fix, docs and test; no hook enforces it.

Behavior is switched on and off through configuration rather than through a release.

How we apply it The page cache, bot verification and the CRM connection are switched by environment variables; the cache first shipped switched off and was turned on after testing.

Environments are defined in versioned files and built by tools, not by hand.

How we apply it The development environment is defined in Docker files, the release pipeline in versioned configuration, and no file on the server is edited by hand; the first setup of the hosting account was done by hand.

A branching model in which features gather in a development branch and releases are kept on the main branch.

How we apply it Feature branches merge into the development branch and the development branch into the main branch; we follow a simplified form of the model, without release or hotfix branches and without version tags.

The desired state is declared in Git and applied automatically; Git is the only path to production.

How we apply it A push to the main branch is the only way to release, and the server configuration is versioned in the repository; no agent keeps the server in sync with Git continuously.

Running services with service level objectives, monitoring, incident response and blameless postmortems.

How we apply it We use a health check and a rollback path after every release and rotating logs with retention; there is no uptime monitoring and no service level objective defined.

A header that lists the allowed sources for scripts, styles and frames, which blocks injected inline code.

How we apply it The live policy has no unsafe-inline, we use no inline styles or event handlers, and a test guards the policy.

Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and frame-ancestors on every response.

How we apply it All of these headers are set on the live server and HTTP requests are permanently redirected to HTTPS; local development runs on HTTPS as well.

Short implementation guides on topics such as CSRF prevention, input validation, logging and secrets.

How we apply it The form uses stateless CSRF protection with an Origin check and a double-submit cookie; input is validated against an allowlist and cleaned of control characters, and email addresses are masked in the logs.

Request limits and bot traps protect forms from abuse.

How we apply it The contact form is limited to five submissions per IP address in fifteen minutes; it also has a hidden trap field and bot verification, and the order of the checks is written down in the class comment.

Every program and user runs with the smallest set of rights the task needs.

How we apply it Releases use a restricted key that belongs to continuous integration only, production secrets sit in a file only its owner can read, and only the entry point can be executed.

Secrets stay out of the repository, are scoped to the environment, and pushes are scanned for leaks.

How we apply it The configuration in the repository holds no secrets, production secrets live in protected continuous integration variables, and automated secret detection runs in the pipeline.

Data protection built into the design from the start: collect the minimum, protect by default.

How we apply it Public pages use no cookies and no sessions, analytics loads only after consent, and contact records are kept for a limited time with masked email addresses.

Türkiye's personal data law, including the duty to inform and the consent rules.

How we apply it The Turkish market publishes its information notice and the form asks for explicit consent; the legal review of the notice is pending.

The data protection regulation of the European Union: lawfulness, data minimization, transparency and the rights of data subjects.

How we apply it The English market publishes its own privacy notice structured after the GDPR, and a test checks that each market carries its own notice; the legal review is pending.

The ten most critical risk categories for web applications.

How we apply it We have controls against several categories: access restrictions, security headers, validation and automatic escaping, security logs. We are guided by the list; there is no category-by-category assessment document.

The 25 most dangerous software weakness types, ranked by CVE data.

How we apply it Against XSS we rely on the automatic escaping of the template engine, against CSRF on token protection; we are guided by the list and keep no weakness mapping.

Levels for build provenance and source integrity in the software supply chain.

How we apply it Packages are built on a hosted runner from a versioned pipeline, and every package records the commit it came from; we produce no provenance attestation and no level has been assessed.

Non-essential cookies are set only after a clear notice and consent.

How we apply it Analytics cookies load only after "Allow" is chosen; the consent banner follows the rule of each market and is guarded by tests.

DNS records that let receivers verify the sending domain.

How we apply it Form email is sent from our own domain with the visitor as the reply-to address; the DNS checklist is written down in the release documentation.

Success criteria for accessible content at levels A, AA and AAA.

How we apply it We build pages to these criteria: a skip link, the page language, visible focus and reduced motion support; no formal conformance audit has been done.

Roles, states and properties that expose the changing parts of an interface to assistive technology.

How we apply it Our templates use aria-labelledby, aria-describedby, aria-expanded, aria-controls, aria-live and role="status".

The LCP, INP and CLS thresholds and the audit tool that reports them.

How we apply it We recorded a Lighthouse measurement (home page: 97 on mobile, 100 on desktop); we preload fonts, defer scripts and serve only the icons in use.

Elements with meaning, such as main, nav, header, footer, section, article and dialog, instead of generic containers.

How we apply it The page skeleton and the components are built from semantic elements, and the dialogs of the contact form are native dialog elements.

Start from working HTML and add CSS and JavaScript as layers that may be absent.

How we apply it The contact form also submits without JavaScript and gets an answer that leads back to the page; a test guards it.

A fluid layout plus media queries, so one page fits every screen size.

How we apply it Pages are built with a fluid type scale and media queries, and we recorded one measurement on mobile and on desktop separately.

Declaring the language and the text direction of a page, so browsers, screen readers and search engines handle the text correctly.

How we apply it Every page carries the language and the direction of its market on the html element; a test checks that both markets have the same translation keys.

Telling search engines about each language version of a page and which one is the default.

How we apply it Every page lists its counterpart in both markets and the default, in the page head and in the sitemap, and reaches the same page even where the address differs per market.

Cache-Control directives let browsers and proxies reuse responses safely.

How we apply it Files with versioned names are cached for a year with immutable; the page cache is keyed by the language decision and purged on every release.

Patterns for accessible widgets such as disclosure, dialog and menu button.

How we apply it We use the disclosure pattern on the menu button and native dialog elements for the form's dialogs; keyboard behavior is not tested automatically.

A compressed font format for the web, served from the site's own origin.

How we apply it We serve the IBM Plex fonts as subsets from our own server; the reasons are written down in a decision record.

The syntax of tags such as tr and en-US, with two-letter region codes.

How we apply it The markets are defined with the tags tr and en and the locales tr_TR and en_US; the browser language is read by a resolver that tests exercise.

Locale data for dates, numbers and names, used by ICU and the PHP intl extension.

How we apply it The PHP intl extension and per-market locale data are in use; dates are written with fixed patterns rather than CLDR formatting.

One encoding for all text in files, pages and data.

How we apply it Pages, files and JSON output are UTF-8, and a test checks the rule of full Turkish characters.

Machine-readable dates and times with their offset, and named time zones such as Europe/Istanbul.

How we apply it Form submissions and the CRM queue write times in the ATOM format, and the time zone of each market is defined in its configuration.

A JSON format for linked data; the carrier of schema.org markup.

How we apply it Every page carries its structured data in one JSON-LD graph, and a PHP service, not a template, builds the graph.

A shared vocabulary for structured data about organizations, services and pages.

How we apply it We use the organization, address, contact point, website, service, software, person and page types, and tests check the graph of every page.

Tags that define how a page appears when it is shared.

How we apply it Every page carries Open Graph and Twitter tags, and each market has its own 1200x630 share image.

An XML list of addresses for crawlers that can name language versions as well.

How we apply it The sitemap is built from the routing table and the content catalog, lists the language versions of every address and is checked by a test.

robots.txt tells crawlers which paths they may fetch.

How we apply it robots.txt points to the sitemap, and the cache probe and the error pages carry the noindex signal.

The international number format: a plus sign, the country code and at most fifteen digits.

How we apply it We publish the company numbers in E.164 format in the structured data and in call links; the phone field of the form is validated by a loose pattern and not normalized.

Data interchange for APIs, and human-readable configuration and content.

How we apply it Form responses and queue files are JSON; the content, the translations and the pipeline are YAML and are linted on every change.