all

This page answers the practical questions clients most often ask before starting work with Techpipe. For the complete engagement process, see How We Work. For access controls and security options, see Working with Your Infrastructure.

Starting the conversation

Who does Techpipe work with?

Techpipe is a DevOps agency working with product companies, web and development studios, and boutique digital agencies across the globe.

We are usually brought in when a team needs experienced infrastructure engineering without immediately building or expanding an internal platform team.

What happens during the initial assessment?

We review the problem, relevant technical context, and the constraints around it. Depending on the task and what you are comfortable sharing, this can include:

  • an architecture diagram;
  • relevant documentation;
  • selected repositories or CI/CD configuration;
  • monitoring data and incident history;
  • a list of current problems, risks, or bottlenecks.

The objective is to understand enough to arrange a useful engineer-to-engineer conversation and define a safe, limited pilot are not to request unrestricted access or run an open-ended discovery programme.

Is the initial assessment free?

Yes. The initial information review and interview with the proposed engineers are free. The technical pilot that follows is paid.

How quickly can a pilot be prepared?

The usual time from the first conversation to a pilot-ready proposal is one to two weeks, depending on the availability of materials, the complexity of the problem, and the time needed to agree on scope and security requirements.

Do we need to disclose our complete infrastructure?

No. We start with the minimum information needed for the specific problem.

Documentation, selected configuration, sanitized data, exported monitoring information, a non-production environment, or a narrow read-only view may be sufficient. The pilot scenario is selected together so that you can evaluate the team with the smallest practical disclosure.

Engineers and communication

Who will we meet before the pilot?

You meet the engineers proposed for your work. They participate in the technical assessment, help define the pilot, deliver it, and remain the primary engineers if we continue into a long-term engagement.

This keeps technical information direct and reduces the delays and misunderstandings that can occur when communication passes through a separate sales or account-management layer.

Can we interview the engineers?

Yes. The format is up to you: it can be an introductory technical conversation, a detailed discussion of your environment, or a fuller technical evaluation.

Can we approve or reject an individual engineer?

We propose and qualify the delivery team as a whole. You evaluate that team during the interview and may decline it before the paid pilot if it is not a fit.

Will the same engineers remain after the pilot?

Yes, the engineers introduced for the pilot remain the primary team for the continuing engagement.

If a future staffing change becomes necessary, its timing, replacement, knowledge transfer, and access changes are discussed with you rather than handled as an invisible substitution.

How is communication organised?

The working channels, meeting cadence, reporting format, ownership, and escalation path are agreed before work begins. Technical questions can be discussed directly with the assigned engineers.

For ongoing work, we adapt to a practical combination of your existing communication and issue-tracking tools rather than requiring a separate process solely for Techpipe.

The paid pilot

Why start with a paid pilot?

A pilot lets you evaluate the actual team, technical approach, communication, security discipline, and delivered result before granting broader access or creating a long-term operational dependency.

It also gives Techpipe enough evidence to decide whether we can support the environment responsibly.

How long does a pilot take?

The duration is defined individually. We deliberately keep the scope small enough to remain understandable, measurable, and low-risk.

How much does a pilot cost?

Pricing is based on the agreed scenario, scope, duration, access requirements, and deliverables. The price is agreed before work begins.

What tasks are suitable for a pilot?

Typical examples include:

  • improving one CI/CD workflow;
  • setting up or correcting observability for a defined component;
  • auditing a limited infrastructure area and implementing an agreed improvement;
  • migrating one service or workload;
  • removing a reliability bottleneck;
  • validating backup and restore procedures;
  • resolving a specific infrastructure, deployment, or operational problem.

The pilot should address a real need, but it does not need to expose the most sensitive part of your environment.

Must the pilot produce a production-ready change?

No. You define the useful result.

It may be a production-ready implementation, a validated technical change, a decision with supporting evidence, an audit with a practical remediation, or another concrete outcome agreed in advance.

What do we receive at the end?

The handover depends on the pilot. It may include:

  • code or Infrastructure as Code;
  • documentation;
  • an architecture diagram;
  • a runbook;
  • a technical report;
  • measurable before-and-after results.

The exact deliverables and acceptance criteria are recorded before the pilot starts.

How do we decide whether the pilot succeeded?

We agree on the criteria in advance. They normally cover:

  • completion of the agreed scope;
  • timing;
  • quality and clarity of communication;
  • the intended technical result;
  • compliance with the agreed security requirements.

Are we required to continue after the pilot?

No. The pilot is a complete engagement of its own and creates no obligation to sign a long-term contract.

If either side decides not to continue, we hand over the agreed results, document the final status, and remove any access that was provided.

Security and infrastructure access

Is production access required for the pilot?

Not necessarily. We prefer to design the pilot around documentation, selected configuration, sanitized data, isolated environments, or narrowly scoped access whenever that can produce the agreed result.

If production access is genuinely needed, its purpose, duration, permissions, connection method, and approval process are agreed before it is provisioned.

Will Techpipe sign an NDA?

Yes. An NDA can be signed before sensitive technical or business information is shared.

An NDA complements not replaces data minimisation, least-privilege access, named accounts, and controlled handling of credentials.

What security controls can be used?

We work with controls appropriate to your environment, including:

  • named user accounts;
  • multi-factor authentication;
  • role-based and least-privilege permissions;
  • privileged or just-in-time access;
  • VPN or bastion-based connectivity;
  • privileged access management;
  • managed secrets and short-lived credentials;
  • access logging, review, and revocation.

The precise control set is agreed for each engagement. See Working with Your Infrastructure for the complete approach.

Do you need permanent administrator access?

No. Administrative access is not a default requirement.

Where elevated permissions are necessary, they can be limited by system, role, task, time window, approval, and connection path. Just-in-time elevation or client-operated changes may be used instead of permanent privileged access.

How is access removed?

Access is reviewed when responsibilities change and revoked when it is no longer needed. At the end of a pilot or contract, assigned accounts, roles, active sessions, VPN or bastion permissions, tokens, and relevant secrets should be disabled or rotated as part of an agreed offboarding checklist.

Long-term work

What engagement models are available after the pilot?

Depending on the work, the next engagement may be:

  • Monthly infrastructure support for ongoing maintenance, improvements, and operational assistance;
  • Project-based delivery for a defined migration, platform change, reliability initiative, or technical outcome;
  • SLA-based managed service with agreed coverage, responsibilities, response targets, and escalation rules.

Do you offer 24/7 support?

Yes, it is possible, though coverage is not assumed. Support hours, response targets, on-call responsibilities, incident roles, and escalation paths are agreed individually and recorded in the contract or SLA.

Is there a long minimum contract?

Monthly support can be ended on a monthly basis. The exact notice period, final handover, access removal, and any service-specific commitments are recorded in the agreement.

Can Techpipe work with our internal team or another provider?

Yes. Responsibilities and system boundaries are defined explicitly so that your internal engineers, Techpipe, and any other provider know who owns each action, decision, escalation, and handover.

Where can we see the services you provide?

See our services for technical capabilities. This section focuses on how we qualify the team, control risk, and structure the working relationship.

Have another question?

Tell us what you are trying to improve and what constraints matter most. We will identify what can be assessed without production access and arrange a conversation with the engineers proposed for the work.

Request an initial assessment