What people actually ask us.

It starts with a discovery call where we map how the work happens and agree what we're solving. Architecture and interface design follow. Development runs in two-week cycles, and you see something working at the end of each one. Testing, launch and handover close it out.

It depends on scope. A focused application covering one process usually runs 6-10 weeks; a system spanning several departments with integrations takes 3-6 months. After a discovery call we give you a phased schedule rather than a vague range.

Yes — that's the point of shipping in slices. Because you see something working every two weeks, a wrong direction gets caught early. If a scope change affects the schedule or budget, we put that in writing at the moment it comes up.

Time from someone who knows the business during discovery, then roughly an hour every two weeks to review progress. Beyond that, quick answers where a decision is needed — pending decisions are what costs projects the most time.

Where scope is clear, yes. Where scope will only become clear during discovery, we price the discovery stage alone and set the rest against what it turns up. Quoting a fixed price for unclear scope costs both sides.

You do. The source code, database and infrastructure accounts are all opened in your name and handed over at the end. We don't build in technical lock-in to keep you as a client.

No. We can stay on for maintenance and new features, or hand the system to your own team. In a handover you get documentation, setup instructions and the reasoning behind the architectural decisions in writing.

A website tells; visitors read, browse and get in touch. A web application does work; users log in, enter data and run operations — booking systems, dashboards, order tracking. Most companies need both, and we work out which you actually need during discovery.

Yes, we take on inherited systems. We review the code and infrastructure, produce an assessment, then explain what can be improved and what needs replacing, with reasoning. Access to the source code is required.

Usually. If the system has an API we connect directly; if not, we build a bridge over file transfer, database access or the interface itself. We don't promise before seeing what you run — that gets settled in discovery.

Yes, targeting iOS and Android from one codebase, including store submission, offline support and subscription billing. Kas Hafızam is an app we built this way.

The healthiest start is one job: classifying incoming email, extracting data from invoices, summarising long records, or answering common questions from your own documentation. We pick one, measure accuracy, and expand only if it earns its place.

No. Enterprise APIs don't feed data into training, and we configure those settings explicitly. You get a written record of what data goes where; if sensitive data must never leave your environment, we can run that part on your own infrastructure.

Yes. We're based in İstanbul but run the work remotely end to end. Calls are online and you see progress in a live demo every two weeks. We also work with clients outside Türkiye.

Yes. Error tracking, performance monitoring and further development continue after launch. If you'd rather move it in-house, we plan an orderly transition.

Within 24 hours on business days. Messages that arrive at the weekend go into Monday morning's queue.

No. When something falls outside what we're good at, we say so. Sometimes that means telling you not to rewrite a system at all.