FAQ - The details before we start.

No. Bring the outcome you want, the problem you are seeing, or the existing codebase. We will turn that context into a clear first request and agree what done means before development starts. You keep product direction; we make the engineering path concrete.

Yes. We start by understanding the stack, conventions, deployment setup, and the part of the product your request touches. Changes land in your repository as reviewable production code rather than in a separate black box.

SaaS products, portals, dashboards, APIs, integrations, billing systems, infrastructure, refactors, and post-launch product work are a strong fit. We are code-first: brand identity, campaign copy, open-ended product strategy, and 24/7 on-call operations are not included unless a written proposal says otherwise.

We agree how often reviewable work should arrive before development starts. That turnaround applies to one active, scoped increment. You can keep as many requests as you need in the queue, but only one increment is in development at a time.

Product features, APIs, integrations, billing, portals, dashboards, infrastructure, refactors, and post-launch improvements. Add the full outcome even when it is large. We keep it visible as a parent ticket and break the delivery work into smaller subtasks.

Yes. Submitted work stays in a queue you can reorder. We take the highest-priority ready item into active development; changing the queue does not require a new quote or a status meeting.

We keep the full request as a parent ticket, then propose smaller subtasks that each produce a reviewable result. You approve the sequence before the first subtask starts. Completed subtasks update the parent's progress, and you can reprioritize the remaining work.

The clock starts when one scoped increment enters active development and the access, decisions, and client materials it needs are ready. It pauses while we wait for review, answers, access, or another client-side dependency. The next increment gets its own target when it becomes active.

Yes. devkyn can invite the teammates you authorize. Members can see the shared delivery board, add context, comment, reorder submitted work, and approve or request changes when an item reaches review.

Nikolai, devkyn's founder and lead engineer, stays directly involved in every engagement. Your work is not handed to a junior learning on your codebase.

You do. Work is delivered into your repository and, when deployment is in scope, into infrastructure and service accounts you control. There is no proprietary wrapper required to keep the product running after the engagement ends.

When an increment is ready, it moves to Your review with the implementation context you need. Approve it, or request changes with a note. In-scope revisions return to the delivery queue with their context intact. The clock pauses while the item is waiting on your review or another client-side dependency.

Testing follows the risk and the codebase. We add automated tests for behavior that should not regress and run focused manual checks on the changed flow. We agree project-specific browser, device, performance, and security requirements before work starts instead of promising a meaningless coverage number.

Yes when it is part of the agreed scope. We can configure staging, CI, and a repeatable release path in accounts you control. You review the work before release; we do not silently push a change into production. If your team already owns deployment, we deliver reviewable pull requests into that process instead.

No recurring meetings, standups, or status calls. The board handles priorities and progress asynchronously. We schedule a focused call only when a decision is genuinely easier to make live.

Each request keeps its description, comments, status, and review decision together on the board. That gives your team one durable record instead of scattering delivery context across meetings and private messages.

It is a flat monthly subscription. The exact rate depends on the scope, capacity, and support the work needs. We put the price, billing schedule, and start date in your proposal before you commit.

Yes. There is no long-term subscription commitment. The notice timing, current billing period, and any project-specific commitments are confirmed in your proposal or order form so the commercial effect is clear before you start.

Pause or cancel the engagement when there is no ready work. You can resume when the roadmap fills up again, subject to current availability.

Raise them on the sales call. Payment method, invoicing details, tax treatment, purchase orders, and any vendor onboarding requirements are confirmed in the written proposal rather than assumed from the website.

Tell us before sharing confidential material if an NDA is required. The appropriate NDA or confidentiality terms must be reviewed and signed before access is granted. Confidentiality obligations for the engagement belong in the signed agreement, not only in a website promise.

We ask for the minimum access needed for the active work, prefer named accounts over shared credentials, and work in systems you control. Any engagement-specific security, data residency, regulated-data, or access-review requirements must be agreed before that data or environment is accessed.

You keep the repository, work history, documentation produced for the agreed scope, and the infrastructure in your accounts. We remove or return access as agreed and can provide a focused technical handoff for your team or next engineer.

No. They explain the standard way devkyn works. Your signed proposal, order form, or services agreement defines the exact scope, commercial terms, responsibilities, and any project-specific commitments, and it controls if something differs from this website.