# Detartech - full content > English full-text companion of https://detartech.com/llms.txt: every service, success story and FAQ answer published on detartech.com. The same pages exist in Turkish, Russian and Arabic (see https://detartech.com/sitemap.xml). ## Services ### MVP Development URL: https://detartech.com/en/services/mvp-development MVP development for startups and new products from Istanbul: a written validation question, progress visible on a test environment, your code, written handover. Highlights: - A one-sentence validation question with the success threshold set in advance - A not-building list as explicit as the build list - Constant client contact with near real-time visibility through pre-prod - CI/CD from day one, infrastructure on your own accounts - The real user flow first, the investor demo second - A written technical assessment and handover document at production An MVP is not a cheaper version of your product. It is the smallest working product built to answer one question, and if that question is not written down, what comes out is not an MVP but an unfinished product. An unfinished product teaches you nothing. That is why we do not start with a feature list but with a single sentence: which assumption, if it turns out to be wrong, makes everything else pointless? Once that sentence exists, two lists follow, one of things to build and one of things not to build. The real work of this service is defending the second list. Writing the code is the most predictable part of the job. ##### How we define an MVP An MVP is not a prototype. A prototype answers an internal question, "does this technically work", and it lives under test conditions. An MVP goes outside, touches real users, and works fully within a narrow scope: people sign up, pay, and see the error screen. There is also the v1, a first release with the feature list closed up front and no hypothesis attached. A v1 is legitimate work, but its timeline, price and risk differ from an MVP, so we tell you in the first meeting which of the two your request is. There is work we decline as well: projects with no definition of success, requests shaped as "let us ship first and look later", and measurements nobody will use to make a decision. For the history of the idea, the different MVP types and where the practice stands today, see [our guide to what an MVP is](https://detartech.com/en/blog/mvp-development-guide-2026). ##### How we build an MVP The six headings below cover every decision made in an MVP project. The first three describe how the work is set up: cutting scope, designing the validation, and the delivery rhythm. The next two cover what happens after launch: how a demo differs from real usage, and what is done with technical debt in production. The sixth is the opposite of the others, the cases where an MVP is the wrong answer and we say so before any contract is signed. ###### Cutting scope: deciding what will not be built Cutting scope is not deleting features. It is tying every feature to one question: which assumption does this test? A feature with no answer is not thrown away, it goes on the post-MVP list handed to you at the end of the project. The clearest example is BiTalih, where teams needed to produce social media content and what they did not get was a design tool. Fixed templates were defined and users were given permission to update only the variable fields such as place, time and amount. That was a decision, not a gap: because design consistency held, content production dropped from hours to minutes. ###### Designing validation: which question, which measurement Three lines are written before any code. The assumption to be tested, the metric that will measure it, and the threshold that counts as a yes. If the threshold is not set in advance, any outcome can be narrated favourably afterwards, so the metric stays binary: it either cleared the bar or it did not. The same document records who the measurement runs on and how those users are reached, because an MVP with no traffic produces guesses rather than measurements. Event tracking ships with the first release, since instrumentation added later cannot recover the data from the early weeks. ###### Constant contact and pre-prod visibility We stay in constant contact with the client throughout the project; progress is shared on most days it is possible to share it. Early on, we set up a staging environment that closely mirrors the live system but is not yet open to real users; we call it pre-prod, and changes made there can usually be watched in near real time. The evidence of progress is not a screenshot but working software at a real address, and what makes that possible is a deployment pipeline set up from the very start. Lextum AI, Biletico, Anneekspres and World Summer Schools all had CI/CD automation running on Jenkins. Releasing has to stop being an event before that transparency can hold. ###### Investor demo versus real user testing An investor demo is built around a ten-minute narrative and follows the happy path. Real user testing needs the unhappy paths: empty states, invalid input, an abandoned payment, a weak connection, a small phone. Both come out of the same product, but the order matters: we build the real flow first, and the demo becomes a scripted route through it. When we took over Biletico, the platform had a foundation but the payment flow had been left half finished. When payment does not work, every other measurement loses its meaning, because the user leaves before reaching the purchase step. That is why payment took first priority, and payment, search, profile and ticket management were all made functional before the platform went live. ###### Moving from MVP to production and the technical debt decision Not every piece of technical debt gets repaid; what gets decided is the order. At the end of an MVP we usually share a written assessment separating what must change before growth from what can live as it is for a long time; that split follows the project and is not divided into the same fixed categories every time. The point is that the decision can be made commercially rather than technically. Lextum AI is the concrete example of what belongs on the production side: the system is built on a microservice architecture with asynchronous processing over RabbitMQ, and role-based access and a full audit trail are part of that same structure. High-traffic enterprise use is what makes those items non-negotiable. When the problem is load rather than demand, the work leaves MVP territory and moves to [backend scaling](https://detartech.com/en/services/backend-scaling). ###### When an MVP is the wrong answer There are four situations in which we do not recommend an MVP. First, questions that are already answered: if a process has been running inside the company for years, the job is not to test demand but to build a system with a written scope. Second, work whose result nobody will act on: if no one is authorised to change direction when the measurement lands, it is only an expense. Third, flows where the smallest working version is not actually small: payment, identity verification and regulated steps cannot be left half done. Fourth, cases where the product exists already and the problem is visibility or resilience rather than demand, where a new MVP is not the answer. ##### The project delivery package When an MVP finishes, you hold four things. The code, with its full history, in a repository on your own account rather than as a compressed folder, so who changed what and when stays readable. The running infrastructure: server, database and deployment pipeline sit on accounts opened in your name, which keeps the handover from becoming a separate migration project. The data and the measurement: the database schema, the event records, and the report that answers the question you started with. And the handover document: how the system comes up locally, how it is deployed, which decisions were deliberate, and what has accumulated on the post-MVP list. All four are delivered whether or not you continue the project with us. How to ask for them before signing with anyone is covered in [questions to ask when choosing an MVP agency](https://detartech.com/en/blog/questions-to-ask-when-choosing-an-mvp-agency). ##### How budget and scope are protected What protects a budget is not fixing the number but keeping scope in writing. Duration is estimated upfront, and because progress stays visible through the pre-prod environment the date does not turn into a surprise; scope is the thing that flexes. Every new request that arrives during the project is priced with one question: if this comes in, which item goes out, or does it open a separate line item? The decision is yours and the exchange is recorded in writing, so that at the end of the project there is no argument about where and why the scope grew. You keep the right to stop at any point, and because everything produced by then is already yours, stopping is a decision rather than a loss. Third-party costs, meaning payment commissions, cloud bills and app store fees, are listed separately from the start and billed to your own accounts rather than hidden inside a development fee. ##### Our measurement scope What we measure is completion of the core flow: could the user perform the action the product exists for, in how many steps, where did they drop off, did they come back. In a product that takes money the payment step is tracked separately, because the gap between intent and payment is the most expensive information available. There are things we deliberately do not measure: page views, sign-up counts on their own, time-based engagement averages, satisfaction scores on small samples. A product can fail while all of those rise, which is why they cannot drive a decision. Our own speed is not a success metric either; how many items we closed is internal tracking data. The measurement window and the sample size needed vary by project; if the data is not yet mature enough to support a conclusion, we say so rather than reporting a result as more certain than it is. ##### Our technology selection criteria An MVP is a bad place to learn a new technology, so the choice is made from a narrow set: tools we already run in production and that somebody else can maintain after handover. When transaction complexity, role structures and enterprise integrations dominate, the backend is .NET, as in Lextum AI, World Summer Schools and Welldone. When the weight of the work sits in the data model and the admin screens, Python and Django get there faster, and the Anneekspres marketplace was built that way. React and Next.js carry the interface, and we reach for Flutter or React Native when a single codebase has to reach field users on both iOS and Android. Three criteria drive the choice: who maintains it after handover, whether people who know that technology can be hired, and whether hosting stays on your own accounts. ##### What this looks like in practice The work listed below is either live or completed, and each project has its own page in the success stories section. - **[Lextum AI](https://detartech.com/en/success-stories/lextum-ai):** document generation, contract review, simultaneous editing and versioning for legal teams. Taken to production with a microservice architecture, RabbitMQ, role-based access and an audit trail. - **[Biletico](https://detartech.com/en/success-stories/biletico):** a platform with a foundation in place but almost nothing working was taken over; payment, search, profile and ticket management were made functional and a canvas-based seating plan was added. - **[World Summer Schools](https://detartech.com/en/success-stories/world-summer-schools):** hundreds of summer school programmes gathered into one searchable catalogue, with content entry accelerated through an OpenAI integration and role-based authorisation in place. - **[Anneekspres](https://detartech.com/en/success-stories/anneekspres):** a marketplace for mother and child products built from scratch: seller panel, payment and order flow, infrastructure on PostgreSQL and RabbitMQ. - **[BiTalih](https://detartech.com/en/success-stories/bitalih):** a content production platform built on fixed templates and variable fields; with role-based access, content production went from hours to minutes. - **[Welldone](https://detartech.com/en/success-stories/welldone):** a Flutter mobile app, a React management panel and .NET services for industrial laundry operations, with QR-code packaging in the field and real-time reporting for managers. - **[Terazzi](https://detartech.com/en/success-stories/terazzi):** work on an existing platform covering design and customer panel improvements, search engine visibility and backend performance. #### FAQ **How long does an MVP take and how is it priced?** Once scope is clear we give an estimated duration and price at the first meeting, not a calendar promise made later. We stay in constant contact with the client throughout the project, and you can usually watch progress live through the pre-prod environment we set up. If scope changes later, price changes with it; what comes in and what goes out is recorded in writing. **Do the code, infrastructure and accounts stay with us?** Yes. The repository sits on your account with its full history, the server and database are set up on accounts opened in your name, and the deployment pipeline runs there too. At the end of the project you receive the database schema, the event records, the measurement report and a handover document that explains how the system comes up locally and which decisions were deliberate. **How do we track progress during the project?** Changes made to the pre-prod environment we set up can usually be watched in near real time; the evidence of progress is working software, not a report. We stay in constant contact throughout, sharing progress on most days it is possible to share it. If something slips or breaks, we say so the moment we notice it rather than waiting for the next scheduled call. **Who maintains and grows the product after the MVP?** All three arrangements are possible: your own team continues, we continue, or the work is shared. The technical assessment handed over at the end of the MVP is what the decision is based on, since it separates what must change before growth from what can live as it is. Load and traffic work is a separate service, covered under backend scaling. **Does every idea need an MVP?** No, we say this plainly: if a process has run inside your company for years there is no demand left to test, and the right move is a system with a written scope. If nobody is authorised to change direction once the measurement lands, an MVP is only an expense. If the product exists already and the problem is visibility or load rather than demand, the answer is work on that product. **Does MVP code get discarded and rewritten later?** When the hypothesis is confirmed, specific parts change rather than the whole codebase. Durable pieces such as authentication, payments and the data model are built to production standard from the start, while faster work is concentrated where replacement is cheap, like admin screens and reporting. Which part carries priority is handed over in writing at the end of the MVP, so a rewrite decision rests on that assessment rather than a guess. **What should we look for when choosing an MVP development agency?** A handful of questions reveal most of it. Will the code repository live in your account with its full history, and will the server and database be opened in your name? Is the scope written down, including a list of what will not be built? Are the assumption being tested and the success threshold defined before any code is written? Can you follow progress on a working test environment rather than in reports? Will you receive a written handover document and a technical debt assessment at the end? Are payment provider, cloud and app store fees listed separately from the development fee? And will the agency tell you when an MVP is the wrong answer for your idea? We apply the same questions to our own work. --- ### Vibe-Code to Production URL: https://detartech.com/en/services/vibe-code-to-production Cursor, Lovable, Replit, Codex and Claude Code output made production-ready: security audit, fixes shipped as PRs, a permanent CI/CD security gate. Highlights: - Three stages: audit, fix, a permanent CI/CD security gate - Access control, secret leaks, hallucinated packages and injection bugs scanned - Half-built integrations and endpoints never tested under load are in scope too - Every finding ships as its own PR: changed files, reasoning, a test proving the fix - Static analysis and dependency scanning get embedded in your release pipeline - Delivery package: the finding report, fixed code, a working security gate An app now comes together from a few sentences of instructions in hours: a feature gets requested in Cursor, an interface gets designed in Lovable, a backend spins up in Replit, Codex or Claude Code wires up an integration. Screens render, forms save data, login works. But the model that wrote it was optimizing for finishing the request, not for holding up in production. Veracode's 2025 report, testing over a hundred models, found that 45 percent of generated code carried an OWASP Top 10 flaw, and model size did not change that rate. In an independent audit of vibe-coded applications, only 10.5 percent came back secure. The problem isn't limited to security either: integrations like payments or authentication get left half-built, the app has never been tested under real user load, and AI calls go out with no spend cap or rate limit. This service exists for that exact point: teams who got their product to a certain place with these tools and now don't know what's missing before it goes live. ##### Three situations, three different entry points People come to us in one of three states. The first is a live leak: user data, an API key, or another customer's record is visible by mistake, and either you or a security researcher noticed. The second is a pre-launch check: the product is considered done, but nobody looked at security and resilience systematically, and someone wants a professional pass before it goes live. The third is a growth stall: the code has become a pile nobody wants to touch, every feature shipped quickly risks breaking something else, and nobody knows where to start. The first step is the same in all three: read the existing code and separate what works from what happens to work. ##### Three stages: find, fix, install the gate Most vibe-code audits deliver one thing: a report ranking findings. A finding list does not change your codebase, it only tells you where you stand. Our work runs in three stages: audit first, covering not just security flaws but half-built integrations, endpoints never tested under load, and the cost risk of unbounded AI calls; fix second; and third a permanent security gate wired into your CI/CD pipeline, the automated system that builds and ships your code with every update. Without the third stage the other two are temporary, because the next AI-assisted commit reproduces the same failure class. Once the gate is in place, every new change you or your AI tool pushes is scanned automatically and blocked before it merges. ##### Where we look during the audit Four areas get scanned every time, because nearly every real leak comes from one of them: who can see what, where secrets are sitting, whether dependencies actually exist, and where user input ends up. Alongside these we flag half-built integrations such as payments or authentication, and endpoints that will break under real traffic; these aren't a separate line item, they're part of the same pass. ###### Access control and visibility permissions The most expensive failure class is access control, because it stays quiet. In the Tea app, flawed authorization logic the model generated exposed private messages to other users. Every project created on Lovable before November 2025 was exposed for 48 days; a free account could reach another user's source code, database credentials and customer data. In both cases the code ran fine and the screens looked right; the problem sat where tests never look: whether a user can swap their own ID and reach someone else's record. During the audit we test every endpoint by hand for who can see which record, because an automated scanner alone does not catch this. ###### Secret and credential leaks AI-assisted commits expose secrets at twice the rate of human-written code: an API key, a database password, a third-party token ends up hardcoded or dropped into Replit's environment file. The model is not doing this maliciously, it is taking the shortest path to a working example, and the shortest path usually means writing the secret as plain text. The audit scans the entire codebase, including past commits, because once a secret has entered history, deleting it from the environment file is not enough; the key itself has to be rotated. ###### Dependencies and hallucinated packages When models are prompted for code, on average a fifth of the packages they suggest do not actually exist, and these names are not random: rerun the same prompt and a high share of the same hallucinated names come back. That predictability created a new attack class called slopsquatting. An attacker registers a real package under the hallucinated name and drops malicious code inside it, and because the model recommended that exact name, a developer installs it without noticing. During the audit we check whether every package in your dependency list actually exists and whether its download count and maintenance history look reasonable. ###### Input validation and injection-class bugs In the same Veracode report, 86 percent of tested code was vulnerable to XSS, meaning a user's input gets written straight into the page and runs in the browser, and 88 percent was open to log injection, where unchecked data gets written into server logs. Both come from the same root: data coming from a user is never cleaned before it is written to the screen or dropped into a query. Model-generated code usually works fine for the intended use case, not for a malicious one. During the audit we trace every user input to see where it ends up, whether that's the screen, a query, or a file path, and whether validation exists at that point. ##### Fixing and locking it in Finding issues is never sold apart from fixing them; they come together, because a finding list on its own protects no one. The fix isn't limited to security either: finishing a half-built payment integration, completing an authentication flow, or adding spend and rate limits to AI calls all move through the same package. ###### The fix: mergeable code, not a report We do not stop at the finding list. Every finding gets its own pull request, a self-contained proposed change you can review and approve: the files that changed, the reasoning, and a test that proves the hole existed before the fix. Priority follows severity and proximity to user data; an access bug leaking personal data in production is closed before a configuration issue that has no measurable impact. We work like a new engineer reading your codebase, not imposing our own preferences; we make the smallest change that fits the architecture you already have. ###### A security gate built into CI/CD A fix is not permanent, because your AI tool can reproduce the same mistake tomorrow. That's why the last step is embedding static analysis, dependency scanning and secret scanning into your release pipeline: every pull request is scanned automatically, and a critical finding blocks the merge. The gate works the same regardless of who pushes the change; whether you wrote it by hand or an AI agent committed it makes no difference. This gate gets added to a CI/CD pipeline you already have, or built together with our [DevOps and CI/CD](https://detartech.com/en/services/devops-ci-cd) service if you don't have one yet. Once the gate is running, the same failure class stops reaching production at all, and your own team can maintain it without needing us again. ##### How scope gets defined Scope gets written down during the scoping call: which repository, which environment, which integrations are included. Which AI tool produced the code doesn't change the audit's scope; everything goes through the same process. The audit scans known failure classes that can be found with current knowledge, and every class we scan closes with either a fix or a knowingly accepted risk note. An architectural decision, redesigning the entire data model for instance, falls naturally outside this audit's boundary; if that need comes up, the work moves to [Backend Scaling](https://detartech.com/en/services/backend-scaling) or [CTO as a Service](https://detartech.com/en/services/cto-as-a-service). Because this clarity is built in from the start, what each side is getting is clear from the first day of the conversation. ##### Initial scan findings A first scan of a vibe-coded application turns up almost the same three things nearly every time, regardless of which tool produced the code: an admin screen reachable without authentication, at least one API key hardcoded into the source, and at least one user input with no real validation. An independent scan of more than five thousand publicly deployed vibe-coded apps in May 2026 found that around 40 percent exposed sensitive data such as medical or financial records, and more than two thousand corporate apps had no access control at all. We hold ourselves to the same discipline: every piece of code we ship, this site included, passes through a sanitization layer that lets nothing past its allowed tag list and an automated pre-commit review. We don't recommend a method we don't apply to our own work. ##### Process: from first contact to delivered code The process runs in four steps. It starts with a short scoping call covering which repository, which environments and which integrations are involved. From there the audit follows, usually taking three to five business days and ending in a written finding list ranked by severity, one that can also be taken on its own. The fix comes next, with its length depending on how many findings are in scope, and each one arrives as its own pull request. The last step installs the CI/CD gate and runs a trial with your team. Everything closes with a handover document covering what each check looks for, what to do when it fires, and how your team updates the gate going forward. #### FAQ **How long does this audit take and how is it priced?** It splits into two parts, each priced separately. The audit takes three to five business days and ends in a written finding list priced against the size of your codebase. The length of the fix stage depends on which findings are in scope and is quoted separately once the audit is done. We do not quote a fix timeline before the audit, because that would be a guess. **Do you work with code written in Cursor, Lovable, Replit, Codex or Claude Code?** The tool that generated the code matters less than the language it's written in. We work with JavaScript, TypeScript, Python, .NET and PHP codebases; whatever tool produced the code, the audit covers the same ground: access control, secret management, dependencies, input validation and half-built integrations. If a platform has a vulnerability specific to its own infrastructure, we flag that separately during scoping. **Our product is already live with real users, will the audit cause downtime?** No, the audit is read-only; we examine your code and production environment without changing them. During the fix stage, changes are verified in a staging environment first, and anything shipping to production goes out with your approval during low-traffic hours. If we find something critical during the audit, an admin screen open to the public for instance, we report it the moment we find it, before the full report is finished. **Do you guarantee zero security vulnerabilities?** No, and don't trust anyone who does. The audit covers known failure classes that can be found with current knowledge; a zero-day cannot be guaranteed against. What we can promise is specific: for every class we scan, you get either a fix or a written note explaining why it was not fixed, plus a CI/CD gate that catches future mistakes. **We only want the report, can our own team handle the fixes?** Yes, the audit can be taken on its own. The finding list is ranked by severity and written in enough detail for your own team to act on each item. We also offer the CI/CD gate setup as a separate line item, so you can take just that piece if you prefer. **Does every AI-written project need this audit?** No. If it's an internal-only tool with no outside access and no user data, the risk is low and a full audit usually is not necessary. If it's a public-facing application with user accounts, payments, or personal data, our advice is direct: do it before launch. --- ### Mobile App Development URL: https://detartech.com/en/services/mobile-application Mobile app development for iOS and Android with Flutter and React Native, from Istanbul: version compatibility, offline use, store release, accounts you own. Highlights: - One codebase with Flutter and React Native, Swift and Kotlin where needed - A backend contract compatible with old clients, plus minimum version checks - Offline behaviour and conflict rules written into the scope - App Store and Google Play submission, rejection causes cleared beforehand - The forced update mechanism is built into the first release - Store accounts, signing keys and source code stay in your name The screens are the most predictable part of a mobile app. The hard part is distribution: the version you publish lands on a user's phone and stays there for months, and a bad release you would roll back on the web in ten minutes cannot be rolled back on mobile. Store review sits in the middle, and nobody installs the update at the same moment. That is why the most expensive decision is not how a screen should look, but how many versions will be running in the field six months from now and how the server answers all of them. At Detartech we open every mobile project with that question. ##### The real challenge in mobile apps Unlike a web release, a mobile release is a distribution to thousands of independent devices, each taking the update whenever it decides to, with two gates in between that you do not control: store review and the user's update behaviour. A downloaded version cannot be recalled. There is no rollback, only publishing another version, and that one goes through review again. Three consequences follow: the server has to stay compatible with old clients you can no longer change; the app has to be able to tell a user "this version is no longer supported"; and field errors have to be visible remotely, because users do not report bugs, they delete the app. Unless these three are built into the first release, they get built later at a higher price. ##### The decisions a mobile project actually makes The six headings below cover the durable decisions in a mobile project: two on technology and contract, two on device constraints, two on distribution. ###### Choosing between cross-platform and native Flutter and React Native produce iOS and Android from one codebase; Swift and Kotlin write each platform separately. Three criteria decide it: how much the app touches device capabilities (camera, Bluetooth, background location), how much platform-specific feel the interface needs, and who maintains the app after handover. Feeding one team instead of two is often decisive for business applications. Welldone is the example there: the field app in Flutter, the management panel in React, the services in .NET. The field needed QR scanning for item-level packing and instant order status, not a platform-specific interaction. Choosing cross-platform does not mean native code is never touched: permissions, notification registration and background behaviour are still handled per platform. ###### The backend contract and version compatibility A mobile app's API is a contract, and on the other side of it sits a client you cannot update. On the web you ship the interface and the server together; on mobile you cannot. So the rule is: no field removed, no field renamed, no new required field. When a change is needed, a new field is added and the old one keeps being populated, with the version at which it stops written down. The server also has to state the minimum app version it supports, because closing the support window is a server-side decision. Togodo and Welldone both run .NET services behind the mobile client. When the problem is not the contract but the load, meaning concurrent users and query cost, the work leaves the mobile side and moves to [Backend Scaling](https://detartech.com/en/services/backend-scaling). ###### Offline behaviour and synchronisation Offline support is not a feature added later; it is a decision that changes the data model from the start. Three questions get answered while scope is written: which screens open without a connection, whether an offline write is queued or blocked, and which side wins when two devices change the same record at different times. If the third answer is not written down, data corrupts silently and you notice months later. Supporting offline means a small local database and a synchronisation layer inside the app, a real cost line. In field apps used in warehouses, basements and vehicles, skipping it ends with the app not being used at all. Inside an office it can be needless complexity, so the decision follows the need, not a default. ###### Notifications and background work A push notification is not a feature of the app, it is a chain: your server, the Apple and Google notification services, the device, and an operating system that has the last word. It can be dropped at any link: the user can refuse permission, the system can delay delivery to save battery, the device can be off. So no workflow depends on notifications alone; a user who misses one has to see the same information when they open the app. Background work is limited too: the operating system wakes your app when it decides to, and a feature built on a background task assumed to run at regular intervals works on the test device and fails in the field. Togodo is the example here: real-time messaging and push notifications were built for the social events app. ###### Store submission and the reasons apps get rejected The App Store and Google Play are separate processes with different rules and timelines. In the release calendar, review time stands as its own line: it is outside your control and the first submission is usually the slowest. The common rejection reasons can be cleared up front: a missing or inaccurate privacy declaration, no path to delete an account, no working test account for the reviewer, mandatory sign-in without justification, permissions requested without an explanation string, incomplete store assets. Each one, fixed after the fact, costs a full review round, so they sit on a pre-submission checklist. The store listing is part of the delivery package too: title, description, keywords, screenshots. An automated build pipeline shortens the loop; on Welldone the CI/CD automation was built with Jenkins, and the detail belongs to [DevOps and CI/CD](https://detartech.com/en/services/devops-ci-cd). ###### Forced updates and the fact that releases are irreversible The minimum supported version mechanism is built into the first release, not added later. It works simply: on launch the app tells the server its version, and if that version is no longer supported the user sees a blocking screen linking to the store. Without it there is no way to retire an old version; all you can do is wait. Once it exists it gets used sparingly, because a forced update stops the user mid-task; it is reserved for security holes, bugs that corrupt data, or a contract change that can no longer be sustained. Staged rollout is another safety valve: you open the release to a fraction of users, watch the crash rate, halt it if things go badly. Halting only protects those who have not installed yet. That is why crash reporting is switched on with the first release; learning about a field problem from store reviews is the latest possible way to learn it. ##### Why old versions become a problem Every version you have published keeps living in the field. Between devices with auto-update off, operating systems that no longer receive updates, and users who open the app once a month, what exists out there at any moment is not one version but a queue of them. The daily cost: every server change has to be checked not only against the newest version but against the oldest supported one. The expensive class of bug is not the crash, because a crash is visible. The expensive one is an old client writing missing or outdated data, silently, into the database. So the supported version window becomes a written policy from the start: which operating system versions are supported and how the app behaves below a given version. There is also the test most teams skip: the new server version is tried while the previously released app is still installed. ##### The scope of post-launch maintenance Maintenance on mobile does not mean "fixing bugs". A mobile app stops working over time even if nobody touches its code, because the ground underneath it changes several times a year. The calendar has fixed items: behaviour changes in each year's operating system major release, store rules on build targets and privacy declarations, expiring signing certificates, third-party library updates. When a certificate expires the app keeps running but you cannot publish a new version, so you lose the ability to fix bugs. Alongside sits continuous monitoring: crash reports, unresponsive-screen records and store reviews. A store review is not a marketing indicator, it is a bug source. Taking over a live app and improving it is normal work here too. On Togodo the existing app was functional, but the event management, messaging and user profile screens had gaps; new screens were designed for the existing platform, real-time messaging was built, and SEO and ASO (App Store Optimization) work was carried out. ##### How we choose the right format The decision rests on four questions. If the browser can carry the job, meaning the need is to show content, collect a form or present a report, a mobile-friendly web application ships faster and does not wait for a store review. If demand is not yet validated, that gets validated in [MVP Development](https://detartech.com/en/services/mvp-development) first, because being listed in the store is not proof of demand. If it is an internal tool with a known user base and the flow needs no camera, QR scanning, offline operation or hardware access, a web panel gets there faster. If notifications are the only reason for the app, email, SMS and web push get evaluated first, because taking on an asset that needs permanent maintenance for a single channel is an expensive decision. Once these four questions are answered, the right format follows from them. ##### Accounts, signing keys and handover Ownership on mobile is not only the source code, it is the accounts and the keys. Store accounts are opened in your company's name: the listing, reviews, ratings and download history are tied to that account, and moving one is a separate job. Signing keys matter even more. If the Android signing key or the iOS certificates are lost, you cannot update the same listing; users would have to install a new app and your user base resets. So the keys are kept under your control from the start. Source code sits in your repository with its full history; server and database run on accounts in your name. The handover document is part of the delivery package too: how the app builds locally, how it reaches the stores, which permissions are requested and why, and the minimum supported version policy. ##### Two apps currently live Both projects below are live, each with its own page in the Success Stories section. - **[Welldone](https://detartech.com/en/success-stories/welldone):** A Flutter field app, a React management panel and .NET services for an industrial laundry operation. Order, shipment, shelving and packing came onto one platform; the field team scans QR codes for item-level packing, order status updates instantly, team communication runs through the same platform. Infrastructure on .NET and MySQL, CI/CD automation on Jenkins. Welldone Helper can be downloaded from the App Store and Google Play. - **[Togodo](https://detartech.com/en/success-stories/togodo):** A live social events app was developed further. New screens were designed for event listing, user profiles and community management; users create events, join them and invite friends. Real-time messaging and push notifications were built, SEO and ASO work was carried out, and performance improvements corrected behaviour under high traffic. Flutter on mobile, .NET on the server. #### FAQ **How long does a mobile app take, and can you commit to a date?** We commit to a development and submission date, not to the moment the app goes live in the store. The calendar has two parts: the development we control, and the store review window we do not. The first submission is usually the slowest. To reduce the chance of rejection, items like the privacy declaration, the account deletion path and a working test account go through a checklist before submission. **Can a single codebase really match native?** For most business applications it can, and the deciding factor is how much the app touches the device. Flows built on camera use, QR scanning, notifications and forms run comfortably on Flutter or React Native. Work that needs continuous background location, heavy graphics or platform-specific system integration belongs on the native side. One criterion is not technical at all: who maintains the app after handover. **Who keeps the store accounts, signing keys and the code?** You keep all of them. Store accounts are opened in your company name, because the listing, reviews and download history are tied to the account. Signing keys and certificates stay under your control; if a key is lost, the same listing cannot be updated and the user base resets to zero. The source code sits in your repository with its full history, and the handover document records the build and release steps. **What happens if users do not install an update right away?** Old versions keep living in the field for a while, which is why the server side is checked against the oldest supported version, not only the newest. For serious cases such as a security hole or a bug that corrupts data, the app can show a blocking screen through the minimum-version mechanism, built into the first release, that directs the user to update. Ordinary updates do not force anyone; backward compatibility is maintained. **Is maintenance mandatory after launch, and what happens without it?** It is mandatory, because a mobile app degrades even if nobody touches its code: operating systems ship a major release every year, stores change build target and privacy rules, and signing certificates expire. When a certificate expires the app keeps running but you cannot publish a new version, which means you lose the ability to fix bugs. Maintenance can also be run by your own team. **Does every business need a mobile app?** Not always, and we say so plainly: if the need is showing content, collecting a form or presenting a report, a mobile-friendly web application costs less and its fixes go live the same day. If demand has not been validated, validation work comes first. If notifications are the only reason, email, SMS and web push should be evaluated before taking on an app that needs permanent maintenance for one channel. **What determines the cost of mobile app development?** Cost is driven more by decisions than by the number of screens. The main factors: whether you need one cross-platform codebase or two native apps, how much the app relies on device capabilities such as the camera, Bluetooth or background location, whether it must work offline and sync later, and the scope of the backend, admin panel and third-party integrations. Post-launch maintenance is a separate line, because operating systems and store rules change every year. Once the scope is written down we share an estimated timeline and price in the first meeting; third-party fees such as store accounts are listed separately. **Flutter or React Native: which should we choose?** Both ship iOS and Android apps from a single codebase, and for most business apps either one is enough. The deciding factor is usually the team rather than the technology: React Native is written in JavaScript and TypeScript, so a team that already knows React on the web maintains it more easily; Flutter is written in Dart and renders its own interface components, which keeps the look consistent across both platforms. The mobile side of our two live apps, Welldone and Togodo, is built with Flutter. We decide with three questions: how much the app touches device capabilities, whether the interface needs a platform-specific feel, and who will maintain it after handover. --- ### Web Development URL: https://detartech.com/en/services/web-development The cost of a web project shows up over time, not at launch. We settle rendering strategy, type safety, multilingual architecture and content management up front. Highlights: - Rendering chosen per page type, cache refresh tied to events - Core Web Vitals tracked from field data, not from a lab score - Strict TypeScript with runtime validation at the data boundary - Localised URL structure and a right-to-left layout for Arabic - An admin panel the content team can publish from unaided - Migrations that map addresses one to one and hold them with 301s The cost of a web project is not decided at launch. It becomes visible later: when a new language is added, when the content team wants to change a page without waiting for a developer, or when the URL structure moves. Three decisions set that cost: when each page is generated, whether type safety is enforced at the data boundary, and who is able to manage the content. None of the three can be bolted on later; skipped at the start, they get rewritten. ##### Our definition of web development For us web development means building a database-backed, manageable application, not putting up a brochure page. Three different jobs share the name. The first is a ten-page corporate site whose content changes a few times a year: an off-the-shelf theme is usually enough and you do not need us; we say so in the first meeting. The second is a multilingual content platform of hundreds of pages that earns search traffic. The third is an application with accounts, payments and third-party integrations. Only the last two force real decisions about rendering, type safety and the content model. We wrote about how the web turned from a document format into an application platform in [the story of web development](https://detartech.com/en/blog/the-story-of-web-development-from-a-document-to-an-application-platform). ##### The six decisions inside a web project The six headings below cover the decisions that are most expensive to reverse. The first two set how fast the site is: when a page is generated and where performance is measured. The third is whether the code stays safe to change over time. The fourth and fifth are how many languages the site publishes in and who may touch the content. The sixth applies only when there is an existing site to move. ###### Rendering strategy: when each page is generated There are three options. Static generation builds the page at compile time; when the set of addresses is known, it is the fastest and cheapest route. Server-side rendering builds the page per request, which per-user or constantly changing content needs. Incremental regeneration keeps the page static and refreshes it when the content changes. The detail that matters is in the third: refreshing should be tied to an event, not a timer. On the site you are reading, a save in the admin panel invalidates only the matching cache tag, so no rebuild is involved. The archive of bebekistiyorum.com, made up of 66 medical articles, hundreds of video pages and expert profiles, is published on a MongoDB-backed platform rendered on the server with the Next.js App Router and React Server Components. ###### Core Web Vitals and real user measurement A lab score and field data are not the same thing: Lighthouse measures one device, one connection profile and an empty cache, while the data Google actually uses comes from the browsers of real visitors. So instead of a green score we watch three field metrics: how long the largest content element takes to paint, the delay between an interaction and the next paint, and how much the layout shifts during a visit. The set of things that breaks them is narrow: images served without dimensions, fonts that arrive late, an oversized JavaScript bundle, and code that measures an element after mount and immediately changes a style. That last one forces a synchronous layout pass, so on visitor-facing pages we read measurements from the ResizeObserver callback itself. Mobile performance was a known problem of the old ASP.NET version of bebekistiyorum.com, and the new platform carries performance work focused on Core Web Vitals. ###### Type safety and maintainability with TypeScript The value of TypeScript shows up when you change code, not when you write it. Rename a field and the compiler points at every place that touches it; without types you do the same job with a text search and hope. That guarantee has three conditions. Strict mode: TypeScript's implicit any, which lets a value pass through unchecked whenever its type is never declared, has to be switched off, otherwise the type system is decoration. The data boundary: anything arriving from a database, an external service or a form has to be validated with a runtime schema rather than a type assertion, because types are erased at build time and no interface declaration stops a wrongly shaped response. Third, type checking belongs in the pipeline, not in human discipline. We went into the long-term effect of architectural decisions in [our article on software architecture](https://detartech.com/en/blog/how-to-design-scalable-and-maintainable-software-architecture). ###### Multilingual architecture and RTL Publishing in several languages is not a translation-file problem, it is a URL and layout problem. Each language needs its own address, the relationship between them declared to search engines with hreflang, and the path segments themselves translatable. On the site you are reading the address is localised too: the same page lives under hizmetlerimiz in Turkish, услуги in Russian and خدماتنا in Arabic. Right-to-left languages add a second layer. Arabic flips more than text direction: margins, icon orientation and form alignment all mirror, and building that with left and right instead of logical CSS properties means writing every component twice. bebekistiyorum.com publishes in Turkish, English, Russian and Arabic, with every component designed to work right to left for Arabic. We collected the mistakes we see most often in [our notes on localisation](https://detartech.com/en/blog/localization-tricks-on-software-development). ###### Content management and editor independence The real owner of a site is whoever can change its content. If every text edit needs a developer, the site quietly stops being updated. That is why we model content at the field level, not the page level: title, summary, body, media and metadata are defined separately, so an editor can publish without breaking the layout. HTML coming out of a rich text editor is sanitised on the server against an allowed tag list, because sanitising in the browser is not sanitising. On [bebekistiyorum.com](https://detartech.com/en/success-stories/bebekistiyorum-ivf-clinic-website) a custom admin panel was built with the Tiptap rich text editor and bulk content import. The contrast with the old version is the clearest result: in the old setup every content update required technical support; in the new one the content team publishes without developer support and without paying for a CMS licence. ###### Migration and preserving URL value When an existing site is rebuilt, the most expensive mistake is quietly changing the URL structure. Years of accumulated search value sit on the address, not on the page; if the address disappears, the value goes with it. The order that works: pull every address of the old site from its sitemap, server logs and search console, map each one to a destination in the new information architecture, then ship that map as permanent redirects. Sending everything to the homepage is not a mapping and carries no value. On bebekistiyorum.com more than 1,200 addresses from the old ASP.NET site were mapped to the new architecture and preserved through a database-driven 301 redirect layer. We keep that map in the database, so gaps that surface after launch can be filled without waiting for a deployment. Tracking indexing and rankings afterwards belongs to [our SEO service](https://detartech.com/en/services/seo). ##### What we look at first in projects we inherit When we take over a codebase somebody else wrote, the first week answers six questions rather than reading code. Does the project install on a clean machine and does the build pass; without setup documentation you inherited a puzzle, not a codebase. How many errors do type checking and linting report; that number is written down as a baseline before anything is fixed, so later changes cannot hide behind it. How many major versions behind are the dependencies, and are there known security advisories. Are real keys or passwords sitting in the repository; if so, the work starts with rotating them, not with code. How many queries does a list page fire, and are they indexed. Where does the traffic actually land, and what shape is the redirect layer in. The findings go into a one-page note: fix now, put in the release plan, leave alone on purpose. ##### How a performance budget is set A performance budget is a set of ceilings written down before the code: JavaScript weight per page type, image weight, third-party script count, and the field metrics being targeted. Without a budget, page weight only moves one way: no single change slows a site down on its own, accumulation does. Two rules make a budget usable. Measurement has to live in the pipeline: when a ceiling is crossed, the person who made the change sees it the same day, not a user months later. And a budget is a negotiating table, not a ban: a change that breaks the ceiling is not rejected, what comes out in exchange is written down and the call stays with you. The usual source of overruns is predictable and rarely development: chat widgets, tag managers, heatmaps and ad scripts. ##### The question of who will run the site We ask this before design starts, because the answer changes the architecture: who touches the site, how often, and with what permissions? Three typical answers. For a site whose content changes a few times a year, a separate admin panel is a cost with no return; text can live in the code. For a small team entering content a few times a week, a custom panel is right: the fields are defined around that team's actual work and the learning curve stays short. Where there are dozens of editors, approval steps and a translation workflow, buying an established headless CMS, meaning a content system with no front end of its own that serves content through an API, is the better call, and we say so. Whichever answer comes out, three things are part of delivery: role separation, preview before publishing, and a written note on how the panel is used. On bebekistiyorum.com the answer was a custom panel, and its test was simple: the content team publishes without developer support. ##### Five items in the delivery package Five things stay with you when the project ends. First the repository: it sits in your own account with its full history, not as a zipped folder. Second the infrastructure: server, database and domain are set up on accounts opened in your name, so parting ways is not a separate migration project. Third the content: the database schema and the content in exportable form. Fourth the address record: redirect map and sitemap, with the old-to-new mapping if a migration was done. Fifth the handover note: how the project starts locally, how it is deployed, how the panel is used and why each decision was made. ##### One project, all of it together Most of the decisions on this page can be seen in one project: bebekistiyorum.com, the site of the Eurofertil IVF Centre, moved from an old ASP.NET WebForms stack to a four-language Next.js platform. The first five items below are written on that project's own page; the sixth is the site you are reading. - **Rendering and data:** a MongoDB-backed platform rendered on the server with the Next.js App Router and React Server Components. - **Migration:** more than 1,200 addresses from the old site mapped to the new architecture and preserved with a database-driven 301 redirect layer. - **Multilingual publishing:** Turkish, English, Russian and Arabic; every component designed right to left for Arabic, language versions declared with hreflang. - **Content management:** a custom panel with the Tiptap editor and bulk content import; the content team runs the whole site without needing a CMS licence. - **Technical SEO:** per-page dynamic metadata, an automatic sitemap, schema.org structured data and Core Web Vitals performance work. - **detartech.com:** the same architecture: Next.js App Router, four languages, localised path segments and a right-to-left layout in Arabic. #### FAQ **How long does a web project take and how is it priced?** Duration is set by the number of templates, not the number of pages: if fifteen pages come out of the same three templates, it is a three-template job. The other variables are the number of languages, the scope of the admin panel and third-party integrations. We write those four down in the first meeting and give a range. Migration is priced separately, since its effort is independent of page count. **Do the code, infrastructure and content stay with us? Are there licence fees?** The repository sits in your own account with its full version history, the server and database are set up on accounts opened in your name, and the content stays exportable from the database. If we need a closed component that carries a licence fee, we put it in writing before the contract. On bebekistiyorum.com the content team runs the whole site without needing any CMS licence. **If we migrate our existing site, will we lose our search rankings?** A migration done properly keeps this risk largely under control, but nobody can guarantee rankings. The most common cause of loss is addresses left without a destination. So before the switch we extract every URL of the old site, map each one to a page in the new structure and publish the mapping as permanent redirects. When bebekistiyorum.com was migrated, this was done for more than 1,200 addresses through a database-backed 301 layer. Redirecting everything to the home page carries no value, so we do not take that shortcut. **Can we update the content ourselves after launch?** Yes, and we treat that as the test of delivery. The admin panel is defined around the fields your team actually fills in; editor output is sanitised on the server, role separation and preview come as standard, and a written note on using the panel is part of the handover. A developer is needed for a new page type or a new field, not for a text change. **Does every site need custom development?** Not always, and we say so directly. For a ten-page brochure site whose content changes a few times a year, an off-the-shelf theme is usually enough and working with us would not pay for itself. The same holds at the other end: where there are dozens of editors, approval steps and a translation workflow, buying an established headless CMS beats writing a panel from scratch. **Are Next.js and TypeScript overkill? Would an off-the-shelf platform be cheaper?** At launch it usually is cheaper. The difference shows up over time: in a multilingual site that also needs a right-to-left layout, the plugin dependency grows until every update carries risk and the performance budget stops holding. The test is simple. If the site is a few pages of brochure, the ready-made route is right; if it is a database-backed multilingual platform, it is not. --- ### AI Integration and AI Solutions URL: https://detartech.com/en/services/ai-solutions AI integration: we connect LLM and agent systems to your existing product and workflows. RAG, document automation, measured accuracy and clear data boundaries. Highlights: - RAG and enterprise knowledge retrieval with source attribution - Agent workflows with tool calling, loops, and graph structures - Accuracy measured with a golden set and an eval harness - An agent-readable surface via WebMCP, llms.txt, and structured data - Token cost and latency budget management - Data boundaries compliant with KVKK and GDPR We do not train models from scratch; instead we place existing language models, or LLMs, inside the product you already run and the process your team already follows. We do it on two conditions: the result has to be measurable, and it has to be reversible. Measurable means accuracy is tracked as a number on a golden set. Reversible means that if the LLM layer is switched off, the process keeps working the way it did before. Building a demo is easy, because it only has to work once, for one scenario. The hard part is turning that demo into a system that runs every day, whose cost is known and whose errors are counted, and Detartech's AI work is that second part. ##### The scope of our AI solutions service When we say AI solutions we mean the application layer. We are not a model lab: we do not train foundation models, we do not research new architectures, and we are not chasing benchmark tables. Our job is to build the layer around an existing model that makes it useful. That layer is retrieval (making sure the model sees the right data), verification (checking the output before anyone accepts it), workflow (which screen the output lands on, and after whose approval) and observability (what it spent, how long it took, how often it was wrong). A demo has none of these layers, which is why it comes together in days. A production system takes time because of them. There is also work we do not take on: projects with no verifiable definition of success, requests of the "let us put some AI in and see what happens" kind, and critical decisions whose output nobody will ever check. ##### Our service lines The six headings below cover everything that comes up in an AI project. The first five are where a language model earns its place: knowledge retrieval, document processing, agent workflows, features inside your product, and opening your site to agents. The sixth is the opposite, where a language model costs more and adds nothing, and we say so upfront. Most projects start with one heading and add a second over time. ###### RAG and enterprise knowledge retrieval We build systems that answer questions over your own documents, records and knowledge base. The work does not end with pasting a document into the model: we split the content at meaningful boundaries, turn the pieces into embedding vectors, then rerank the candidates so the model only sees the ones that are genuinely relevant. Retrieval quality gets measured on its own, because if the right passage never reaches the top of the list, the answer comes out wrong no matter how good the model is. Every answer shows which document and which section it came from. Source attribution is not an optional feature here; it is the default. An answer with no visible source cannot be used in a business process even when it is correct, because nobody can check it. ###### Document understanding and automation We turn raw documents into structured data. The input can be a PDF, a scanned form, an email attachment or free text; the output is a record that matches your schema, filled in field by field. The same line also handles classification (what type of document, which department owns it), summarization and field-level comparison. The last step is the one that matters: the output is never written straight into your system. The model produces a confidence score and a source location for each field, and any record that falls below the threshold goes to a person for approval. That way the error rate does not climb out of control as automation goes up. Every approved record also becomes data for measuring accuracy. ###### Agent-based workflows For work that takes more than a single question-and-answer turn, we build an agent. The model invokes the tools you have defined through tool calling: search, a database query, an API call, writing a file. The workflow moves through loops and graph structures, and the state of every step is stored. What happens on failure is written down in advance: how many retries, how long to back off, which errors get handed to a person. Every run leaves a step-by-step audit trail: which tool was called with which input, what came back, and at which step the decision was made. An agent with no audit trail gets switched off the first time it does something wrong. ###### LLM features inside your product We add model-driven features to a product that is already in use: filtering in natural language, semantic search, suggestions based on user context, draft text generation, a short summary of a long record. We do not rewrite the interface to make room for them. The feature sits inside the existing screen, the classic path stays where it is, and the user can go back to the old flow whenever they want. If response latency goes past what a user will wait for, the feature is either streamed or moved to the background. When the model is unavailable the product keeps working; the LLM feature is built as a layer you can switch off, not as a dependency. ###### An agent-readable web surface: WebMCP and llms.txt Agents now browse websites the way people do. Opening a site to an agent does not mean making it easier to scrape; it means handing the agent tools it can call directly. With WebMCP, an agent in the browser calls the tools the site itself defines. llms.txt tells a model which sources to read. An RFC 9727 API catalog announces to machines which APIs exist. Structured data leaves no ambiguity about what a page means. The result is that an agent acting on a user's behalf works against a defined interface instead of guessing. We implemented all of this on our own site, because we do not recommend something we have not run ourselves. What WebMCP is and what agentic browsing changes for SEO and GEO is covered in [our WebMCP article](https://detartech.com/en/blog/webmcp-agentic-browsing-seo-geo). Visibility inside AI answer engines is a separate subject, covered on our [GEO service page](https://detartech.com/en/services/geo). ###### Where classical machine learning is still the right answer Not every problem needs a language model. When the job is predicting a number, classical methods are both cheaper and more accurate: demand and inventory forecasting, sales projection, churn scoring, anomaly detection in transaction records, visual defect classification on a production line. Here the input is already a structured table, and the model has to answer in milliseconds rather than seconds. Putting an LLM there raises token cost and latency for nothing in return. At the start of a project we separate which problem belongs to which method, and if we can solve something without an LLM, saying so is part of the job. ##### How we work We move in three stages: proof of concept, pilot, production. In the PoC we build one real scenario on your own data and hand the result back with a measurement table; the goal is not an impressive show but a decision about whether the work is feasible. A PoC typically runs two to four weeks. In the pilot the system opens to a limited group of users, real errors are collected, and the flow is corrected against them. Production brings in monitoring, cost tracking, release management and handover documentation; the deployment pipeline and monitoring side is described on our [DevOps and CI/CD service page](https://detartech.com/en/services/devops-ci-cd). We work in two-week cycles, and each cycle ends with a running version and its measurement. If you decide at the end of a stage not to continue, you keep working code, a data pipeline and the measurements. The questions worth asking before you pick a team are collected in [how to choose an AI integration company](https://detartech.com/en/blog/how-to-choose-an-ai-integration-company). ##### How we measure accuracy Whether an AI system works is settled by measurement, not by impression. We start by building a golden set: the real questions your team asks day to day, together with the answers you accept as correct. That set runs automatically through what we call an eval harness, a test setup that reruns every question on every change, so the result is measured again when a prompt changes, a model version is updated, or a retrieval setting is adjusted. When the score drops, you can see exactly which questions broke, which is how regressions stay traceable. We share the measurement results with you as a report. On critical flows a human stays in the chain: the model proposes, an authorized person accepts. "It seems to be working" is an observation. "We measured this score on this set" is data you can decide on. ##### Cost, latency, and model independence What an AI feature costs to run matters more than what it costs to build, because every request spends money. We start a project by setting a token budget per request and a target latency. Repeated requests and fixed blocks of context are cached, steps that do not need long context are routed to a smaller and cheaper model, and output length is capped. The model call is not buried in the code; behind it sits a provider-independent abstraction, so when a provider raises its price or a better model arrives, the switch happens without rewriting your prompts and workflow. Where the data must not leave your premises, we run an open-weight model on your own infrastructure. ##### Security and data boundaries The first document we write on an AI project is the data boundary document: which fields go to the model, and which never do. Identity numbers, contact details and payment data are either masked before the prompt or never carried at all; the model can do most of the work without them. Under KVKK and GDPR, the purpose of processing, the retention period and the legal basis are defined in writing. When we choose a provider, data residency and the guarantee that your data is not used for training are fixed by contract; where necessary we run the model on your own infrastructure. Every request and every output is written to an audit trail, so it can later be shown when a result was produced, from which input, and with which model version. ##### Where these are already running The work below is either live or completed. Each one has its own page; follow the heading to read the project in full. - **detartech.com:** WebMCP tools, llms.txt, an RFC 9727 API catalog and ai/service.json are live on our own site. The site is open in a way that lets an agent call defined tools instead of scraping the page. We run this surface ourselves before we recommend it. - **[SanalRandevu](https://detartech.com/en/products/sanalrandevu):** llms.txt, robots.txt rules written explicitly for 18 AI crawlers, Organization, WebSite and HowTo structured data, and fast indexing through IndexNow are in place. - **[Lextum AI](https://detartech.com/en/success-stories/lextum-ai):** the first-pass analysis of contracts running to hundreds of pages was automated; risk and compliance points were extracted, and the lawyer's time went to the clauses that mattered. - **[World Summer Schools](https://detartech.com/en/success-stories/world-summer-schools):** raw program data was structured with a language model, summaries and category suggestions were generated, and content went live after human approval. - **[bebekistiyorum.com](https://detartech.com/en/success-stories/bebekistiyorum-ivf-clinic-website):** a content archive of more than 1200 URLs in 4 languages was made visible both in classic search results and in AI answers. #### FAQ **Do you train models from scratch?** No, we work with existing language models. What decides the outcome is not the model itself but the layer built around it: access to the right data, verification of the output, and the work settling into a real flow. If we run into one of the rare cases that genuinely needs training from scratch, we say so plainly and put its cost and timeline down as a separate line item. Most enterprise problems do not need it. **Will our data be used to train models?** No, provider selection and the contract behind it are arranged so that the data you send is not used for model training. Alongside that, the fields that never reach the model at all are defined in writing at the start of the project; identity, contact and payment information is usually masked or never carried. Where data must not leave the country, we run the model on your own infrastructure. **How long does an AI project take and how is it priced?** A PoC typically runs two to four weeks and tests one real scenario on your own data. The duration of the pilot and production stages depends on scope, because the number of integrations and the quality of the data drive the work. Pricing is per stage: each stage has its own price and its own deliverable, and the right to stop at the end of a stage stays with you. **Which model do you use, and can we switch later?** The model is chosen to fit the job and is not hard-wired into the code; the provider call sits behind an abstraction. That makes a change of provider or model version possible without rewriting prompts and workflow. After a change, accuracy is measured again on the same golden set. Where an open-weight model is required, the system is set up to run on your own infrastructure. **How do you measure the accuracy of answers?** We build a golden set out of the real questions your team asks and the answers you accept as correct. Every time a prompt, a model version or a retrieval setting changes, that set runs again automatically, and if the score drops you can see one by one which questions broke. That is how regressions stay traceable. On critical flows a human stays in the chain: the model proposes, an authorized person accepts. **What is WebMCP, and do we need it?** WebMCP is an approach that lets a site offer a visiting AI agent tools it can call directly, instead of text to scrape. It pays off in products where agent traffic does more than read: booking, ordering, lookups, calculations. On a purely promotional site the priority is not WebMCP but llms.txt and correctly structured data. We tell you which one fits by looking at the traffic you already have. **What data do we need for an AI integration?** Because we do not train models from scratch, you do not need a large training dataset; three things are enough. First, the sources the model will rely on: documents, records, a knowledge base, PDFs or scanned paperwork, from which a RAG system builds its answers. Second, a golden set: real questions your team asks every day with their accepted answers, against which accuracy is measured. Third, access: the databases and APIs the system will connect to. Whether fields such as identity, contact and payment details ever reach the model is decided at the start in a written data boundary document. For numerical forecasting work, structured tabular data and classic machine learning are used instead of a language model. **How do we choose a company for AI integration?** Ask for measurement, not a demo: accuracy should be reported as a number on a fixed set built from your own questions and re-measured after every change. Answers should show which document they came from. The provider contract should state that your data is not used for model training, and the fields that never reach the model should be written down. Model calls should not be hard-coded; you should be able to switch providers, and the process should keep working the old way if the LLM layer is switched off. The work should be split into proof of concept, pilot and production, with the right to stop after each phase staying with you. And look for a team that will tell you when a job does not need a language model at all. --- ### SEO - Search Engine Optimization URL: https://detartech.com/en/services/seo Technical SEO is never finished, and any release can break it. We build indexing, hreflang, Core Web Vitals, 301 mapping and measurement as one system. Highlights: - Technical audit covering indexing, crawl budget and redirect chains - Page layout that stops pages competing, plus descriptive internal links - Reciprocal hreflang clusters generated from live page records - Core Web Vitals read from field data rather than a lab score - Address-by-address migration mapping preserved with 301 redirects - Query-level measurement from Search Console reported in one table Technical SEO is never finished in one pass. A site can be built correctly on the day it launches, and three months later a filter generates thousands of URLs, a language version ships with an incomplete declaration, and what the search engine sees has quietly changed. So we do not call the work "improving rankings": we build the system that produces rankings and measure whether each release breaks it. The system has three conditions: the search engine crawls the site fully and indexes the right page, the pages sit in an architecture that supports each other, and the effect of every change is traceable in data. Most claims on this page are open on bebekistiyorum.com and on the detartech.com site you are reading. ##### We define SEO in three layers For us SEO is the work on a site's technical structure, URL architecture and content layout that increases traffic from search results. It has three layers. Access: can Googlebot fetch the page, which page does it index, which URL does it treat as canonical. Meaning: which question does the page answer, and do the headings and internal links say so. Measurement: which page appears for which query, and whether that appearance turns into business. Things we do not do: buying links, building networks of sites, redirecting expired domains, duplicating the same text with the city name swapped. They can produce numbers briefly, but they are the first items to fall in an algorithm update. ##### The six pieces of work in an SEO engagement The six headings below define the scope of an SEO engagement. The order is not arbitrary: content work does not pay off until access problems are solved. The third heading applies only to multilingual sites, the fifth only to sites being moved. ###### Technical audit: indexing, crawl budget and redirects A technical audit answers three questions: which pages are indexed, meaning kept in the search engine's own catalog, which should not have been, and why pages that should be indexed are missing. The distinction that breaks most often: blocking a URL in robots.txt is not the same as a noindex tag, because a blocked page is never fetched, so its noindex tag is never read. On crawl budget, meaning the number of pages a search engine's bot is willing to fetch from your site in a given period, the pattern we find most often is URL multiplication from filter and sort parameters: while one listing sits at dozens of addresses, the crawler reaches the real pages late. On redirects we unwind chains and loops: a two-step redirect looks like it works but adds a needless hop to every click. Its output is a written list reading a Screaming Frog crawl, server logs and the Google Search Console coverage report together. ###### Content architecture and internal linking Content architecture decides which topic is covered on which page and how those pages link to each other. The problem we correct most often is pages competing: when three answer the same question, the search engine cannot decide which to show and all three stay weak. The fix is usually not new content but merging them into one page and redirecting the other two to it. On internal linking the test is simple: how many links point to a page from inside the site, and does their anchor text say what it is about. A page nothing links to is not prioritised, even if the sitemap lists it. We pull the external link profile with Ahrefs and the internal distribution with Screaming Frog, and read both in one table. ###### hreflang management for multilingual publishing hreflang is the tag that declares the language versions of one piece of content to a search engine as counterparts. Three rules are non-negotiable. The link has to be reciprocal: if the Turkish page points at the Russian version, the Russian page has to point back, because a one-way declaration is ignored. Every cluster has to include its own URL, and the URL it points to has to be the indexable canonical version, since hreflang on a redirected or noindexed address invalidates the cluster. It breaks most often on a translation gap: when one language leaves publication, the cluster quietly falls apart. So we build hreflang not as a hand-written list but as an output generated from the live page records. On bebekistiyorum.com the four language versions are declared to search engines with hreflang tags. ###### Core Web Vitals and page experience Core Web Vitals are the three field metrics Google uses for page experience: how long the largest content element takes to paint, the delay between an interaction and the next paint, and the accumulation of layout shift. On the SEO side we clarify two things up front. First, where the data comes from: the assessment looks at field data from the browsers of real visitors, not a lab score taken on one device, so we report from the Core Web Vitals report in Search Console. Second, the limit of the effect: these metrics separate two results of similar strength, they do not carry a barely relevant page to the top. The set that breaks them is narrow: images without declared dimensions, late-loading fonts, an oversized JavaScript bundle and third-party code added after launch. How these metrics relate to architecture is on our [web development page](https://detartech.com/en/services/web-development). ###### Migration and 301 mapping A migration means the URL structure changes: a new platform, a new domain or a new information architecture. The search engine value accumulated over years sits in the address rather than the page, so an old address left without a counterpart takes the value with it. The map is produced in this order: old addresses are collected from the sitemap, server logs and Search Console, each is mapped to a single counterpart in the new structure, and the mapping goes live as a permanent redirect. Redirecting everything to the home page is not a mapping. On [bebekistiyorum.com](https://detartech.com/en/success-stories/bebekistiyorum-ivf-clinic-website), more than 1,200 addresses from the old ASP.NET site were mapped to the new information architecture and preserved with a database-driven 301 redirect layer. ###### Measurement and reporting Measurement comes from three separate sources that should not be mixed. First, the site's own search data: Google Search Console reports, from Google's record, which page was shown for which query, how many clicks it took and its average position; index coverage and crawl statistics sit there too. Second, third-party tools: Ahrefs and its peers give the external link profile and competitor comparison, but their ranking figures are a sample, and because the results page changes with location and device, what we measure is a repeated trend rather than an absolute position. Third, your side: whether an organic session filled in the form. The report gives all three in one table with the changes that shipped in that period. ##### What we protect during a migration When a site moves, rankings are not the only thing at risk; six items come under threat at once. Addresses: each old one is mapped to a counterpart and goes live as a permanent redirect. Internal links: links on the new site point straight at the new address, not at the redirected old one. Language clusters: hreflang links are rebuilt with the new addresses, since a cluster pointing at an old one is invalid. Structured data: JSON-LD markup is regenerated in the new templates, since it does not travel on its own. Sitemap: only indexable canonical addresses remain in the new one. Advertising and measurement: landing pages and conversion tags for paid campaigns are updated, because a working redirect rescues the click but not the measurement. In the bebekistiyorum.com rebuild, Google Ads conversion tracking was integrated into the appointment and contact forms. The first weeks after launch are a monitoring period: the coverage report, 404s in server logs and new redirect chains are read regularly. ##### How we build SEO and GEO together Classic search and answer-generating systems look at the same site with two different questions: Google wants a page to rank, while systems like ChatGPT, Perplexity and AI Overviews want a source to put inside their answer. The common ground is wide: crawlability, correct HTML, a clean sitemap, page speed and content carrying real information are preconditions on both sides. The divergence starts with the unit of work: SEO optimises the page, GEO optimises a single passage. In practice the text under one heading has to do two things at once: state what the page is about, and stay complete when lifted off the page on its own. On sequence our position is firm: access and indexing breakage is cleared before any GEO work begins, because the files produced there rest on the same crawler access. Work aimed at ending up inside answer-engine citations is a separate offering, set out on our [GEO page](https://detartech.com/en/services/geo), with the technical detail in our [GEO guide](https://detartech.com/en/blog/ai-search-engines-geo-guide). ##### The timeline of results Indexing moves comparatively fast: a new page can be crawled and added to the index within days. Ranking moves at a different pace, because the results page varies by location, device and search history; on a competitive query, a change in position depends on the site's history and on what competitors are doing. We cannot control algorithm updates themselves, but after one ships we separate, with data, which page group was affected and how, and prioritise fixes accordingly. Technical work alone does not create demand either; being first for a term nobody searches brings no business, which is why we build the target query list together and read the report as a trend rather than an absolute rank. ##### How an SEO engagement runs An SEO engagement opens with an inventory of how the site currently looks to a search engine: index coverage, crawl logs, redirect structure, hreflang clusters, field data for page speed, and the queries that will be measured. That inventory becomes a written priority order setting the cost of each fix beside its expected effect. The second stage is implementation: redirect rules, template fixes and markup are written straight into the project's own codebase. The third stage is regular follow-up: indexability, redirect and hreflang checks are repeated after every release, because a new page type or a template change can break them. When the contract ends the redirect map, the markup, the target query list and the check list are already in place; there is no dashboard to close. ##### The evidence: one case and this site The first four items come from the rebuild of bebekistiyorum.com, the site of Eurofertil IVF Centre; the fifth is the site you are reading. - **Migration:** More than 1,200 addresses from the old ASP.NET site were mapped to the new information architecture and preserved with a database-driven 301 redirect layer. - **Multilingual publishing:** Turkish, English, Russian and Arabic versions are live; they are declared to search engines with hreflang tags, and for Arabic every component was designed to work right to left. - **Technical SEO foundation:** Page-level dynamic metadata, automatic sitemaps, schema.org structured data and performance work focused on Core Web Vitals. - **Conversion tracking:** Google Ads conversion tracking was integrated into the appointment and contact forms, making the conversion of ad spend into real patient enquiries measurable. - **detartech.com:** Here the URL segments are localised as well, and the hreflang links for four languages are declared reciprocally on every page. #### FAQ **How is SEO work priced, and when do results show?** The audit carries its own price and produces a written priority list ranked by cost; handing the list to your own engineers is a legitimate way to use it. Implementation and regular follow-up run monthly, while content production is priced separately because the effort is independent of the technical work. We do not set the moment results appear: indexing is relatively fast, while a position change on a competitive query depends on the site history. **Do you guarantee first-page rankings for specific keywords?** No. There is no purchasable placement in organic results, the system that produces rankings is not open to outsiders, and the results page changes with location, device and user history. What we do guarantee is technical state and measurement: the list of indexable pages is correct, the redirect map is complete, hreflang clusters are reciprocal, and reporting comes query by query from Search Console. Rank tracking is presented as a trend, not an absolute position. **What gets delivered when the engagement ends?** Every change made lives in the repository you control and on the domain you own: the redirect map, structured data markup, sitemap rules and hreflang generation. Alongside them we hand over the target query list, the check list to repeat after every release, and the measurement table. Nothing of ours keeps running behind the work, so there is nothing to switch off that could move your rankings or your measurement. **Who protects this after the site goes live?** Technical SEO is never finished in one pass; a new page type, a new filter or a template change can break indexability and redirects. That is why we attach the checks to the release flow rather than to a monthly report: indexability, redirect and hreflang checks are repeated after every release. Your own team can run these checks as well, which is why the check list is handed over in writing. **In what case would we say you do not need SEO work?** When demand for the business does not come from search. In a company whose sales come entirely from a field team, a dealer network or closed tenders, organic search stays a small channel and the budget pays back better on the advertising or sales side. The same holds for a brochure site of a few pages: what is needed there is correct metadata and a working sitemap, not an SEO programme. **With AI search growing, does classic SEO still make sense?** Classic search and AI search rest on the same technical foundation: a page a crawler cannot reach is neither ranked by Google nor picked as a source by an answer engine. What changes is measurement: because an answer can satisfy the user without a click, session count alone is no longer sufficient, so we read impression and query data separately. Turning up inside the citations of an answer engine falls under the GEO service. --- ### GEO - Generative Engine Optimization URL: https://detartech.com/en/services/geo AI engines do not rank, they select sources. We make your site citable with llms.txt, structured data, E-E-A-T, a written crawler policy and WebMCP. Highlights: - llms.txt, machine-readable endpoints and honest sitemap hygiene - Schema.org structured data that matches the visible page exactly - E-E-A-T signals built on author identity, sources and dates - A purpose-based robots.txt access policy for AI crawlers - Passage architecture written to be quoted on its own - Four-layer measurement: crawling, citation, referral and conversion AI engines do not rank pages. When they answer a question they choose which sources to read, blend sentences from them into an answer of their own, and often put a few links underneath. The target is therefore not "position three" but being one of the sources named inside that answer. The conditions differ from classic ranking: the model has to find the page, understand what it is about without guessing, and still be correct when it lifts a single paragraph out of its surroundings. Detartech's GEO work is building those three conditions into a site one by one. We did the same on our own site, so most claims on this page can be opened and checked on detartech.com. ##### How we define GEO GEO stands for generative engine optimization: making a site usable as a source by answer engines such as ChatGPT, Perplexity and Google AI Overviews. The work has two layers. The first is machine readability: the model and its crawler find the site, can tell what each page is, and never have to guess while parsing content. The second is citability: a paragraph stays correct, complete and attributable once it is pulled off the page. There are things we do not do: hidden instructions for the model, text visitors cannot see, invented authors and dates. Those violate search guidelines and are the fastest way to lose the trust signal you were building. For how answer engines work and the technical roadmap, see our [GEO guide](https://detartech.com/en/blog/ai-search-engines-geo-guide). ##### How we open a site to AI engines The six headings below cover everything a GEO engagement contains. The first two are discovery and meaning: machine-readable files that let the model find the site, and structured data that removes ambiguity about what a page is. The third is who the source is, the fourth is which crawler may enter and why. The fifth is the text itself: whether a passage can be quoted on its own. The sixth goes past reading, giving agents that act on the site tools they can call directly. Most projects start with the first five. ###### llms.txt and a machine-readable site map llms.txt is a markdown index at the root of a site that tells a model which addresses to look at while reading it. What goes inside is not a copy of the navigation menu but addresses that genuinely exist, each with one line saying what it is; one address that does not resolve makes the whole file untrustworthy. The same layer carries JSON endpoints such as a service list, an FAQ file and an API catalog, where a machine gets an answer without parsing a page written for humans. The sitemap error we correct most often is fake freshness, where every page gets today's lastmod on every deploy; that empties the date information across the site within weeks. Rather than wait for a changed page to be crawled, we announce it through IndexNow. ###### Schema.org structured data Structured data is the JSON-LD block that tells a machine what a page is. We use Organization for company information, WebSite across the site, Article on blog posts, HowTo on step-by-step instructions, FAQPage on question and answer blocks and BreadcrumbList on navigation paths. The part nobody sees is entity disambiguation: unless the company name, address and outside profiles are tied together with sameAs, a model may read them as two separate entities. One rule is not negotiable: the schema has to match the text visible on the page. Marking up questions that do not appear on the page buys a penalty, not visibility. Every schema goes through a validator before it goes live, because a single malformed field can stop the whole block from being read. ###### E-E-A-T signals E-E-A-T stands for experience, expertise, authoritativeness and trustworthiness, the signals search systems weigh when judging whether content can be trusted. Answer engines apply a similar logic and look at who said a sentence before they quote it. So an author page points to a real person, their real expertise and a way to reach them; publication and update dates are honest; and when a claim rests on an outside source, that source is named in the text. On the company side the legal name, address and contact details are kept identical on every page, because a name spelled differently in different places weakens the identity signal. Part of this heading is not our work but yours: without real authors, real experience and verifiable cases, these signals cannot be manufactured. ###### AI crawler access policy and robots.txt Here robots.txt is a commercial decision, not a technical detail: which crawler may enter your site, and for what. Three groups have to be separated: crawlers collecting content for model training, crawlers feeding a search index, and crawlers fetching a page on a user's behalf the moment they ask. Closing the training crawler while leaving the answer-time crawler open is a coherent position; closing all three also closes your chance of appearing in answers. We put the decision in writing and spell the rules out crawler by crawler, because a policy left to a wildcard makes it arguable later who was allowed what. And robots.txt is not always the file you wrote: managed blocks inserted by a CDN can sit above your own rules, so we verify the policy from the live file, not the repository. ###### Citable passage architecture An answer engine does not take a page whole; it lifts one section out of it. Every block under a heading therefore has to stand on its own: the answer in the first sentence, the definition before the elaboration, a number in the same sentence as its unit and date, and no backward references of the "as explained above" kind. The test is simple: cut the paragraph out of the page and read it alone. Is it still correct and understandable? If not, it will never end up inside an answer. The FAQ block follows the same logic, using the question a buyer actually asks rather than a decorative marketing one. This page itself was built to that rule. ###### WebMCP and agents that use the site Agents no longer only read sites, they act on them. WebMCP is the approach in which a site offers a visiting agent callable tools instead of text to be parsed. On our own site those tools are not declared a second time by hand: the browser agent takes the tool list from the site's own MCP endpoint, so the two surfaces cannot drift. Every registered tool is read-only, and the contact and quote forms stay exposed as declarative form tools, which keeps a human in front of the form before submission. An RFC 9727 API catalog separately tells machines which interfaces exist. To be honest, WebMCP today runs only in Chrome and only as a trial; we do not sell it as a traffic promise but as a layer that builds tomorrow's interface today. Details are in our [WebMCP article](https://detartech.com/en/blog/webmcp-agentic-browsing-seo-geo). ##### How GEO differs from SEO and where they overlap SEO competes for a place in a list of ten blue links; GEO competes to be one of the few sources a model reads while composing an answer. The overlap is wider than people assume: crawlability, page speed, correct HTML, a clean sitemap, sane internal linking and content that carries actual information are shared ground. A site Googlebot cannot see is largely invisible to AI crawlers too, so we do not sell GEO as a replacement for SEO. Divergence starts in two places. The unit: SEO optimizes a page, GEO optimizes a passage, so the decisive factor is not keyword density but whether one paragraph is complete on its own. The outcome: an AI answer can satisfy a user without a click, so session count alone stops being a measure of success. Technical work and content architecture on the classic search side are a separate service, described on our [SEO page](https://detartech.com/en/services/seo). ##### How we measure visibility We split measurement into four layers. Crawling: server and CDN logs show which AI crawler fetched which addresses, how often and with what status code, which is a record rather than an estimate. Citation: a fixed list of questions specific to your business is run against answer engines at set intervals, and we record whether the brand appears and whether it was linked. Referral: traffic arriving from answer engines is tracked as its own segment in analytics. Conversion: we track whether those sessions filled a form or asked for a quote. We state the limit of the second layer up front: answers vary by user, session, region and model version, so what we measure is not a rank but a trend read across repeated runs. How the dashboard is built and which indicators we follow is in our [article on measuring AI visibility](https://detartech.com/en/blog/measuring-ai-visibility-geo-kpis-and-monitoring-dashboard). ##### The factors that determine the outcome An answer engine's response to the same question is not fixed: it varies by user, session, region and the model version running at that moment. A change can reach the crawlers that fetch a page at answer time within days; the same change entering the trained model itself depends on that model's release cycle. Because of this variability, we treat measurement as a recurring exercise rather than a one-off check: a fixed question list runs on a schedule, and the result reads as a trend across repeated runs rather than a single snapshot. Markup does not change this mechanic either, it only makes it easier for the model to read information that is already there; if a paragraph carries nothing that twenty other pages do not, no schema makes it citable on its own. ##### How a GEO engagement runs The work starts with an audit of what is actually live: robots.txt, the sitemap, llms.txt, whether the schemas validate, whether we can reach crawler logs, and which questions will be measured. The output is a written list ordered by cost and impact, deliverable on its own. Implementation comes second: files and markup go into your repository and onto your own domain, not into an intermediary on our servers. We run in two-week cycles, each ending with the changes that went live reported alongside the measurement result. Measurement comes third: a baseline before implementation, the same question list repeated afterwards. Nothing switches off when the engagement ends. llms.txt, the schemas and the robots rules stay on your site, and the question list and measurement sheet are handed over. ##### What can be verified from outside Every item below is live right now and can be verified from outside. - **detartech.com, machine-readable layer:** llms.txt, an RFC 9727 API catalog, ai/service.json and .well-known/ai.txt are published. The same page is also returned as markdown rather than HTML to a client that asks for it. - **detartech.com, agent interface:** WebMCP tools are registered from the tool list of the site's own MCP endpoint and are all read-only. The contact and quote forms are exposed as declarative form tools, so a human stays in front of the form before submission. - **[SanalRandevu](https://detartech.com/en/products/sanalrandevu):** llms.txt, robots.txt rules naming 18 AI crawlers one by one, Organization, WebSite and HowTo structured data, and fast indexing through IndexNow are all published. - **[bebekistiyorum.com](https://detartech.com/en/success-stories/bebekistiyorum-ivf-clinic-website):** a content archive of more than 1200 URLs in 4 languages was optimized for AI-assisted search such as ChatGPT and Perplexity alongside classic search. #### FAQ **How long does GEO work take and how is it priced?** The audit is priced as a separate item and ends with a written list ordered by cost, and you are free to hand that list to your own team. Implementation runs in two-week cycles, each with its own price. Measurement has to be continuous, because a single run tells you nothing about a trend. When the result becomes visible is not something we control. **Do you guarantee that we will appear in ChatGPT or Perplexity answers?** No, we cannot guarantee it. These systems have no placement you can buy and no table that hands out positions, and the same question can produce two different answers for two users. What we do guarantee is a technical state and a measurement: files live and passing validation, a written access policy, readable crawler logs and a fixed question list running on a schedule. We report on that measurement, not on impressions. **What gets delivered when the work ends?** Every file sits in your repository and on your own domain: llms.txt, structured data, robots rules and machine-readable endpoints. Along with them you receive the question list used for measurement, the measurement sheet and a handover note explaining how to read crawler logs. There is no intermediary running on our servers that leaves you in the dark once it is switched off. **We already do SEO. Do we need GEO separately?** Crawlability, speed, correct HTML and a clean sitemap are shared ground, so if the SEO side is in order the foundation is already there. What GEO adds is this: llms.txt and machine-readable endpoints, schema that matches the page exactly, passages that can be quoted on their own, and a written crawler access policy. If Googlebot cannot see the site at all, the classic search side is fixed first. **Could we just block AI crawlers entirely?** You can, it is a legitimate decision, but it has a cost. A crawler collecting content for model training, a crawler feeding a search index and a crawler opening your page on a user's behalf the moment they ask a question are not the same thing. Blocking the last means staying out of the answers that would have linked to you. We separate the three groups and put the decision in writing; whichever way it goes, robots.txt is written out crawler by crawler. **Do we need WebMCP?** It matters on products where an agent can do something beyond reading: booking, ordering, lookups, calculations. On a purely promotional site the priority is llms.txt, correct structured data and passage architecture. WebMCP also runs only in Chrome and only as a trial today, which is why we do not present it as a traffic promise. We built it on our own site and watch how it behaves from there. --- ### RevOps - Ads and CRM Integration URL: https://detartech.com/en/services/revops We move Meta and LinkedIn leads into your CRM and feed the sales outcome back through the Conversions API. Self-hosted setup, monthly EMQ and conversion report. Highlights: - A lead line from Meta Lead Ads, LinkedIn and site forms into the CRM within seconds - Qualified, disqualified and won-sale signals fed back through the Conversions API - Identity fields hashed with SHA-256 and an Event Match Quality score tracked in production - Deduplication and scheduled backfill as a safety net against missed webhooks - Self-hosted installation on your own server with no per-transaction licence fee - Monthly report on EMQ, event volume and the lead-to-sale conversion rate Left to their defaults, lead campaigns optimise for everyone who fills in the form and never find out whether that person became a customer. The sales team's verdict that a lead was not worth calling stays inside the CRM, so the algorithm keeps optimising against its only signal: form submission behaviour. RevOps (Revenue Operations) is the discipline that joins marketing, sales and data infrastructure into a single revenue line. At Detartech we build it in three parts: leads moving from the ad platforms into the CRM without loss, sales outcomes flowing back, and the whole funnel reported in numbers you can check. We closed this loop on our own ad account first; that architecture is now the core of our RevOps service. ##### The definition of a two-way data pipeline RevOps here means building and running the two-way data line between the ad platform and the CRM. The first direction runs from the ad to the CRM: the moment a user submits the form, the platform's webhook, an automatic notification triggered by that submission, fires; the automation layer pulls the lead detail from the API, and the contact and lead records appear in your CRM within seconds. The second runs from the CRM back to the ad: when a salesperson marks a lead qualified or disqualified, or when a deal is won or lost, that change goes back to the ad platform as an event. The core sits in one field: the lead ID must never be lost, because it is the primary matching key for the feedback. This is neither a CRM implementation project nor a media buying service, but a data layer built on the CRM and campaigns you already run. We published the step-by-step roadmap for it, with the event mapping table and the most common mistakes, in our [Meta and CRM feedback loop guide](https://detartech.com/en/blog/meta-crm-feedback-loop-guide). ##### The parts we build the revenue line from The six headings below cover everything a RevOps setup involves: where the lead is captured, where it is carried into the CRM, where the sales outcome returns to the ad platform, the match quality that makes the feedback worth anything, the safety net against missed and duplicated records, and where the line runs and who holds the data. ###### Lead capture: Meta Lead Ads, LinkedIn and site forms Leads enter the same pipeline from three sources rather than an inbox or a spreadsheet: Meta Lead Ads instant forms, LinkedIn Lead Gen Forms, and the contact, quote and appointment forms on your site. On Meta's side, the webhook carries the lead ID rather than the lead itself; the name, email, phone number and form answers are pulled separately from Meta's API. All three connect to one line for a reason: if organic and paid demand do not appear in the same table, you cannot compare which channel brings customers. The technical work on the organic side is a separate service, described on our [SEO page](https://detartech.com/en/services/seo). ###### Real-time flow into the CRM The lead appears as a contact and a lead record in your CRM within seconds of submission; Pipedrive and HubSpot are typical examples, and field names differ while the logic stays the same. Four custom fields sit on the record: lead ID, ad ID, campaign ID and form ID. These are not report decoration but the operating condition of the feedback: a lead typed in by hand carries no lead ID and drops out of the loop. On the funnel side you define an entry point for raw leads and a set of ordered stages, and the qualified and disqualified distinction is set up to produce a trackable field change in the CRM, since that change fires the webhook. ###### Feedback through the Conversions API When a salesperson marks a lead qualified or disqualified, when a deal is opened, or when a deal is won or lost, the CRM webhook fires and that signal goes to the ad platform through the Meta Conversions API and the LinkedIn Conversions API, both of which let you send events directly from a server rather than a browser, carrying identity fields hashed with SHA-256\. Event names are kept short, space-free and ASCII: crm\_lead, qualified, disqualified, converted. The won-sale event carries a value and a currency so the platform can report on revenue, and the event is flagged as coming from the CRM. One rule is worth knowing: Meta has no mechanism for deleting or reversing an event. If a wrong signal has gone out, the correction is to send the person's current state as a new event, because Meta treats the latest event as valid. The event mapping is therefore agreed in writing during setup, not tried out in production. The same feedback loop extends to ChatGPT Ads. Its only ad format is the chat\_card, a sponsored card shown beneath the answer, and there is no in-platform form like Meta's or LinkedIn's. Your site is therefore the lead capture point: the user arrives from the card, and the form, booking or purchase conversion is sent from the server to OpenAI's Conversions API with the same SHA-256 hashing and event naming discipline. A session or click ID replaces the lead ID as the matching key. How the platform reached Türkiye and how to advertise on it is covered in [our ChatGPT Ads guide](https://detartech.com/en/blog/chatgpt-ads-turkiye-openai-advertising-guide). ###### Attribution and Event Match Quality Event Match Quality scores how likely an event you send is to match a real person on the ad platform, and it decides what the feedback is worth. Events sent with nothing but an IP address and a user agent are of little practical use; the score rises noticeably once a hashed email, phone number and lead ID are included. Field hygiene in the CRM is therefore attribution itself, not a technical detail: a record with a malformed phone number produces an event that never matches. The second decision is the signal pool: we send CRM events to the main pixel your web events already flow into rather than to a separate dataset, because splitting the signal across two pools slows the platform's learning. ###### Data quality, deduplication and backfill Webhooks get missed when a server restarts, a retry window closes or the platform fails briefly, so two protective layers are built into the line. The first is deduplication: every event is given a deterministic event ID, so repeated sends are not counted twice and the report does not inflate. The second is backfill: a scheduled flow running every few hours scans the latest leads on the platform and pulls in the ones with no counterpart in the CRM. Two limits shape that safety net: Meta keeps lead data for 90 days and you cannot go back further, and the Conversions API rejects an event time older than 7 days, so delayed sends have their event time updated. ###### Self-hosted setup and data ownership The automation layer runs on your own server. Subscription bridge tools such as Zapier, Make and LeadsBridge exist for this job; we use the MIT-licensed Activepieces Community Edition, because a self-hosted installation has no flow or task limit and no per-transaction tool licence. On the Meta side, access runs through a system user, a dedicated account created only for the integration, with a never-expiring token rather than a personal account, because personal tokens die quietly after roughly 60 days and are the most common cause of outages in integrations of this kind. If we also set up the server, backups and update flow, that part connects to the [DevOps and CI/CD](https://detartech.com/en/services/devops-ci-cd) side. ##### The difference a closed loop makes Once the sales outcome goes back to the ad platform, the algorithm learns the profile of the customer, not of the form filler. The first is reporting: you add qualified and sold columns to Ads Manager and see, ad by ad, which campaign brought customers. The second is audiences: custom and lookalike audiences are built from the qualified and converted events, so targeting is modelled on buyers rather than form fillers. The third is the optimisation goal: past the volume threshold, switching to Meta's Conversion Leads optimisation is a single step. Meta's guidance for that switch is roughly 250 leads a month and a conversion rate between 1 and 40 percent at the target stage. Below the threshold it still makes sense: the quality report arrives from day one, audiences accumulate, and the switch is ready when volume grows. ##### Where the lead data sits Lead data is personal data, and its route is an architectural decision. With a subscription bridge tool, the lead's name, phone number and email, along with your ad account access tokens, pass through a third-party SaaS provider's servers. On our line they do not: the automation layer runs on your server, and the data moves between the ad platform, your server and your CRM. KVKK and GDPR compliance is part of the architecture for that reason, not a clause added afterwards. The privacy notice and consent side remain yours; what we build is the data's route, documented in a written field mapping table you keep. ##### What our reporting covers The monthly report rests on three numbers, all read from places you can verify. The first is the Event Match Quality score. The second is event volume: how many times crm\_lead, qualified, disqualified and converted were sent, and from which source. The third is the lead-to-sale conversion rate: how many leads landing in the CRM were marked qualified and how many became won deals. Where each number is read from in Events Manager or in your CRM is written in the report, so you can check it without us. We also say up front what this does not measure: it does not improve the sales conversation, it carries that conversation's outcome to the ad platform. ##### How a RevOps setup proceeds The work starts with an audit: the pixel and dataset structure, server-side event quality, the CRM pipeline and field architecture, and the points where lead IDs are lost. Its output is a written list that can also be delivered on its own. The second stage is the foundation: a Business-type app and the Webhooks product on the Meta side, then a system user with a never-expiring token. In the same stage, matching fields for Meta and LinkedIn are created in the CRM, webhook subscriptions defined, and funnel stages mapped to events. The third is implementation: real-time lead flow, the qualified, disqualified and converted events fired from CRM webhooks, deduplication and scheduled backfill. The fourth is verification: test events confirm all four events on screen, the conversion funnel is ordered in Events Manager, and the system goes live. Monthly maintenance follows: token and webhook health is monitored, and event mappings are updated as your sales process changes. Google Enhanced Conversions and the TikTok Events API can be added to the same infrastructure later. ##### What's verifiable and what we report ourselves Two of the items below are pages you can open and check directly; the other two are things we report about our own setup. - **Detartech's own ad account:** leads land in the CRM automatically, and the sales team's qualified and disqualified decisions, along with closed sales, go back to Meta through the Conversions API. - **A published setup guide:** the step-by-step account of this architecture, the table mapping each CRM trigger to a Meta event, and the five most common mistakes are open on our blog. - [**bebekistiyorum.com**](https://detartech.com/en/success-stories/bebekistiyorum-ivf-clinic-website)**:** Google Ads conversion tracking was integrated into the appointment and contact forms, making the conversion of ad spend into real patient enquiries measurable. - **The self-hosted automation layer:** the setup runs on the MIT-licensed Activepieces Community Edition, there is no per-transaction licence fee, and lead data does not pass through a third-party SaaS provider. #### FAQ **How long does the setup take and how is it priced?** The audit is priced as a separate item and ends with a written list you may choose to implement with your own team. What sets the duration is access rather than code: if Business Manager permissions, a CRM administrator account and server access are ready, the work moves quickly. Monthly maintenance is priced separately, because watching token and webhook health has to be continuous. **In what situations would this service be unnecessary?** If you do not run lead ads, or if no CRM records the sales outcome, there is no signal to feed back and the funnel inside the CRM is arranged first. Where the sales cycle is very short and the conversion already completes on the site, a standard pixel setup is usually enough. This work pays off when the decision is made by a sales team the ad platform cannot see. **Do you guarantee that our ad costs will fall?** No. The setup gives the ad algorithm a more accurate signal; it does not lower a budget by itself, and the outcome depends on how your sales team defines a qualified lead. What we do guarantee is visibility: you see, ad by ad, which campaign brings qualified leads. The decision on where to shift budget stays with you, and the effect of that decision is read in the monthly report. **What gets delivered when the work ends?** The automation flows stay on your server, the custom fields and the accumulated lead history stay in your CRM, and the system user and tokens stay in your own Business Manager account. Alongside those you receive the written mapping table showing which CRM change fires which event. There is no intermediary on our servers whose shutdown would cut the line, so the system can be handed to another team. **Why self-host when Zapier or LeadsBridge already exist?** Two differences. The first is cost: subscription bridge tools charge per transaction, while a self-hosted installation has no flow or task limit, so the cost curve does not break as volume grows. The second is the data route: with a bridge tool, the lead name, phone number and your access tokens pass through a third-party SaaS provider. In a self-hosted setup they do not, which matters under KVKK and GDPR. **Our CRM is neither Pipedrive nor HubSpot. Can this still be built?** The condition is capability rather than brand: the CRM has to be able to send webhooks and to allow custom field definitions. With those two in place the logic is the same and only field names and trigger naming change. A CRM without webhook support can be worked with through scheduled polling, but the feedback is then not real time and we write that down at the proposal stage. --- ### DevOps & CI/CD URL: https://detartech.com/en/services/devops-ci-cd The point of CI/CD is safe rollback, not speed. Pipeline anatomy, environment and secret management, containers, observability and written handover. Highlights: - The rollback step written before the deploy step - The exact image that was tested is the one released - Configuration and secrets separated per environment - Logs, metrics and alerts that actually demand action - Infrastructure written as code and kept under version control - A pipeline running in your accounts and a written handover The value of a release pipeline is not measured by how fast you can ship. It is measured by how many minutes it takes to get back when a bad version reaches production. A pipeline you cannot reverse is not automation; it is a mechanism that spreads mistakes faster. That is why the first step we write into every pipeline is not deployment but rollback: which command, whose permission, and how you return to the previous version without touching database migrations. A team without a written answer to that question accumulates risk as it increases release frequency. The sections below cover the parts of a pipeline, environment and secret management, the container side, observability, and how the pipeline is operated after handover. ##### The point of CI/CD is safe rollback, not speed CI/CD, short for continuous integration and continuous delivery, describes the system that tests code changes automatically and ships them to production; but this automation does not lower the error rate, it only changes what an error costs, because the same mistake happens in a system deployed by hand and the real difference shows up in what can be done afterwards. Three questions decide whether a pipeline is worth anything: can the application version return to the previous image with one command, is the database change written so it can be reversed, and on release channels that cannot be rolled back, such as mobile, can the feature be switched off behind a flag. The three answers are not the same. An application version comes back in minutes. A migration that drops a column does not, which is why the schema is widened first and narrowed in a second, later step. A mobile build published to a store is not rolled back at all, so it ships behind a switch. Lextum AI is the product-side version of the same principle: every document change on the platform is recorded so it can be traced and reversed, and who changed what and when stays visible. What we expect from infrastructure is no different. ##### What a release pipeline is made of The six headings below cover every decision made while a release pipeline is built. The first three are the pipeline itself: the steps that run from build to deploy, how environments are kept apart, and the package format the application travels in. The next two are what surrounds the pipeline: the measurement layer that shows what happened after a release, and who is allowed to reach what. The sixth is where the other five are tested, meaning what actually happens when things go wrong. ###### Pipeline anatomy: build, test, image, deploy A release pipeline has four steps, and every step holds the right to stop the rest. The build step proves the code stands up in a shared environment, not on one developer's laptop. If the test step is red, nothing moves forward; a test that can be skipped is a test that does not exist. The image step turns the output into a single versioned package, so what was tested and what goes live are the same artifact. The deploy step carries that package to a target environment. This separation is the backbone: once package and environment are split, the same image runs through test, staging and production in order, with no rebuild per environment. ###### Environment management and configuration The difference between environments belongs in configuration, never in code. The application reads which database to connect to, which service address to call and which feature is on from environment variables. A branch inside the code that checks the environment name is a path that will run for the first time in production. We set up at least two environments: a staging environment that matches production in schema and migrations, and production itself. Staging differs from production only in data and scale. Configuration is versioned like code, because the cause of an incident is more often an unrecorded setting change than a code change. ###### Containers and orchestration Containers exist to retire the sentence "it worked on my machine". Application, runtime and dependencies merge into one image, and that image opens the same way on a developer laptop and on a production server. Orchestration is a separate decision and is not required on every project. For a single-service application with predictable traffic, Kubernetes adds more operational weight than it returns. It earns its place when several services scale independently, deploys must happen without downtime, and automatic recovery is expected. If the real problem is load rather than the pipeline, the work moves to [Backend Scaling](https://detartech.com/en/services/backend-scaling), where architecture, data access and caching are the subject. ###### Observability: logs, metrics, alerts "Looks fine" is not a measurement after a release. We build three layers: structured logs, error and latency metrics, and alerts that actually reach a person once a threshold is crossed. If an alert reaches no one, the dashboard is decoration. Marking each release in the same data belongs to this layer too. When the error rate climbs, the first question is which version it started after, and if the answer is not visible on the chart, the search stretches into hours. We keep alert thresholds few and set them where they demand action, because an alert that fires constantly gets muted. ###### Secret management and access A key that has entered the repository stays in the history even after the line is deleted, so the only correct move is to revoke it and issue a new one. Database passwords, payment provider keys and cloud credentials live in a secret store the pipeline reads, not in the code repository, and they are separated per environment: a staging key must not reach production data. Permission to deploy to production is assigned by name and leaves a record. The goal is not to reduce the number of people who can deploy, but to make it readable later who deployed and when. ###### Rollback and incident response Rollback is not a plan written during an incident. It is an ordinary step of the pipeline and it is exercised outside incidents too. The previous image is kept ready, the deploy command takes a version parameter, and going back is a single action. The database side is treated separately: migrations are written with both a forward and a backward direction, and steps that destroy data are deferred to their own release. During an incident the order is fixed: roll back first, look for the cause second. The reverse order is the expensive one, because diagnosis on a broken system is slow and made under pressure. A short written record afterwards is the only thing that stops the same failure returning for the same reason. ##### How release frequency relates to fragility Releasing often does not make a system fragile. Releasing big does. What sets the risk is not the number of deploys but the size of the change that travels at once. When a release that accumulated for weeks breaks, nobody knows which change broke it, and rolling back also removes dozens of things that worked. With small and frequent releases, what gets reverted is obvious. The precondition is that deploying stops being an event; if a team has to gather for every release, frequency was never available. This matters most in systems that cannot afford downtime. Anneekspres is a marketplace: buyers place orders while sellers update stock, so a planned maintenance window is not a luxury that exists. The project was built with a RabbitMQ message queue, PostgreSQL for data management and Jenkins pipelines, and high availability and fast deployment come out of that same structure. ##### The benefits of managing infrastructure as code A server built by hand becomes an undocumented system the day the person who built it leaves. Writing infrastructure as code moves the answer to "what is on this server" out of human memory and into the repository. With tools such as Terraform, server, network, security group and database definitions get versioned; a change is reviewed as text first and applied second. The gain shows up in three places. First, repeatability: standing up a second environment drops from a week of work to a single command. Second, auditability: when a setting changed and why stays in the record. Third, the disaster case: "if the server is wiped, how many hours until it is back" gets a measured answer instead of a guess. The only way to confirm all three is to build the infrastructure from nothing at least once. ##### Handover: how you operate the pipeline A release pipeline is yours only if it runs in your accounts. The repository, cloud account, domain and secret store are opened in your name; we take access, not ownership. Four things are delivered in writing at handover: what the pipeline does step by step, how a new developer goes from a clean machine to a release, what the rollback command is, and who holds deploy permission for which environment. The on-call side is added to that: which alert reaches whom, and what is done in the first twenty minutes. Documents alone are not enough, so before handover we run at least one real release and one real rollback together with your team. We wrote about the engineering approach of working close to the customer's own systems in our [Forward Deployed Engineer article](https://detartech.com/en/blog/what-is-a-forward-deployed-engineer); handover follows the same logic. ##### Our tool selection criteria Tooling is chosen by where the project already lives, not by habit. If the code sits on GitHub and nobody wants to operate a separate runner machine, GitHub Actions is the shortest route. For pipelines that run on your own server, take a long time, or contain custom steps, Jenkins remains a reasonable choice: in six of the nine references attached to this service, CI/CD was built with Jenkins and the server side runs on Ubuntu. In the remaining three the technology list is different, because we do not copy the same pipeline everywhere. Docker removes the gap between environments and becomes the default once containerisation is decided. Kubernetes and Azure depend on justification: several services, independent scaling, or a corporate cloud policy. Where the system is hosted is your decision rather than ours; the managed SaaS infrastructure of Lextum AI was built on AWS, while other projects went elsewhere. ##### How this has worked in practice The work below is live or completed. The detail of each one sits on its own page in the Success Stories section. - **[Lextum AI](https://detartech.com/en/success-stories/lextum-ai):** Microservice architecture with asynchronous processing over RabbitMQ; a Next.js interface, .NET services and a managed SaaS infrastructure on AWS, with CI/CD automation on Jenkins. The structure is ready for high-traffic enterprise use. - **[Anneekspres](https://detartech.com/en/success-stories/anneekspres):** Marketplace infrastructure built with a RabbitMQ message queue, PostgreSQL for data management and Jenkins pipelines, delivering high availability and fast deployment. - **[Biletico](https://detartech.com/en/success-stories/biletico):** Redis caching on a Next.js and Node.js stack, with CI/CD automation on Jenkins pipelines; every update is tested before it goes live. - **[Welldone](https://detartech.com/en/success-stories/welldone):** A Flutter mobile application, a React management panel and .NET services, on scalable Ubuntu-based server infrastructure with CI/CD automation on Jenkins. The whole operation from order to shipment runs on one platform. - **[World Summer Schools](https://detartech.com/en/success-stories/world-summer-schools):** Cloud-based scalable infrastructure on a Next.js, .NET and PostgreSQL stack, with CI/CD automation on Jenkins. The infrastructure is ready for growing program and user volume. - **[BiTalih](https://detartech.com/en/success-stories/bitalih):** A content production platform running on Next.js and MongoDB, with release infrastructure on Jenkins and Ubuntu. #### FAQ **How long does a CI/CD setup take and how is it priced?** Four things set the duration and the price: how many services will be released, how many environments are needed, whether database migrations are involved, and whether there is a channel that cannot be rolled back, such as mobile. Pricing follows that scope rather than an hourly rate. The first delivery is always the same, a written release and rollback path, and the rest is built on top of it. **Do the pipeline and the infrastructure stay with us?** Yes. The repository, cloud account, domain and secret store are opened in your name; we take access, not ownership. Because the pipeline runs in your accounts, handover never turns into a separate migration project. At handover you receive, in writing, what the pipeline does, how to go from a clean machine to a release, the rollback command, and who holds deploy permission for which environment. **If the work stops halfway, is what's been done still usable?** Yes, the setup is delivered in pieces, so unfinished work stays usable. Since the release and rollback path is the first thing built, you hold a working pipeline even if none of the later steps are done. Everything lives in your accounts, so you do not need to request a separate handover from us to keep using it. **Who operates the pipeline and who carries the on-call duty?** All three arrangements work: your team operates it, we operate it, or on-call is shared. The alert list in the handover document drives the decision, since it states which alert reaches whom and what is done in the first twenty minutes. Before handover we run one real release and one real rollback together with your team, so the choice is not made on assumption. **Does every project need a CI/CD pipeline?** No, we say this plainly: if you run a single static site and release once a month, a dedicated pipeline returns little. If the product is not validated yet and has no users, Kubernetes with multiple environments is a cost taken too early. In those cases we suggest a small deploy script and a written backup plan; the full pipeline is built when release frequency rises. **Can this be set up without disturbing the running system?** It can. The new pipeline starts as a dry run that deploys nothing to production, and releases the same version to a staging environment matching the production schema. The switch to production happens only after the rollback command has been exercised at least once. The existing manual release path stays open until the new pipeline has run cleanly through a full release. --- ### CTO as a Service URL: https://detartech.com/en/services/cto-as-a-service CTO as a Service (fractional CTO): tech leadership without a full-time hire. Architecture decision records, tech debt inventory, vendor and team evaluation. Highlights: - Irreversible decisions separated out and written before they are made - One page per decision: options, reasoning and reversal condition - Account, repository and domain ownership staying with you - Technical, knowledge and intent debt inventoried separately - Engineers evaluated on reading code rather than writing it - The exit defined upfront: decision record and handover package The cost of a technical leadership gap is not bad code. Bad code is expensive but reversible; the real cost sits in decisions nobody recognised as decisions at the time and cannot be undone later. Which country the data sits in. Whose name the cloud account was opened under. None reach an agenda under the heading "decision", most pass quietly inside a sprint, and two years later they determine what the company can do. The work here is not writing code but getting in front of those decisions: separating the irreversible ones, writing them down with the reasoning, and leaving the record with you. ##### Role definition and fit criteria It means making, justifying and recording technical decisions without employing a full-time technical executive. The boundary is drawn at the start: we do not become an officer with signing authority, nor the legal manager of your engineers. There is a threshold beyond which a full-time CTO is right: once a new question touching architecture arrives every week, an outside role cannot keep up. This service is built for companies where decisions arrive in bursts, with implementation and measurement between them. One observation from the work itself: in the Tegoly, Finteo and Terazzi engagements the advisory side never ran on its own. Each of them also delivered changes to the running product, from new screens and modules to backend and performance work. Advisory here is not detached from execution. ##### What the work covers The six headings below cover everything inside an engagement. The first two are the ground: where the system stands today, and decisions recorded with their reasoning. The next two are choices: which technology and vendor, and who joins the team. The fifth inventories accumulated debt; the sixth translates it into language an investor or board can read. ###### Technical due diligence and current-state assessment The assessment starts from the running system, not a document: first it checks whether the project comes up from scratch on a clean machine, since a setup that only runs on a handful of laptops is effectively unproven. From there it looks at whose name the repository, cloud, domain, DNS, app store and payment provider accounts are opened under, along with how code reaches production, who can push it, and whether the rollback step is written down. Asking whether backups are taken is not enough; has a restore ever been attempted, because an untested backup is unproven. It also checks whether secrets sit in the repository, which runtime has lost support, and which part can only be touched by one person. The output is a written list ordered by cost and impact. ###### Architecture decision records and justification Every decision fits on one page: the question answered, the options considered, the path chosen, the reasoning, and the condition that would justify reopening it. That last item is most often skipped, and without it a decision hardens into a habit nobody argues with. The real test of a record comes a year later, when somebody asks whether a behaviour was deliberate. That is the intent debt we covered in [our article on knowledge debt](https://detartech.com/en/blog/knowledge-debt-hidden-cost-of-ai-coding): the reason behind a decision never being written down. The code may be clean and the tests may pass, and the team still cannot tell which behaviours were chosen and which were accidental. AI-generated code accelerates this, because the tool that produced the suggestion does not record its reasoning for you. ###### Technology selection and vendor evaluation The question in a selection is not "which technology is best" but "what does being wrong cost". Three criteria settle it: who maintains it after handover, whether you can hire for it in your market, and whether hosting can stay in your own accounts. On a system that already works, the default answer is not to change it, because the case for risking something that already runs, just for an alternative that looks better on paper, is usually weak. None of the Tegoly, Finteo and Terazzi engagements replaced a working technology: on Tegoly the work stayed on the MSSQL and Azure setup already in place, and the Finteo and Terazzi work ran on the platforms those companies already had. On the vendor side the measure is not a reference list but the shape of the handover and who owns the accounts. ###### Team building and engineer evaluation The first engineers do not only write code; they set the company's technology choices and the bar for every later interview. That is why early hires are made against the decisions of the next twelve months, not an org chart imagined three years out. The conclusion of our article on [being a junior developer in the AI era](https://detartech.com/en/blog/being-a-junior-developer-in-the-ai-era-advantage-or-disadvantage) is this: to get value out of AI you have to know what to ask, and have enough technical grounding to judge whether the answer is correct. So the interview question is no longer "write this function" but "here is a generated change, what is wrong with it and why". We sit in the technical part of the interview and write the evaluation criteria; the hiring decision is yours. ###### Technical debt inventory and prioritisation The inventory separates three kinds of debt, because each closes by different work. Technical debt lives in the codebase and closes by changing code. Knowledge debt is the gap in understanding between the codebase and the people responsible for it, and closes only through knowledge transfer; rewriting the code often makes it larger. Intent debt is the reasoning behind a decision going unrecorded, and closes by writing. Each item then goes into one of three boxes: what must change before growth, what can live as it is, and what will never be touched because the assumption behind it is gone. Each item carries the cost of leaving it and of fixing it, so the ordering is set commercially rather than technically. ###### Investor and board communication The question a board asks is never which framework was used. It is what the risk is, what it costs, and when it comes due. We write a summary converting the technical state into three columns. In a funding round the other side's technical review asks for the same list: account and domain ownership, whether the open-source licences in use fit your product, which country the data sits in and where that leaves you under KVKK and GDPR, past security incidents, and areas of knowledge resting with a single person. These items are not assembled when the round opens; they are ready beforehand. We do not write a figure we cannot verify on your behalf, and we do not sign the review as an officer. ##### Which decisions cannot be reversed Sorting decisions by reversibility is the most practical tool in this work. Long meetings usually go to the reversible ones: the UI library, the CI tool, the code style, most library choices, the hosting provider, and while these can be painful they can still be undone. The ones that cannot be undone tend to pass in silence instead, and five of them stand out. First, whether user identity and customer data separation sit in the data model or in application code. Second, where the data sits, because moving it is not only a technical job, it reopens customer contracts. Third, account ownership: if the cloud, domain and repository accounts were opened in the vendor's name, getting them back is a legal process, not a technical one. Fourth, how the payment provider and the refund, subscription and invoicing logic are embedded into the data. Fifth, the first API contract you publish outside, because every customer that integrates locks it in place. These five require written justification before the decision; the rest do not, otherwise the process becomes a burden of its own. ##### Agency or vendor evaluation criteria We write this as an agency ourselves, so the list has to apply to us, and six questions are enough to test it. Does the repository sit in your account with its full history, or does the handover arrive as a compressed folder, leaving who changed what and when unreadable? Whose name are the cloud, domain, DNS and app store accounts opened under, and if you parted ways today, which password would you lack? Does the project come up from scratch outside the vendor's machine? Is the reasoning behind decisions written down, or does it live in a few people's memory? Has the vendor built a closed layer that cannot be carried elsewhere? What unit is a change request priced in, and how does the invoice move when scope grows? An engagement that cannot answer all six ties you to that vendor regardless of the quality of the work. ##### The exit: you becoming independent The measure of success here is not the engagement being renewed but it becoming unnecessary. The exit happens one of three ways: you hire your own technical executive, a senior engineer on the team takes the role, or the flow of decisions slows and no continuing role is needed. All three receive the same handover package: the full decision record, the current-state assessment, the three-box technical debt inventory, the account and access list with owners named, and the vendor evaluation notes. What we avoid is becoming the single point of knowledge: decisions live where your team can read them, not in our heads or a message history. We do not hold your accounts in our name and we do not leave a closed layer behind. Without those two rules an exit stops being a handover and becomes a migration project. ##### How decision authority is divided The work starts with the current-state assessment, which is priced separately and can be handed to your own team. After that it runs off an open decision list: every item has an owner, a date opened and a status; closed items move into the decision record. What belongs to us is the technical recommendation, always written with a named alternative and the cost of both. What belongs to you is the budget, hiring, vendor selection, the timing of a release, and legal responsibility. We also say when the service is not needed: with a single product, a single team and a settled system whose decisions are made, the work required is maintenance rather than advisory. When the problem is load rather than decisions the work moves to [Backend Scaling](https://detartech.com/en/services/backend-scaling), and when it is an unvalidated product idea it moves to [MVP Development](https://detartech.com/en/services/mvp-development). ##### How this worked across three cases The three engagements below are where this work was done; each has its own page in the Success Stories section, checkable from outside. - **[Tegoly](https://detartech.com/en/success-stories/tegoly):** A digital signature and business process platform for the global market. On a system already functioning, the work covered new user screens and modules, digital signature and document management integrations, caching mechanisms, server configuration on Azure, MSSQL and Azure security layers, and technical SEO. - **[Finteo](https://detartech.com/en/success-stories/finteo):** A fintech and digital payment platform. The headline change happened on the frontend: the entire interface was redesigned, customer panel improvements, forms and new screens were added, and content strategy plus technical SEO applied. - **[Terazzi](https://detartech.com/en/success-stories/terazzi):** The web platform of a construction and decoration brand. Design problems were resolved, customer panel improvements and new screens delivered, backend and performance optimisation done, and content strategies applied for search visibility. #### FAQ **How is CTO as a Service priced and how long does it run?** The first step is the current-state assessment, priced as its own line; its output is a written list ordered by cost and impact, and taking that list and handing it to your own team is a legitimate outcome. After that the engagement runs by period, and the length is set by how dense the flow of decisions is. Because more teams, vendors and integrations mean more decisions, we cut the scope in writing at the first meeting. **What gets delivered at the end of the engagement?** Five things get delivered: the decision record carrying every decision with its reasoning, the current-state assessment, the three-box technical debt inventory, the account and access list with owners named, and the vendor evaluation notes. All of it stays under your access. Because we never hold your accounts in our name and never leave a closed layer behind, the handover does not turn into a migration project. **What happens if we end the engagement early?** Everything written up to that point stays with you; the decision record, the assessment list and the debt inventory are kept under your access independently of the contract. No separate handover exercise is required, because the documents already accumulate on your side and the accounts are never opened in our name at any stage. The cost of stopping is limited to the period already completed. **Do your recommendations always point back to your own services?** Buying advice and delivery from the same company is a genuine conflict of interest, which is why every recommendation is written with a named alternative and the cost of both sides. Because the decision record stays with you, a recommendation can be audited after the fact. In the Tegoly, Finteo and Terazzi engagements no working technology was replaced; on a system that works, our default answer is not to change it. **When is this service not the right fit?** We say this plainly: with a single product, a single team and a settled system whose decisions are already made, the work required is maintenance rather than advisory. If the flow of decisions has become continuous, meaning a new question touching architecture arrives every week, the right answer is a full-time technical executive. If the problem is load the work moves to Backend Scaling, and if it is an unvalidated product idea it moves to MVP Development. **How does this role sit alongside our existing software team or agency?** The role sits in front of the decisions, not above the team. Daily task management and code production stay with the existing team or vendor; what we produce is the decision record, the technical debt inventory and the criteria for evaluating vendors. We do not become the legal manager of the engineers on your payroll. The visible benefit for the team is fewer decisions arriving without written reasoning. --- ### Backend Scaling URL: https://detartech.com/en/services/backend-scaling Scaling is not adding servers, it is finding the bottleneck. Measurement, database and query optimisation, cache layers, queues and a reversible migration. Highlights: - Measurement first: no architectural change proposed before a profile exists - Four homes for the bottleneck: query, synchronous step, cache, release pipeline - Query plan and index decisions before growing the server - Redis for cache, RabbitMQ for queues: unwaited work leaves the request path - Gradual, reversible migration with a written rollback plan - Load tests built around a real business event, not a round number Scaling is not adding servers; it is finding where the system is blocked, opening that point, and measuring that it opened. Adding servers sits at the end of that sequence and is usually unnecessary, because the slowness rarely comes from the machine's capacity. It comes from one query running on it, one synchronous step the user must wait through, or a cache layer that was never built. Optimisation without measurement is guesswork, and while guesswork sometimes lands, even then nobody knows why, so it cannot be repeated the next time load rises. That is why a scaling engagement starts with profiling rather than an architecture debate. ##### The difference between scaling, performance and resilience Three separate jobs get confused: performance optimisation means serving the same load with fewer resources, scaling is about how response time behaves as load increases, and resilience is about the system staying up when one part fails. A page can be fast for one user and lock up under thousands of concurrent ones; the reverse happens too, with systems that are slow but stable under load. The three differ in cost, duration and remedy, so we write down which one it is before anything else. Work that skips that distinction usually applies the most expensive fix to the smallest problem. We covered the architectural side separately in our article on [designing scalable and maintainable software architecture](https://detartech.com/en/blog/how-to-design-scalable-and-maintainable-software-architecture). ##### How we set up a scaling engagement The six headings below cover every decision made in a scaling project. The first is diagnosis: what gets measured and which number counts as the target. The next three are the layers where the intervention happens: database, cache and queue. The fifth decides whether the architecture gets split. The sixth belongs at the start of the work rather than the end: measuring capacity. ###### Bottleneck diagnosis and measurement Diagnosis is not done by looking at average response time, because an average is where slow requests hide behind the majority. What matters are the tail percentiles: the user who abandons the system experiences their own request, not your average. Endpoints are taken one at a time and each one's time is broken down between the database, waiting on an external service, and application code. Four more numbers go beside that: slow query logs, cache hit ratio, queue depth, and memory and CPU saturation. We propose no architectural change before that table exists, because it is the only source of a comparison point afterwards. ###### Database design and query optimisation Under load the first thing to break is almost always the database, and the reason is usually not the machine. It is a query with no index, queries repeated inside a loop, or a listing screen whose result set grows without bound. Adding an index without reading the query plan is guesswork too: the wrong index slows writes and moves the problem elsewhere. The Anneekspres marketplace was built from scratch on Python and Django over PostgreSQL, where category filtering, search and the seller panel's stock and order management all run on the same infrastructure. In catalogue systems dominated by filtering, the cost sits in the query rather than the server: World Summer Schools collects hundreds of programmes in one searchable catalogue filtered by age, country, programme type and date. ###### Cache layers and invalidation Adding a cache is easy; the hard part is deciding what must never enter it. A system showing stale data costs more than a slow one, so the lifetime of every cache entry and the event that drops it are written down in advance. Biletico is the concrete example: the platform was taken over and the interface, seating plan and payment flow rebuilt, while on the infrastructure side caching was placed with Redis on a Next.js and Node.js stack, with MongoDB on the data side. On the same platform the canvas-based seating plan can reflect real-time occupancy. On our side the scope of the cache, and what deliberately stays outside it, is settled as a written decision. Cache structures were part of the performance work on Welldone and Tegoly too. ###### Queues and event-driven asynchronous processing A user request should only do the work the user is waiting for. Invoice generation, notification delivery, report calculation and calls to external services are not that work. Lifted out of the request path onto a queue, response time drops and the order flow stays up when a third-party service goes down. On the Anneekspres infrastructure the message queue was built with RabbitMQ, and the case page states that this infrastructure keeps the system running without interruption under high traffic. Lextum AI was built on a microservice architecture with asynchronous processing over RabbitMQ, ready for high-traffic enterprise use. Queues are not free: message loss, double processing and ordering are three separate conditions, each handled on its own. ###### Gradual migration from monolith to microservices Microservices mean splitting an application that lives in one codebase, a monolith, into small services that talk to each other over the network; that split is a cost, not a goal in itself. Once services are separated, a function call becomes a network call, and debugging, data consistency, version compatibility and monitoring all get harder at once. Lextum AI was built with a microservice architecture, meaning it was delivered that way rather than moved off a monolith. Most systems do not need this; one application with properly separated modules is enough for a long time. When a split is genuinely required it does not happen in one go: one part whose load or release rhythm differs clearly from the rest is chosen, its boundary is written down, the read side moves first, and the write side follows only once the read side is measured as working. No second part starts in parallel. ###### Load testing and capacity planning A load test is built around a real event in your business calendar rather than a round number: the minute ticket sales open, a campaign launch, the start of a season, payroll day. The target is written before the test, otherwise the result can be narrated favourably from any angle. What gets measured is not only whether the system holds, but at which point and with which symptom it breaks; without a known breaking point there is no capacity plan. For Anneekspres the requirement for a platform able to carry high traffic was set at the start. On Togodo, performance improvements delivered smooth operation under high traffic. The infrastructure built for World Summer Schools was designed to scale, ready for growing programme and user volume. ##### Where systems actually break The breaking point is rarely processor power; in practice it is one of four places. First, the database: a single unindexed query fills the connection pool as load rises and leaves the whole system waiting. Second, the synchronous path: work the user is not waiting for, left in the request path, slows your system the moment an external service does. Third, a missing or badly built cache, and the second is more dangerous because it shows wrong data silently. Fourth, the release pipeline: if going live is an event, the problem you found stays live for hours or days. CI/CD automation was set up with Jenkins on Anneekspres, Biletico, Lextum AI, Welldone and World Summer Schools, and building that pipeline is a separate job handled under [DevOps and CI/CD](https://detartech.com/en/services/devops-ci-cd). ##### What scaling costs and where to stop Every layer added is a layer that has to be operated. A cache brings invalidation bugs, a queue brings message loss and reprocessing, and splitting services brings failures arriving over the network. So two numbers go beside every scaling decision: the expected gain and the monthly operating burden of that layer. The stopping point is defined up front too. We stop when the measurement hits the target, we stop when the bottleneck is business volume rather than technology, and we do not reach for the larger fix when a cheaper one does the job. An index or one query correction is often both faster and more durable than an architectural change. Vertical growth, meaning one bigger machine, can come out cheaper than a distributed architecture, and we say so when it does. If the product is not validated yet, scaling is the wrong answer and the work belongs under [MVP Development](https://detartech.com/en/services/mvp-development). ##### How the migration runs without downtime Scaling work is done on a living system, so every step has to be reversible. The release pipeline and monitoring go in first, because a change with no rollback mechanism does not get attempted. Schema changes run in two phases: the new field is added, both shapes live side by side for a while, and the old field is removed only after it is measured as unused. Read paths move before write paths, because a mistake on the read side can be undone. Changes go out behind a flag, to a small slice of traffic first. The rollback plan is written before the change ships and names who reverts it at which threshold. On Biletico the structure that lets every update be tested and released, and on Anneekspres the pipeline that makes fast deployment possible, are the precondition for this rhythm. ##### Our technology selection criteria The choice is limited to tools we run in production and that somebody else can maintain after handover. On the database side the default is relational: Anneekspres, Lextum AI and World Summer Schools use PostgreSQL, Welldone uses MySQL, Tegoly uses MSSQL, and Togodo uses both MSSQL and PostgreSQL. Where the schema is variable we move to the document side, and Biletico and Tegoly work with MongoDB. On the application side we use Node.js when the workload is I/O heavy, Python and Django when the data model and admin screens dominate, and .NET when enterprise integration and role structure decide. The cache layer runs on Redis, the queue on RabbitMQ, the servers on Ubuntu and the release pipeline on Jenkins. Three criteria decide, none of them fashion: who maintains it after handover, whether people can be hired for it, and whether hosting can stay in your own account. ##### Projects where this service was part of the work Backend Scaling was part of every engagement below. The detail of each one sits on its own page in the Success Stories section. - **[Anneekspres](https://detartech.com/en/success-stories/anneekspres):** a marketplace for mother and child products built from scratch, with a RabbitMQ message queue, PostgreSQL for data management and Jenkins pipelines; the system runs without interruption under high traffic. - **[Lextum AI](https://detartech.com/en/success-stories/lextum-ai):** document generation, contract review and simultaneous editing for legal teams, on a microservice architecture with asynchronous processing over RabbitMQ and a managed SaaS infrastructure on AWS. - **[Biletico](https://detartech.com/en/success-stories/biletico):** an inherited ticketing platform whose interface, canvas-based seating plan and payment flow were made functional, with Redis caching on Next.js and Node.js and MongoDB on the data side. - **[Togodo](https://detartech.com/en/success-stories/togodo):** new screens, real-time messaging and notifications added to a social events application; performance improvements delivered smooth operation under high traffic. - **[Welldone](https://detartech.com/en/success-stories/welldone):** .NET services, MySQL, cache structures and Ubuntu-based scalable server infrastructure built for an industrial laundry operation. - **[World Summer Schools](https://detartech.com/en/success-stories/world-summer-schools):** hundreds of summer school programmes gathered into one searchable catalogue, on cloud-based infrastructure over Next.js, .NET and PostgreSQL, ready for growing programme and user volume. - **[Tegoly](https://detartech.com/en/success-stories/tegoly):** speed improved on a digital signature platform through cache mechanisms and optimised server configuration on Azure; the performance work brought page load times down. - **[Terazzi](https://detartech.com/en/success-stories/terazzi):** optimisation work on the backend and performance side of a construction and decoration platform, which improved site performance. #### FAQ **How long does a backend scaling engagement take and how is it priced?** The work splits in two and is priced separately. First comes diagnosis: tail percentile response times, slow query logs, cache hit ratio and queue depth are extracted, ending in a ranked bottleneck list with an estimated gain for each item. Second comes implementation, and its duration depends on which items you pick from that list. We give no duration estimate before diagnosis, because it would be a guess. **Can you do this without taking the system down?** Yes. The work runs on the living system in reversible steps. Schema changes happen in two phases: the new shape is added, the old one lives alongside it for a while, and removal comes only after it has been measured as unused. Read paths move before write paths, and changes open behind a flag to a small slice of traffic. The rollback plan is written before anything ships. **What gets delivered when the work finishes?** Four things get delivered. A measurement report with before and after numbers, stating which change bought which gain. A monitoring dashboard and alert thresholds set up inside your own accounts. Load test scenarios in a form you can re-run. And an operations document: where the breaking point sits, when capacity runs out, and what to do when an alert fires. All four are handed over whether or not you continue with us. **Who handles maintenance and monitoring afterwards?** All three arrangements work: you continue with your own team, we continue, or it runs as a mix. The thresholds in the operations document drive that decision, because what to do when an alert fires is written there. If your team takes over, no separate migration is needed, since the dashboard and alerts already sit in your own accounts. Ongoing monitoring can also run as a separate service. **Does every slow system need scaling?** No, not every slow system needs scaling. If traffic is nowhere near the limit of the current server, the job is not scaling but a query or index correction. If the product is not validated yet, architecture for a system with no load is an expense. If the problem is the error rate rather than slowness, that is a resilience job, solved differently. When the diagnosis list comes out empty, we say so in writing. **Why touch the architecture instead of just buying a bigger server?** Most of the time you are right, and that is what we recommend. One bigger machine is cheaper and faster than a distributed architecture and adds no operating burden. That option ends at two points: past a certain size the price stops rising linearly, and one machine is a single point of failure. The diagnosis report puts numbers on both thresholds, so the decision is not made by guessing. ## Success Stories ### bebekistiyorum.com - Multilingual IVF Clinic Website, SEO and GEO URL: https://detartech.com/en/success-stories/bebekistiyorum-ivf-clinic-website Client: Eurofertil · Sector: Healthcare & IVF · Country: Türkiye Eurofertil IVF Centre's legacy ASP.NET site was rebuilt as a 4-language Next.js platform: 1,200+ URLs preserved with 301 mapping plus full SEO and GEO setup. #### Problem bebekistiyorum.com, the website of Eurofertil IVF Centre in Bursa, had grown into one of Turkey's most comprehensive IVF content archives, with 66 medical articles, hundreds of video pages and specialist profiles. Yet the site ran on legacy ASP.NET WebForms: the design was dated, every content update required technical help and mobile performance fell short. Since the clinic also serves international patients speaking Russian and Arabic, the site had to be published in 4 languages. The most critical risk was migration: the search equity accumulated across more than 1,200 URLs could not be lost in the move. #### Solution The site was rebuilt from scratch on Next.js, together with its design, content infrastructure and admin panel. ###### Modern Full-Stack Architecture A server-rendered, MongoDB-backed platform was built with Next.js App Router and React Server Components. A custom admin panel with a Tiptap rich text editor and bulk content import was developed; the content team manages the entire site without any CMS licence. ###### 4 Languages and Arabic RTL Turkish, English, Russian and Arabic publishing was set up with next-intl. Every component was designed to work right-to-left (RTL) for Arabic, and language versions are correctly announced to search engines with hreflang tags. ###### SEO Migration More than 1,200 legacy URLs were mapped to the new information architecture and preserved through a database-driven 301 redirect layer. Technical SEO was completed with per-page dynamic metadata, automated sitemaps, schema.org structured data (JSON-LD) and Core Web Vitals focused performance work. ###### GEO - Visibility in AI Search Beyond classic search engines, the site was optimised for AI-driven search experiences such as ChatGPT and Perplexity: llms.txt, a machine-readable FAQ feed and consistent structured content. ###### Conversion Tracking Google Ads conversion tracking was integrated into the appointment and contact forms, making the return on ad spend measurable through real patient enquiries. #### Results - **More than 1,200 URLs** consolidated on a single modern platform in 4 languages; SEO equity preserved with 301 mapping. - **4-language publishing including Arabic RTL** opened the site to an international patient audience. - **A custom admin panel** lets the content team publish without developer support. - **SEO and GEO infrastructure** positions the site for visibility both on Google and in AI search. - **Google Ads conversion tracking** made appointment form performance measurable. --- ### Lextum AI - AI-Powered Legal Document Management URL: https://detartech.com/en/success-stories/lextum-ai Client: Lextum · Sector: Legal & Legal-Tech · Country: Türkiye SaaS platform for legal professionals offering AI-powered document generation, contract review, real-time collaboration, voice/video calls and versioning. #### Problem Law firms and corporate legal departments managed contract review and document workflows largely through manual processes. Reviewing hundreds of pages for risk took hours; version tracking fell to spreadsheets and file sharing to email chains. There was no way to work simultaneously on the same document: every revision was shared individually, conflicts resolved by hand, and coordination scattered across separate tools. Drafting legal documents such as petitions and contracts meant copy-pasting from templates - a cycle that wasted time and introduced error risk. Protecting sensitive legal data, maintaining audit trails, and keeping up with growing document volumes became critical challenges. General-purpose tools fell short of sector-specific compliance requirements and enterprise-scale demands. #### Solution Lextum AI reimagined these workflows with AI-powered document generation, real-time collaboration and enterprise access management. ###### AI-Powered Document Generation and Analysis Legal texts are automatically analysed to produce meaningful insights. Documents such as petitions and contracts can be generated with AI assistance; the system also handles research functions like case search and legal briefs. Potential risks and compliance issues in contracts are detected, letting lawyers focus only on critical points. ###### Real-Time Collaboration and Communication Multiple users can work on the same document simultaneously. While co-editing without conflicts, users can also hold voice and video calls within the same session - no external tools needed for coordination. ###### Document History and Versioning All changes are tracked and reversible. Who changed what and when is fully visible; no revision is ever lost. ###### Enterprise Authorisation and Technical Infrastructure Role-based secure access is provided for different user types. A microservice architecture with RabbitMQ-powered async processing handles high-volume enterprise workloads. A fully managed SaaS infrastructure on AWS with a Next.js frontend and .NET backend runs with Jenkins CI/CD automation. #### Results Lextum AI launched as a legal-tech platform that accelerates legal workflows, makes risks visible and gives organisations a real digital transformation advantage. - **Contract review time significantly reduced** \- AI pre-analysis lets lawyers focus only on critical points. - **Collaborative editing delivered** \- multiple users can work on the same document simultaneously, with voice/video calls keeping coordination inside the platform. - **Risk oversights minimised** \- automated compliance scanning removed human error from the process. - **Secure enterprise document management achieved** \- with role-based access and full audit trails. - **SaaS architecture** scales seamlessly with growing user and data volumes at high performance. --- ### Yükpro - Freight & Load Board Platform URL: https://detartech.com/en/success-stories/yukpro-freight-load-board-platform Client: Akın Atmaca · Sector: Logistics & Transportation · Country: Türkiye A mobile load board that connects cargo owners with carriers and drivers, with route-based load alerts and one-tap call or WhatsApp contact. #### Problem In road freight in Turkey, cargo owners struggled to find the right carrier, and carriers struggled to find loads that matched their routes. Matching relied on phone calls, scattered WhatsApp groups and intermediaries. This wasted time, increased empty return trips and reduced price transparency. #### Solution We built a mobile listing platform that connects cargo owners directly with carriers and drivers. Cargo owners publish listings for free, with no limit, including route, vehicle type and price. Carriers filter by city, vehicle type and loading method, then reach out with one tap by phone call or WhatsApp. Route-based load alerts, set by origin and destination city, send an instant push notification when a matching listing is posted. Carriers can share their vehicle and driver details from their profile as a ready-made message in one step. The app is live on iOS and Android from a single Flutter codebase, on a Firebase backend (authentication, Firestore, Cloud Functions and notifications). Carriers get a 14-day trial, followed by a monthly in-app subscription. #### Results Yükpro is live on the App Store and Google Play. Because listing is free for cargo owners, the barrier to joining the platform is low. Carriers can reduce empty return time by searching, filtering and following loads that match their routes through instant notifications. Since contact happens directly between the parties, there is no intermediary cost. The revenue model is based on carrier subscriptions. --- ### Biletico - Event Ticketing Platform for Children URL: https://detartech.com/en/success-stories/biletico Client: Biletico · Sector: Events & Ticketing · Country: Türkiye Event ticketing platform for children. Taken from near-zero functionality to live with a canvas-based seating plan, secure payment integration and comprehensive UX overhaul. #### Problem Biletico aimed to help parents easily find events suited to their children and buy tickets with confidence. The platform had a foundation in place but almost no feature was functional, the design was far behind modern standards and the payment flow had been left incomplete. There was no seating plan component at all - event organisers had no way to manage seat layouts. The user experience had serious issues and mobile compatibility was inadequate. To go live, almost everything had to be redesigned and made functional. #### Solution At Detartech we took the existing foundation and transformed the entire system into a functional, modern platform. ###### Design and UX Overhaul All interfaces were redesigned from scratch. A mobile-first approach ensures a consistent, fast experience on every screen size. Category-based event listing, age filter and advanced search let users find the event they want within seconds. ###### Canvas-Based Seating Plan A canvas-based seating plan component was developed that lets organisers visually design event venues. Seats can be grouped, divided into categories and display real-time occupancy status. ###### Secure Payment Integration The payment infrastructure was set up to industry standards. A secure, fast and user-friendly payment flow was delivered together with cart management and order history. ###### Technical Infrastructure Caching with Redis on a Next.js + Node.js stack and CI/CD automation via Jenkins pipelines. Every update is tested and deployed to production safely. #### Results A non-functional platform was transformed through comprehensive redevelopment into one of Turkey's leading digital solutions for children's event ticketing, and taken live. - **All core features rebuilt from scratch** \- payment, profiles, search and ticket management went live fully functional. - **Canvas-based seating plan** lets organisers visually manage seat layouts. - **Modern, mobile-responsive design** delivers a high-quality user experience on both desktop and mobile. - **Secure payment infrastructure** gives parents confidence when purchasing. - **CI/CD automation** enables new features to be deployed quickly and safely. --- ### Welldone - Industrial Laundry Management System URL: https://detartech.com/en/success-stories/welldone Client: Welldone Group Turkey · Sector: Industrial & Operations Management · Country: Türkiye Mobile app + web panel solution digitalising order, shipment, racking and packaging processes on a single platform. #### Problem Welldone Group Turkey ran its industrial laundry operations through spreadsheets and verbal coordination. Every stage from order to shipment - washing, drying, racking, packaging - was tracked in separate systems or on paper. Field workers had no visibility into real-time job status; managers depended on manually prepared reports to access current operational data. Customer-specific shipment planning was error-prone and reporting was delayed. #### Solution At Detartech we developed an end-to-end system covering a mobile app, a web management panel and backend services. ###### Mobile App (Flutter) Field workers can perform product-based packaging via QR code scanning. Order status updates in real time; in-team communication runs via platform notifications and messaging. ###### Web Management Panel (React.js) Order creation, customer management, shipment planning and real-time reporting are all managed from a single screen. Managers can make immediate decisions. ###### Backend and Infrastructure (.NET + MySQL) Backed by high-performance .NET services, cache structures and a scalable Ubuntu-based server infrastructure. CI/CD automation provided via Jenkins. #### Results Welldone Group Turkey improved operational efficiency and consolidated all processes on a single digital platform. - **The entire operation from order to shipment** is now managed through a single platform. - **QR code-based mobile app** lets field teams track processes in real time. - **Real-time reporting** enables managers to make immediate decisions. - **Customer-specific shipment planning** minimised operational disruptions. --- ### World Summer Schools - Global Summer School Catalogue URL: https://detartech.com/en/success-stories/world-summer-schools Client: BYA Consultancy · Sector: Education & EdTech · Country: United Kingdom Digital platform connecting families and students with global summer school programmes, featuring AI-powered content entry. #### Problem BYA Consultancy needed a digital platform to connect families and students with global summer school programmes. The existing process relied on manual content management, email correspondence and scattered information sources. Presenting hundreds of summer school programmes from around the world in an organised, searchable and user-friendly format, speeding up content entry and keeping the system scalable were critical requirements. #### Solution The platform, built from scratch, met these requirements with AI-powered content entry and a comprehensive search infrastructure. ###### Global Programme Catalogue Summer school programmes from around the world are presented under one roof. Users can apply advanced filters by age, country, programme type and dates. ###### AI-Powered Content Entry (OpenAI) School and programme information can be automatically structured via OpenAI integration. After content managers enter raw data, AI generates summaries and category suggestions - significantly reducing manual workload. ###### Multi-User Authorisation A custom authorisation structure for different user types (visitor, consultant, admin) enables secure content management. ###### Technical Infrastructure Cloud-based, scalable infrastructure on a Next.js + .NET + PostgreSQL stack. CI/CD automation via Jenkins. #### Results World Summer Schools established a scalable, long-term digital platform infrastructure for BYA Consultancy in the global education market. - **Hundreds of global programmes** consolidated into a single, searchable catalogue. - **AI-powered content entry** accelerated the process of adding programmes. - **Role-based authorisation** keeps content management secure and controlled. - **Scalable infrastructure** ready for growing programme and user volumes. --- ### Anneekspres - Online Marketplace for Mothers URL: https://detartech.com/en/success-stories/anneekspres Client: Anneekspres · Sector: E-Commerce & Marketplace · Country: Türkiye Category-based marketplace for mother and child products. Launched from scratch with a seller panel, secure payment, order tracking and high availability. #### Problem There was a need for a reliable, focused and easy-to-use marketplace in the mother and baby products segment. Existing general-purpose platforms offered no experience tailored to the mother and child category - finding the right product amid content noise was becoming difficult. A scalable platform had to be built from scratch that provided easy navigation and secure payment for buyers while offering inventory and order management for sellers, and could handle high traffic. #### Solution A fully featured marketplace infrastructure was developed from scratch on Django and PostgreSQL. ###### Category-Based Product Management Easy filtering, search and category navigation for mother and child products. Buyers can quickly find what they need. ###### Seller Panel Sellers can manage all operations - product listing, inventory updates, order tracking and sales reporting - from their own panel. ###### Secure Payment and Order Flow A secure and fast shopping experience delivered through an industry-standard payment infrastructure. Users can track their orders in real time. ###### Technical Infrastructure High availability and fast deployment achieved through RabbitMQ message queuing, reliable data management with PostgreSQL and Jenkins CI/CD pipelines. #### Results Anneekspres went live as a modern, secure marketplace designed to serve the needs of mothers in Turkey. - **Fully featured marketplace** launched from scratch - buyer and seller flows fully operational. - **Seller panel** lets stores manage products and orders independently. - **RabbitMQ-based infrastructure** keeps the system running without interruption under high traffic. - **Secure payment integration** established user trust. --- ### BiTalih - Social Media Content Production Platform URL: https://detartech.com/en/success-stories/bitalih Client: BiTalih · Sector: Digital Marketing & Content · Country: Türkiye Corporate content production platform generating banner and reels content with dynamic variables on fixed design templates, with role-based access. #### Problem BiTalih teams produced social media content such as banners and reels through manual design processes. Repeatedly editing the same template for different events was time-consuming and led to design inconsistencies. Depending on designers for every piece of content limited daily production volume and prolonged approval cycles. There was a need for a role-based, controlled solution where employees in different departments could update only variable fields without breaking the design. #### Solution The canvas-based content production platform automates dynamic content flow while preserving design integrity. ###### Canvas-Based Template System Fixed background templates (announcements, events, campaigns, etc.) are defined. Users create new content by updating only variable fields such as venue, time and amount on the canvas - design integrity is always maintained. ###### Role and Permission-Based Access Each employee sees only the screens and templates relevant to their responsibilities. Corporate operational control is strengthened while division of labour is clarified. ###### Rapid Content Production Daily content production is completed in minutes. Manual editing and approval cycles are eliminated; teams can produce content independently, quickly and consistently. #### Results BiTalih teams moved social media content production to a centralised, controlled platform. - **Content production time** dropped from hours to minutes. - **Design consistency** maintained in every piece of content through the template system. - **Role-based access** strengthened operational control and eliminated conflicts. - **Designer dependency** for daily content production came to an end. --- ### Togodo - Social Events Mobile App URL: https://detartech.com/en/success-stories/togodo Client: Togodo · Sector: Social & Mobile · Country: Türkiye New screens, real-time messaging and performance improvements delivered to a social events mobile application. #### Problem Togodo was a mobile app enabling users to meet new people and participate in social events. While the existing app was functional, there were gaps in event management, messaging and user profile screens. Real-time features to boost user engagement, new interfaces and performance improvements were needed. The app's visibility on both search engines and mobile stores was insufficient. #### Solution New screens, real-time features and visibility improvements were delivered to the existing platform. ###### New Screens and Features Modern interfaces designed for event listing, user profiles and community management. Users can create events, join them and invite friends. ###### Real-Time Messaging and Notifications Real-time messaging and push notifications developed to boost community engagement. ###### SEO and ASO Optimisation SEO improvements to boost the app's web visibility and ASO optimisations for mobile stores were implemented. #### Results - **New event management screens** strengthened the user experience. - **Real-time messaging** increased community engagement. - **SEO & ASO work** improved app visibility. - **Performance improvements** ensured smooth operation under high traffic. --- ### Tegoly - Digital Signature and Business Process Platform URL: https://detartech.com/en/success-stories/tegoly Client: Tegoly · Sector: Digital Signature & Business Processes · Country: Germany New screens, functional modules and SEO improvements delivered to an international digital signature platform. #### Problem Tegoly was a platform targeting the global market in digital signatures and business processes. While the existing system was functional, screens and modules to improve the user experience, some integration gaps and insufficient SEO visibility were areas that needed to be addressed. #### Solution Comprehensive improvements were made in user experience, technical infrastructure and digital visibility. ###### New User Screens and Modules Interfaces tailored to customer needs and digital signature, document management and integration modules were developed. ###### Performance and Security Speed improved with cache mechanisms and optimised server configurations on Azure. Data protection strengthened with MSSQL and Azure security layers. ###### SEO Optimisation Search engine visibility improved with meta descriptions, content adjustments and technical SEO improvements. #### Results - **New screens and modules** strengthened the user experience. - **Performance optimisations** improved page load times. - **SEO work** increased search engine visibility. - **Azure-based secure infrastructure** strengthened data protection. --- ### Terazzi - Construction and Decoration Web Platform URL: https://detartech.com/en/success-stories/terazzi Client: Terazzi · Sector: Construction & Decoration · Country: Türkiye Design improvements, new functions and SEO optimisations delivered to the web platform of a construction and decoration brand. #### Problem Terazzi's web platform needed modernisation on both design and functionality fronts. Search engine visibility was insufficient, there were user experience issues and there were areas on the backend side requiring performance improvement. #### Solution Comprehensive improvements were made in design, functionality and SEO. ###### Design and UX Improvements Design issues resolved, customer panel improvements and new screens enhancing the user experience were delivered. ###### SEO and Performance Content strategies providing search engine visibility were implemented. Optimisations made on the backend and performance side. ###### Corporate Identity Modern web pages reflecting brand value were created. #### Results At Terazzi the running platform was kept; what was delivered is design, functionality and search visibility work on the brand's existing web platform. - **Design fixes and new screens:** Design issues on the platform were resolved and new screens aimed at the user experience went live. - **Customer panel:** Improvements were made on the panel side. - **Corporate web pages:** Modern pages reflecting the value of the construction and decoration brand were created. - **SEO and backend:** Content strategies for search visibility were applied, and the backend and performance side was optimised. --- ### Finteo - Financial Technology Web Platform URL: https://detartech.com/en/success-stories/finteo Client: Finteo · Sector: Fintech & Digital Payments · Country: Türkiye Modern design overhaul, new functions and SEO optimisations delivered to a fintech platform. #### Problem Finteo's web platform had an outdated design that lagged behind user expectations. In the fintech sector, where trust and modernity must come first, the existing appearance did not fully reflect the brand's value. SEO visibility was insufficient and some functional modules were missing. #### Solution The most significant change took place on the frontend: a transition to a modern design was made. ###### Modern Design Overhaul The entire frontend was redesigned, achieving a trustworthy, modern and professional look appropriate for the fintech sector. ###### New Functions and Modules Customer panel improvements, forms and new screens enhancing the user experience were delivered. ###### SEO Optimisation Content strategies providing search engine visibility and technical SEO improvements were implemented. #### Results At Finteo the weight was on the frontend: the fintech platform's interface was redesigned from the ground up, new customer-facing functions were added and search visibility was worked on. - **The entire interface was redesigned:** The platform moved to a trustworthy, professional look suited to the fintech sector. - **Customer panel, forms and new screens:** New functions that improve the user experience went live. - **Content strategy and technical SEO:** Content and technical improvements aimed at search engine visibility were applied. --- ### Ignis Trace - Industrial Heat Tracing Web Platform URL: https://detartech.com/en/success-stories/ignistrace Client: Ignis Trace · Sector: Industrial & Heat Technologies · Country: Türkiye New screens, functional modules and SEO improvements delivered to the web platform of an industrial heat tracing firm. #### Problem Ignis Trace is a firm specialising in industrial heat tracing as the Turkish business partner of SOLCO PYROELEC. The web platform did not fully reflect the brand's value; search engine visibility was insufficient and some screens and modules were missing. #### Solution Web platform development, new screens and SEO strategy support processes were carried out. ###### New Functions and Screens Customer panel improvements, forms and new screens enhancing the user experience were delivered. ###### SEO and Corporate Identity Content strategies providing search engine visibility were implemented. Modern web pages reflecting brand value were created. #### Results Ignis Trace works in industrial heat tracing as the Turkish business partner of SOLCO PYROELEC; what was delivered is development work on the web platform that presents this expertise. - **New screens and functions:** Customer panel improvements, forms and new screens aimed at the user experience went live. - **Corporate identity:** Modern web pages reflecting the company's brand value were created. - **SEO:** Content strategies for search engine visibility were applied. --- ### Adatech - WordPress Website Development and SEO URL: https://detartech.com/en/success-stories/adatech Client: Adatech · Sector: Software & Technology · Country: Türkiye Modern design pages, SEO optimisations and performance improvements delivered to a software firm's WordPress-based website. #### Problem Adatech's website did not adequately highlight the company's services and brand identity. Search engine visibility was weak, the design was behind current standards and mobile compatibility needed improvement. #### Solution Comprehensive improvements were made in design, SEO and performance on WordPress. ###### New Screens and Design Modern, responsive designs highlighting company services were delivered. A mobile-compatible structure ensures a seamless experience on all devices. ###### SEO Optimisation Search engine rankings improved with keyword-based content, blog structure and backlink strategies. #### Results Adatech's WordPress-based website was kept and developed further; the work focused on design, mobile compatibility, performance and SEO. - **New pages highlighting services:** Modern, responsive designs highlighting the company's services went live on WordPress. - **Mobile compatibility:** A mobile-compatible structure made the site work smoothly on all devices. - **SEO foundation:** Keyword-based content, a blog structure and a backlink strategy were set up. - **Performance:** Performance improvements were made across the site. ## Frequently Asked Questions Source: https://detartech.com/en/faq ### What is the process for developing a project with Detartech? The process starts with a discovery call and requirements analysis. We then prepare a technical architecture proposal and project plan. Once approved, we move into sprint-based development with a working demo delivered at the end of each sprint. Depending on project size, we work in 2-8 week iterations and adjust based on your feedback. ### How does Detartech's pricing model work? We offer two main models - fixed-price projects and time-and-materials. Fixed price works best when scope is clearly defined, while monthly retainer or hourly billing suits evolving or long-term products. After a discovery call, we prepare a clear proposal aligned with your expectations and budget. ### How long does it take to deliver an MVP? A typical MVP is delivered in 6 to 16 weeks depending on scope. A focused product with core features can launch in 6-8 weeks, while projects requiring a mobile app or complex backend may take 12-16 weeks. Clearly defined priorities allow us to significantly shorten these timelines. ### Who owns the source code when the project is completed? Full ownership of the source code transfers to you upon project delivery. This intellectual property transfer is explicitly stated in the contract. We also provide upfront information about any open-source library licences used throughout the project. ### Do you offer maintenance and support after the project is completed? Yes, we offer monthly maintenance and support packages after project delivery. These cover bug fixes, security updates, performance monitoring and minor feature requests. We can tailor the support scope to match your specific operational needs and budget. ### What is included in your CTO as a Service offering? We provide technical leadership, architecture decisions, team management and technology selection consulting on a weekly or monthly basis. This lets you access strategic technical guidance without hiring a full-time CTO - ideal for early-stage startups and scaling companies. ### Can you develop both web and mobile applications? Yes, we develop for both web - Next.js, React - and mobile - Flutter, React Native. Managing web and mobile together with a single team reduces coordination overhead and ensures a consistent product experience across all platforms. ### Can you integrate AI solutions into my existing system? Yes, we can integrate OpenAI, RAG systems or custom ML models into your existing infrastructure. We start by analysing your current system and proposing the least disruptive integration architecture. Our experienced team is ready for chatbot, intelligent search, document analysis and automation use cases. ### Do you provide support for DevOps infrastructure and CI/CD setup? Yes, we handle full DevOps setup on Docker, Kubernetes, GitHub Actions and cloud providers including AWS, GCP and Azure. We set up automated test pipelines, staging environments and production deployments so your team can ship fast and safely. ### Do you work with international clients? Yes, we actively work with clients from Europe, the US and the Middle East. Our communication, project management process and documentation run in both Turkish and English. We are flexible with synchronous and asynchronous working arrangements across different time zones. ### How can I track the progress of my project? We provide board access via Jira or Linear for every project. Weekly status meetings and sprint reports keep the process fully transparent. For urgent matters, our direct communication channel via Slack or WhatsApp is always available. ### Can you do SEO work to increase my organic traffic? Yes, we start with a technical SEO audit and progress through Core Web Vitals optimisation, structured data, hreflang and content strategy. We also apply GEO - Generative Engine Optimisation - to help your brand gain visibility in AI search engines like ChatGPT and Perplexity, with monthly reporting provided. ### Which industries do you have experience in? We have delivered projects in fintech, e-commerce, healthcare, logistics, SaaS and enterprise software. Our team adapts quickly to sector-specific requirements including GDPR compliance, payment integrations and high-traffic system management. ### Can you take over and continue developing an existing project? Yes, we have experience taking over existing codebases. We start with a technical analysis and code quality audit, then share a clear risk assessment and development plan. We work with legacy code, poor documentation and technically indebted projects as well. ### What roles are on your team? Detartech is an Istanbul-based team of specialists including frontend, backend and mobile developers, DevOps engineers, SEO and GEO experts and project managers. We assign the right profiles based on project scope, creating a flexible team structure tailored to each engagement.