Frequently asked questions
Frequently asked questions
Everything people ask us about software development, mobile apps and digital projects — process, technology choices, security and budget.
01Project process
A corporate website takes 2–4 weeks, an e-commerce platform 6–8 weeks, a mobile app 8–12 weeks, and a system with AI integration 3–6 months. What sets the timeline is the number of integrations rather than the number of screens: payment, identity, accounting and enterprise connections each add their own testing load. We give a firm schedule after the analysis in the first meeting.
A website wins when customers find you by searching; a mobile app wins when the same people come back several times a week. The website is stronger on reach and search visibility, the app on retention and bringing people back with notifications. As a rule, build the website first — the app is the step worth investing in once repeat usage is measurable.
Yes. An MVP is not a smaller version of the whole idea but the first release containing the single assumption worth testing. We narrow the scope together: which screen the product cannot work without, and which can wait for version two. A typical MVP ships in 6–10 weeks, and once the first user data arrives the roadmap is updated by measurement rather than guesswork.
Yes, and in most cases without taking the system down. The new version is placed in front of the old one, traffic moves across at a small percentage first, and a path back stays open at every step. Your existing data, user accounts and search rankings are preserved, and old URLs are connected to the new ones with permanent redirects. We start by measuring, not by reading code.
Every two weeks you open and try the working build yourself on a test environment — the real product, not screenshots. At the end of each cycle we send what is finished, what is not, and what is waiting on you, in writing. A shared channel handles day-to-day questions in between. Anything blocking a decision is raised immediately rather than held to the end of the cycle.
Yes, and the decision points are set out in advance. We discuss the flow on wireframes first, then present two distinct visual directions, and the chosen direction becomes the design system. Feedback is collected in one pass and recorded in writing; an approved screen goes into code. That order removes the cost of design changes arriving after development has started.
Yes — a significant share of our projects run this way. We work in your repository, your release process and your meeting rhythm, and no separate delivery package is prepared. The reason is handover quality rather than speed: a team working separately leaves a codebase behind, a team working alongside yours leaves the habit of running it. Role boundaries are written down in the first week.
02Technology
On the web, Next.js, React and TypeScript; on the backend, Node.js, Go and .NET; for data, PostgreSQL and MySQL; on mobile, React Native, Flutter and Swift/Kotlin where needed. We pick technology on three criteria rather than fashion: the stack your team can maintain, the real load profile of the work, and five-year total cost of ownership.
Yes, from a single codebase. An app written in React Native or Flutter ships to both stores without a second team or a second maintenance bill. For modules that sit close to the device — camera processing, background location, heavy graphics — we drop into Swift or Kotlin and bridge that module in, so the choice is not one or the other but the right tool in the right place.
We work across eighteen sectors: banking, insurance, payments, retail, healthcare, pharma, logistics, manufacturing, automotive, energy, telecoms, public sector, education, travel, real estate, media, technology and agri-food. What decides suitability is the shape of the process rather than the sector: any process that repeats often, has a measurable output and whose data is already being collected is a fit.
Yes. Locally we integrate iyzico, PayTR and PayU; globally Stripe and PayPal, including 3D Secure and instalments. Card data never enters your site — the payment page is hosted by the provider and the card is represented by a token. That choice sharply reduces the PCI DSS compliance burden, and refunds, cancellations and reconciliation all sit in one transaction history.
Technically you need four things: a domain, a payment provider agreement, a shipping integration and product data. In practice the fourth is what holds projects up — a catalogue with missing photos, descriptions or variants cannot go live. Legally you need distance-selling terms, a returns policy and a data protection notice. With those in place, launch in 6–8 weeks is realistic.
Yes, we manage the whole release: developer account setup, store copy, screenshots, privacy labels and review responses. Most rejections come from policy clauses rather than code — no account-deletion flow, an unexplained permission request, privacy labels that do not match the app's actual behaviour. We put those clauses on the pre-release checklist.
Yes, and we target two engines at once. On classic search we build the technical foundation, speed, structured data and content architecture. For generative engines, pages are written so that ChatGPT, Perplexity and Gemini can cite them: each page answers a concrete question, the answer sits in the first paragraph, and claims are tied to a source. This site is built the same way.
Yes — we do the setup, but the accounts are opened in your name. We work on AWS, Google Cloud and DigitalOcean, including domain, SSL certificate and email configuration. Owning the account is not a detail but a safeguard: if you decide to change supplier, access to your own infrastructure never depends on someone else's approval.
Yes. Every site ships with a content management panel: adding posts and pages, replacing images, editing menus and filling in SEO fields need no technical knowledge. At handover we run a live session with your team and leave short screen recordings and written documentation. Work that changes the structure — a new page type, a new integration — stays with us.
03Security and rights
You do. On delivery and final payment, source code, design files, infrastructure definitions and all intellectual property transfer in full. Because repositories, secrets and cloud accounts were opened in your name from the start, handover is not a file transfer but handing over the keys to a system that is already yours. The process is not closed until your team runs the deployment pipeline themselves.
Scope is narrowed first: if card data never enters the system, there is no card data to protect. For the remaining scope we apply network segmentation, end-to-end encryption, tokenisation, two-factor authentication, immutable access logging and regular penetration testing, all mapped to PCI DSS requirements. Environments are isolated from each other and production data is never copied into a test environment.
Your data is not used to train models: training use is switched off in provider contracts and that is put in writing. Data is stored and processed encrypted, access is role-based, and a non-disclosure agreement is signed before work starts. Where confidentiality demands it, the model runs on your premises or in your own cloud account — and then no request ever leaves your network.
This is an architectural decision, taken before the project starts. We keep data only in the region you specify; where it must stay in Türkiye, a local region or an on-premises installation is chosen. If personal data will cross a border, the transfer conditions of law 6698 and the required undertakings are written into the project documentation — it is not something resolved afterwards.
Yes. Websites come with one month and mobile apps with two months of free support, during which defects are fixed at no extra cost. After that we agree a maintenance contract with a written scope: response time, fix priority and the number of releases per month. We also keep a planned release calendar for operating system and store policy changes.
04Budget and payment
Four things set the cost: scope, the number of integrations, how bespoke the design is, and duration. Screen count matters less than people expect; the real weight comes from payment, identity, accounting and enterprise connections. We listen to the requirement in the first meeting, run the analysis and prepare an itemised proposal — with what is out of scope written down too.
You do not need a finished specification. Three things are enough: a one-paragraph description of the problem you want solved, a list of the systems it must connect to (accounting, point of sale, shipping, CRM), and a target date if you have one. Two examples of products you like speed things up noticeably. With those we usually produce a first proposal within a few working days.
Payment is usually split into three stages: 40% at kick-off, 30% on design sign-off, 30% on delivery. Longer projects get more stages, and each stage is tied to a delivered output rather than to the calendar. We accept card, bank transfer and cheque, and invoice companies directly. If scope changes, the difference is approved in writing before the work starts.
The first period is free: one month for websites, two months for mobile apps. Defects found in that window are part of delivery and cost nothing extra. After that, maintenance is a separate agreement with a written scope — response time, fix priority, releases per month. New feature development is kept separate from maintenance; putting both in one line item blurs the expectation.
Four questions settle most of the decision: who holds the source code and the accounts after delivery, what has been written down as out of scope, how many people are on the team and who they are, and how maintenance is priced. Instead of portfolio screenshots, ask for a product still live today and speak to its client. A firm that will not answer in writing will not run the project in writing either.
Still have a question?
Ask it directly and someone from the technical team will reply within one business day.