Thirty questions, answered in full.

With a brief — a short call or an email describing the task. Within 3–5 days we come back with an architecture, a stage plan and a firm quote, and that stage is not billed.

What the business does, who will use the system, what is currently done by hand and where the data lives today. Examples of systems you like, and of systems that annoy you, are worth more to us than a finished specification. We pull the rest out with questions.

One responsible person runs the project and answers your email. The people doing the work change by stage — design, build, testing — while your point of contact does not.

Baku is UTC+4, which shares a full working day with continental Europe and a long morning with the UK. Written updates land in the tracker daily, and demos are booked to your clock rather than ours. The working language is English throughout: the brief, the documentation, the code comments and the release notes.

Yes, on request and before the brief. The NDA is already in force during the estimating stage.

An hour buys you a range. In 3–5 days we take the process apart, count the roles and the integrations, and check whether the services you depend on actually expose an API. Sometimes that is where it emerges that one of them does not. What arrives at the end is an architecture, a stage plan and a quote we then hold to. Those few days save weeks.

A working demo — a version you can open and click through yourself. Sprints run two weeks.

Sometimes, though never in proportion: on a small team, bringing someone new in eats the time of whoever is doing the bringing. Cutting the scope of the first release is usually quicker. On the brief we show you what can wait for a second pass.

You do, at the demo. Done means the scenario runs end to end on a working version, not that a developer closed a ticket.

You hear about it at the next demo, not on the deadline. Two options follow — move the date, or push part of the scope to a second pass — and the choice is yours. Nothing slips quietly: the tracker is yours, and it shows where the work stopped.

The word “site” covers a week-long landing page and a six-month platform. A number quoted in a vacuum would be a lie to one of them.

The number of roles and permissions, the number of integrations, the volume of data to migrate and how complex the reporting is. Mobile is a line of its own: whether responsive web is enough, or a separate app is needed. Every service page breaks this down under “What moves the quote”.

An agreed quote does not move. Only what you add on top of the scope costs more, and that is written up separately — with an estimate, and with your approval before anyone starts.

By bank transfer against an invoice, in the stages fixed in the contract: each stage ends in something you can look at, and is paid once you have looked. The estimating stage is never invoiced. We contract with companies and with sole traders alike.

Yes, and it is a sensible move rather than a concession. On the brief we split the scope into what has to ship and what can follow — and the second list is often the longer one.

You do. The repository is created in your account on day one rather than handed over at the end. You receive the code, the documentation, the deploy and rollback scripts, and access to every service the system touches.

Yes, in the contract, and it covers everything produced for the project: source code, design files and documentation. Third-party libraries keep their own open-source licences, which is what makes them usable at all. We retain no right that would let us resell your build to anyone else.

By the task, and by how long the product has to live. We do not pick a technology nobody in Baku could maintain after us.

You hand them the repository and the documentation — you have both already. We keep no access to ourselves and charge nothing for the handover.

On infrastructure registered to you: your server, your account with the provider, your domain. If the data has to stay inside a particular jurisdiction, say so on the brief. That is a decision far cheaper to make before the architecture than after it.

A description of the architecture and the data model, an API reference, an admin guide and short videos covering the routine operations. Alongside them, the deploy and rollback scripts, with a note on what to do when a release goes wrong.

Monitoring, bug fixes and small corrections — three months from release, at no charge. A bug means the system does not behave the way the specification says it should. A new feature is not a bug, and is quoted separately. The warranty starts on release day.

The warranty runs three months and covers bugs. Support is a plan for growth — new features, changes to the process, scheduled updates — and it begins once the warranty ends and is paid for separately.

Monitoring alerts us, not you. Through the three warranty months we respond and fix it; after that it runs on the terms of the support plan.

Yes. The repository, the documentation and the deploy scripts are yours throughout, so a handover is onboarding rather than migration. Say so on the brief and we will keep the stack close to what your developers already know. We can also run the first weeks alongside them, answering questions against the real codebase.

You do, directly to the provider. We do not resell hosting and add no markup — the invoice goes to you, and the access stays with you.

When an off-the-shelf tool closes the task and a custom build will not pay for itself — that shows up on the brief, and we say so. When the process changes every month, because a system would set yesterday’s version of it in concrete. And when the task sits in a field we have no experience in.

No — we work under a contract with a fixed scope and payment by stage.

We do, when it is a finished piece: one integration, one form, one report. An hour or two of edits inside someone else’s code is not our format, and we will say so on the brief.

Yes. We audit the code and the architecture and hand back written findings: what works, what will have to be rewritten, what is missing. The audit does not commit you to changing team; sometimes the finding is that you should not.