Frequently Asked Questions

We offer web application development, mobile app development, backend and API development, UI/UX design, MVP development and corporate website development.

We run projects end to end, from idea to launch: discovery, data model and architecture, interface design, development sprints, testing and release. Because the same team is present at every stage, nothing is lost in handover between design and engineering.

Some clients come to us for a single piece — building an existing design, or redesigning an existing product. We can also extend your current team.

Yes, we work in three different models.

If you already have designs, we can take on development only; in that case we review the design for feasibility before building. If you already have a product, we can work on UI/UX design only, delivering development-ready Figma files, a design system and a clickable prototype.

The third model is team extension: we add a developer or designer to your existing team for a defined period, adapting to your processes and tools.

We are based in Ankara, Türkiye, and operate as a service-area business.

For projects in Ankara we prefer to hold the first discovery meeting in person; the decisions made in a project's first week are the most expensive to reverse, so being in the same room is worth a lot. Delivery then runs remotely.

We work fully remotely with clients in Istanbul, Izmir and other cities across Türkiye, as well as internationally. We share a time zone with every client inside Türkiye, so getting an answer does not mean waiting until the next day.

All source code and the intellectual property of the product are yours. The code lives from day one in a repository created under your account; we work as contributors to that repository.

Delivery is not just code files: you also receive a document describing architectural decisions, the list of environment variables, the database schema and the release steps. The goal is to leave the project in a state you could continue without us.

Design files (Figma), store accounts and the domain are also registered in your name. No asset stays locked inside our accounts — that is the most common problem teams hit when they want to change agencies, and it should be prevented from the start.

We treat technical SEO not as a separate service but as a standard part of corporate web projects. Server-rendered HTML, a single H1, correct heading hierarchy, canonical tags, hreflang, sitemap, robots.txt and structured data (schema.org) are part of every delivery.

On top of that we add a layer for AI search engines: an llms.txt file, robots rules that explicitly allow AI crawlers, and FAQ blocks written in a quotable format. We use the same setup on our own site.

Ongoing SEO work — content production, keyword research and link building — is a separate scope; we plan it as a monthly engagement when requested. Keeping the technical setup separate from content work matters, because it is the only way to measure which effort produced which result.

An MVP with a single verifiable flow typically ships in 4-6 weeks. We took DrapeAI's AI-powered virtual try-on app to the store in that window.

We work in 1-2 week sprint cycles, and every sprint ends with a working build you can install on a test device. You see progress through the product itself, not through a status report.

That time is won by narrowing scope, not by adding people. In the first meeting we write down everything that stays out of the MVP — the most practical tool against silent scope growth. For projects with multiple main flows, 8-12 weeks is realistic.

Every project moves through six steps: discovery, architecture and data model, interface design, development sprints, testing and launch. The steps overlap — the data model is usually in place while design is still running.

Discovery surfaces the business goal, the user flows and the systems already in place; its output is a written scope list plus an explicit list of what stays out. Architecture settles the data model, authorization rules and external integrations. Together these two steps take roughly a fifth of the total timeline and prevent the most expensive corrections later.

Development runs in 1-2 week sprints, and you see a working build at the end of each one. The launch step covers store submission or server setup, plus analytics, error tracking and backups.

There are three fixed touchpoints: a shared messaging channel, an end-of-sprint demo and a test build that is always available.

The messaging channel handles day-to-day questions; nothing stays unanswered longer than 12 hours. In the end-of-sprint demo we walk through the working build together and agree the scope of the next sprint right there. On mobile projects you can reach the product any time through TestFlight or Firebase App Distribution, and on web projects through a preview URL.

The issue board is shared, so you can see the state of any task without asking us. We do not produce a separate weekly report — the working product itself is more accurate than a report.

Scope change is normal, not an exception. What matters is that its effect on timeline and budget stays visible.

When a new request arrives we evaluate it with two questions: would this delay launch, and would it be more expensive to add after launch? If the answer to both is no, the request goes to the post-launch list. If yes, we decide together what leaves the sprint in exchange — adding scope is always a trade.

In fixed-scope contracts such additions are priced as a written change item. In sprint-based engagements they simply enter the next sprint plan, with no contract change needed. In both cases the estimated impact is shared in writing before any work starts.

