Qaynaq STUDIO ’26 / BAKU
S.04 · Engineering

TypeScript, Node.js, Postgres, Cloudflare. Test coverage 80%+, CI/CD wired, documented architecture. Duration scoped per project.

Duration
scoped per project
01

What you get

  1. 01

    Architecture document

    Architecture decision records. Every consequential choice — why Postgres over DynamoDB, why server actions over tRPC — written down. A new team member ramps up by reading the doc, not by interrogating the previous engineer.

  2. 02

    CI/CD and monitoring setup

    GitHub Actions or GitLab CI. Every PR runs lint, typecheck, tests, build, lighthouse. Production deploy is automated. Monitoring through Sentry or Better Stack with documented alert rules.

  3. 03

    Full test coverage (unit + integration + E2E)

    TDD by default — test first, then implementation. Vitest for unit, Playwright for E2E. Eighty-percent coverage — not an inflated number, a real quality signal.

  4. 04

    Handover sessions for the partner's team

    Two-hour recorded sessions: architecture walkthrough, deploy flow, reading monitoring dashboards, incident response. The recordings stay with you.

02

How we approach it

1. Skeleton search first

We look for existing solutions before writing new code. GitHub search, package registries, primary vendor docs. If a battle-tested option exists we adopt it. We write from scratch only when the gap is real. This is the most-skipped step in the local market — and the cheapest source of value.

2. Decisions go into ADRs

Every consequential decision lands in a written record: context, choice, accepted alternatives, rejected ones. This is how you give the right answer to “why this?” six months from now.

3. Test-driven implementation

Test first, code second. It is not slower — it is the faster shape over a six-month horizon. Coverage holds across features, not on day one only.

4. AI tool, human review

AI is used as a tool to write code. Every commit still goes through human review. “AI wrote it, I didn't read it” is not acceptable here. That mistake is widespread in the AZ market — we reject it openly.

03

When not to hire us for this

  • It's a one-or-two-day task — we don't take scopes that small. The minimum is a sprint.
  • You want to keep building on an old PHP / WordPress codebase — we rebuild on a modern stack, legacy maintenance isn't our service.
  • There is no clear spec or prototype yet — that is a design/strategy gap on your side; engineering can't close it for you.

If you have a real engineering problem and want help solving it, send a short brief — stack, problem, timeline.

salam@qaynaq.com