Frequently asked questions

You start by filling in the quote form. Describe what you want to build in your own words; we do not expect a technical specification. Within 2 business days you get a written reply: what we understood, the points we still need to clarify, and the order the work could be built in.

You do not need to prepare documents. It is enough to explain how the work runs today: which steps happen by hand, in a spreadsheet or over the phone, and what decides your prices or your queue. If you have a screenshot of a system you use, a sample form or a short note of what you need, attach it to the quote form as a PDF or Word file.

We do, and what changes is the scope. A small first version is built on the same technical foundation we use for larger systems, so your team does not have to commission a rewrite once the business grows. We also maintain our own products, which is why we talk early about who a decision will weigh on later.

Yes. We read the existing code first, separate what works from what causes trouble, and do not rewrite working parts for the sake of it. KGM SsangYong's corporate site reached us while it was live: we rebuilt how vehicle images are stored, cached the catalogue reads that repeated on every visit, and left the working sections alone. Your first deliverable is a list of what stays and what changes.

The most useful line says whether there is a running system to take over, because that single answer changes the shape of the work. After that, tell us which tasks still live in phone notes, spreadsheets or paper today, and what you expect software to change. The form also asks for a budget range and a timeline; if you do not know them yet, leave them blank.

We build custom web software, mobile apps, e-commerce, content management systems, CRM, ERP, enterprise software, business management software and process tracking tools. We also offer system architecture, software consulting and AI consulting. You do not have to decide which heading your project belongs under. In ERP our scope is operations, stock and accounting; production planning and supply chain are outside it.

We build custom software rather than starting from a theme or template. The technical foundation stays largely the same from project to project; what changes is the rules and data of your business. If an off-the-shelf product already covers what you need, we will tell you so, and we have written separately about where custom software starts to pay off.

Our default set is Laravel, MySQL and Redis, with Inertia and Tailwind on the interface and React Native (Expo) on mobile. We do not pick a new stack for each project and step outside that set only when the job calls for it: Python and OpenCV for image processing, Gemini, OpenAI and Anthropic for generative AI. A developer who takes your system over later finds a structure they recognise.

We do; the same team designs the interface and builds the software. Because there is no separate design phase to wait for, your screens take shape together with the business rules behind them. KGM SsangYong Online Store updates the price on the same screen as the buyer picks trim and colour, and checkout opens as the next step of that flow.

We can. This site runs in Turkish and English, with the copy written separately for each language. What decides a multilingual build is settling early which content changes by language and how language versions are declared to search engines. Make that call at the start and adding a second language later does not turn into a translation patch on top of your system.

That is normal; most projects span more than one heading. Describe what you need in the quote form as you would say it out loud, and we will work out which services it covers. The dental clinic CRM is one example: appointments, a treatment plan built tooth by tooth, and invoicing all live in the same system.

We start by splitting the work into parts that can run on their own. That way you see the first working piece before the whole system is finished. At the same stage we settle which part has to wait for another. The process page sets out what you receive at each stage: planning, architecture, modelling and development.

It depends on the scope, and we do not give dates before the scope is clear. What moves the schedule most is how many connected tasks the system has to run, whether there is an existing system to take over, and whether the app has to keep working without an internet connection. Put those in the quote form and we can talk timing in our first reply.

You know the rules of your business, so we need your input and decisions in the scoping and planning conversations; those cannot be skipped. How often you follow the day-to-day work is up to you. What we ask of you is not long meetings but decisions about your rules, such as when a price changes or who signs off an approval.

We scope the change again, and the work does not stop while we do. Changing a screen or a flow is usually cheap even late on; the expensive change is adding a new kind of data or rewiring how two parts of the work connect. That is why telling us early helps: we will look together at which side of the line your change falls on.

Yes. At the end of each stage you try the working screen yourself and sign it off. Pushing back on something you can click is far easier than picturing a written description of it. We do not write weekly progress reports; what we put in front of you for approval is the working screen itself.

Scope sets the price: which services the work includes and how much each of them carries. The proposal is broken down into those items, so you can read line by line what is included and what is not. If you tell us up front about a part you do not need, such as online payment or stock tracking, that item never enters the proposal.

