Frequently asked questions

The ODIN337 team connects design, development and launch. Team composition and responsibilities are agreed around the project. Founder Danila Roshchupko provides technical leadership.

We agree stages, communication and acceptance criteria before work starts. Read about the team.

With a brief. Use the form on the contact page to say what the product is, what state it is in and what has to change. That is enough for a substantive answer instead of “let’s get on a call”.

Then comes scoping: a range, and a written list of what the range does not cover. Work does not start before that list is agreed — it decides how a project ends far more reliably than the estimate does.

Yes. Requests arrive in one of two shapes, and the second one is an existing product that has grown slow, breaks on every edit and no longer describes the business behind it. What that work covers is written out with the rest — services.

It starts with an inventory rather than with edits: what is deployed, by whom, where the data physically sits, and what happens if it stops answering tomorrow. Until those have answers, any estimate for a rewrite is guesswork, and I will call it guesswork.

Yes. Several entries in selected work are published exactly that way: the problem, the approach and the stack are described, the client is not named.

If the agreement rules out even that, the project never appears on this site at all — neither named nor anonymised.

A landing page takes 3–5 working days, a company website 7–12, and a shop or portal 15–25. Apps and complex platforms are delivered in stages; the base windows are on the project estimate page.

Scope, stages and calendar dates are agreed before the work starts. The windows include responsive layouts, testing and launch; waiting for your materials, access and approvals is separate.

Yes, by defining the first useful release and agreeing priorities. We review essential workflows, content readiness and integrations, then propose a realistic launch plan.

Urgency, extra scope and calendar constraints are considered in an individual proposal. Discuss the project.

Tell us what you want to launch or improve. We clarify goals, workflows, integrations and timeline, then prepare an individual proposal. There are no public prices or universal rates on this site.

Scope, stage deliverables and cost are recorded in the contract before work starts. How we scope a project.

No. A contact and a few sentences about your project are enough to begin. We help define workflows, constraints and acceptance criteria.

If designs, documentation or a working product already exist, we review them and account for them in the proposal.

Cost and payment terms are agreed individually and recorded in the contract. Staged projects have agreed deliverables and payments for each stage.

Payment details are provided on the invoice. Legal registration details are on the team page.

No. The operator is a Russian tax resident, and article 14(5) of 259-FZ bars persons in that position from accepting digital currency as consideration for services — from any client, domestic or foreign. That is a prohibition, not a studio preference.

The accepted methods are listed on the project estimate page. We agree on payment terms before work begins.

A contract, an invoice per stage, and a receipt for every payment. Contractor details are on the about page.

One boundary is better known before the invoice than after the payment: the closing document here is a receipt, and no VAT invoice is issued against it. If your accounting requires one, that is settled while the scope is being agreed, not once the invoice is out.

After launch we can arrange support: updates, monitoring, fixes and new capabilities. Scope and response times are agreed around your product.

A retainer is optional. Declining one does not turn the product into a black box — everything needed to run it yourself is handed over at delivery either way.

Straight to a server in Russia. The submission is first stored in PostgreSQL on our Moscow server. The email notification goes out after that write, not instead of it.

A lead is kept for 365 days and then destroyed on a schedule. Every recipient of the data is named in the privacy policy — by legal name and registered address, as article 9(4)(6) requires.

Email the address published in the privacy policy. The answer comes within 10 working days — a deadline set by article 20(1) of 152-FZ, not by studio policy.

Withdrawing consent stops the processing and deletes the lead from the database. There is deliberately no one-click button for it: an email leaves a record on both sides, a button leaves one only on mine.

Not without your consent. No third-party analytics loads by default: the banner asks once, and the decision can be changed at any time on the cookie page.

Declining breaks nothing — the pages are static and behave identically either way. There is one counter, a Russian one; no foreign trackers are loaded at all.

No. Leave a contact and a few words about your project. Background spam protection works without an external widget.

If submission fails, the form keeps your text and offers a retry or a direct contact channel.

Yes, and it is a line item rather than a side effect of where the servers happen to be: a dedicated perimeter where the primary write of personal data lands on Russian infrastructure before anything else touches it, as article 18(5) requires. The work is described under infrastructure and priced on the project estimate page. On the international market the same line buys something different — residency inside the EU, plus the records and procedures GDPR asks for.

Two boundaries, stated up front. First, that reads “what GDPR asks for”, not “GDPR-compliant”: compliance is a property of an organisation and of all its processing, not of a delivery, and promising it would mean speaking for your company. Second, the perimeter has a recurring half, and it is not hosting with a margin on it — it pays for restores actually tested, for the list of data recipients kept true, and for a subject request answered inside the statutory deadline. A perimeter built once and then left alone stops being a perimeter within a year. What it looks like in practice is visible on this site — privacy policy.

A repository with its commit history, not a zip file. Accounts and credentials issued in your name. Instructions for building and deploying. On infrastructure work, a runbook and at least one restore-from-backup performed together with you.

The full handover list is written out per service on the services page — before the contract is signed, not in an annex to it.

That gets tested before the work ends, not after. The stack is public and conventional; nothing proprietary that only I know how to deploy goes into a project.

Handing the product to another team is a matter of access and documentation, not a series of calls with me. If a project needs my phone number to build, it has not been delivered.