We reply to every request from the contact form within 12 hours.

Our first reply usually contains a few clarifying questions: what problem the project should solve, which platforms you are targeting, and what systems already exist. We then schedule a short discovery call.

By the end of that call, scope, a realistic timeline estimate and a budget range are settled. Nothing is charged up to this point.

The main driver of cost is not screen count but the number of integrations and the complexity of user roles. Every external system the app connects to — payments, ERP, shipping, maps — is a separate development and testing item.

Beyond that, the number of target platforms, offline requirements, real-time features and whether design is built from scratch all move the budget directly.

After a short discovery call we offer two models: a fixed-scope quote for well-defined projects, and a sprint-based engagement where scope will evolve. We publish typical budget ranges by project type as a table in our blog.

Payment is not a single transfer; it follows milestones tied to delivered work. A typical setup is an initial payment at kickoff, two or three interim payments at intermediate deliveries, and a final payment at launch.

Each milestone is attached to something concrete: design approval, the first working build, store submission. Because the schedule is tied to delivery rather than to calendar time, a delay does not leave the risk on one side only.

The discovery call and the proposal itself are free. On sprint-based engagements we invoice monthly for completed sprints, and you keep the right to stop the engagement at the end of any sprint.

Fixed price fits projects whose scope can be settled upfront: a corporate website, a well-defined internal dashboard, building an existing design. In this model the total price and the delivery date are known from the start — and in return, scope is fixed in writing too.

If the product itself is not yet validated — a new app idea, an MVP that will change direction based on user feedback — sprint-based work is usually cheaper. Fixed pricing adds an uncertainty margin to the budget from day one; in a sprint model you only pay for work actually done.

In practice many projects combine the two: the first phase (discovery and design) at a fixed price, development sprint-based. We decide which model fits at the end of the discovery call.

React, Next.js, TypeScript and Tailwind CSS on the frontend; Flutter and Dart on mobile; .NET, C#, Python and PostgreSQL on the backend.

We choose per project. If content needs to be discoverable in search, we use static generation or server-side rendering; for a dashboard used after login, client-side rendering is enough. On mobile we prefer Flutter for interface and logic-driven apps, and evaluate native where deep hardware access is required.

We use TypeScript without exception. Type safety pays off not in month one but as the codebase grows, and it is the single most practical decision for lowering maintenance cost.

Yes, in two ways. First, connecting ready model APIs — image processing, text generation, classification — to the product. Second, building the product logic around those calls: queueing, caching, cost limits and failure states.

In DrapeAI we built the image processing flow that lets a user try clothing on their own photo; in Trendela, the analysis layer that interprets portfolio data. In both cases the real work was not the model itself but what the user sees when a model call is slow or fails.

When adding an AI feature our first question is: does the product still work without it? If the answer is no, the model dependency becomes the most fragile point of the product, and a fallback flow has to be designed accordingly.

Yes. If the system exposes an API we connect directly; if not, we build an intermediate layer for data transfer — scheduled file exchange or reading through the database.

What drives the timeline in integrations is not our side but the other system's documentation and test environment. Connecting to a system with a sandbox can take a few days, while an undocumented system with only a production environment can take weeks. That is why during discovery we ask upfront for the documentation and access details of every system to be integrated.

Integrations are built with fault tolerance: when the other system does not respond, the transaction is not lost — it is queued and retried. The most common failure in enterprise projects is that this fallback was never designed.

Yes, we run the entire store submission process: app identifiers and certificates, store imagery and description copy, privacy policy links, age rating and data collection declarations.

The accounts are opened in your name — Apple Developer Program and Google Play Console memberships are registered to your company, and we are added as developers. That distinction matters: as long as the app lives in your account, control over reviews, download data and future updates stays with you.

On first submission Apple's review usually takes a few days, and a rejection on the first attempt is common; addressing the rejection and resubmitting is part of the scope. We plan the calendar so the first submission happens at least a week before the intended launch date.

Yes. We offer ongoing support agreements covering bug fixes, performance improvements, new feature development and infrastructure maintenance.

A common approach is to budget 15-20% of development cost per year for maintenance. That covers both library updates and changes in app store requirements.

A support agreement is not mandatory. Because all source code stays in your repository and architecture documentation is handed over, you can continue the project with your own team or another one.