You can, once the scope is clear. We do not put a number on a scope that is still moving, because that number would not hold. What makes the scope clear is a list of what the system has to do and which information it has to keep. You can write that in the project step of the quote form and mark your budget range there too.

We do, for systems that keep evolving once they are live. With an ongoing arrangement you are not opening a fresh scope every time something small has to change. Tell us which part of your system you expect to change most often, and we will shape the arrangement around it.

Nothing is hidden, but some costs are paid to providers rather than to us, and the proposal names them. Hosting, the domain and generative AI usage are billed to you directly by the provider; we do not sit in between. A request outside the agreed scope is never added quietly either; it becomes a new item we discuss. Tell us which of these you already have, and the proposal will not count them twice.

We have no office, and the work runs on written decisions and a shared code repository. Decisions are written down, milestones are agreed up front and the repository stays open to you, so you can see progress without waiting for a meeting. We shape the working rhythm around your team in the first conversation.

We work on Turkey time. The working hours within the day are set per project, and milestones plus written updates mean progress does not depend on you and us being online at the same hour. Tell us on the first call which hours you need replies in.

Through written updates. Each update says what is finished, what comes next and which decision is waiting on you, so you never have to call anyone for a status. When you see a decision waiting, answering it is all we need from you.

Turkish and English. Whichever you open the conversation in is the one we continue in.

We can, and we set the schedule together. There is no daily stand-up, because you follow progress through written updates and we keep calls for questions that need a decision. With no office, we do not offer on-site installation or field training either. Write the rhythm you want into the quote form and we will hold it from the first week.

We do. Maintenance runs as its own scope, and new features are scoped separately. Keeping the two apart means your maintenance budget never quietly turns into a feature budget, and you can see which piece of work was paid from where. The proposal lists what maintenance covers, item by item.

You do, and the handover is done as a list. It covers the code repository, the database schema and the file storage layout, so you hold everything needed to run the system without us. The contract names every item on that list.

Yes, and we set the build up on that assumption from the start. Our projects follow the same file layout and setup, so a developer taking over starts by reading code rather than learning a new structure. Bring your developer to the first call and let them ask their own questions.

If the bug breaks behaviour we tested, fixing it is on us, with no new scope attached. What was tested is written down at handover, so you do not have to guess where that line sits. Tell us the screen where it showed up and what you expected to happen; we open the ticket.

Yes. After launch the same team keeps working on the same system, and later work is scoped the way the first build was, so growing the product does not mean finding another agency. When you describe the scope in the quote form, write down where you want the product to be a year from now; we plan the next version from there.

The KVKK Notice sets out in a table which personal data we process, why and for how long. You can read there why each field is asked for. The quote form asks you to accept the Terms of Use and to confirm you have read the Notice, as two separate ticks. The version of each document you agreed to is recorded with the time you agreed.

Yes. Neither your name nor any detail of your project appears on this site without your approval. The 21 case studies and 10 client names on this site are everything we publish. What you type into the quote form stays in the notification we receive and never becomes a project page or a marketing line. We ask you separately, once the work is done, whether your name can go up.

They are stored in a private directory that the web server closes to the internet, and are deleted automatically once the retention period ends. No web address reaches them, so a document you send us cannot surface in search results. The form accepts PDF and Word only, refuses more than 5 files or any file over 10MB, and checks the type from the content, not the extension. If the work goes ahead under contract they move into the project record; if not, the cleanup job removes them.

You do. The code we write for you transfers to you, and the contract you sign sets the extent of that transfer. That means you need no permission from us to hand the system to another developer later. The open source components underneath were never anyone's private property, so they are the one part that is not transferred. You see which right sits with whom in writing, before anything is signed.

It is. Every field that arrives through a form is validated again on the server, and nothing the browser sends is taken on trust. Our own quote form shows this in practice: a submission that fails the bot trap, the check running on our own server or either of the two consent ticks never reaches us. We use no third-party captcha, and Google Analytics runs for visit measurement only if you accept it in the cookie banner.