Founding Engineer, Systems & Infrastructure

About Byteport

Byteport builds file-transfer infrastructure for developers. We move large datasets between object stores, cloud services, and customer-controlled endpoints, including the networks where ordinary transfer stacks become slow or unreliable.

We are a YC W26 company based in San Francisco. The team is small, technical, and close to the work. Customers should be able to connect a source, choose a destination, and move data without assembling a Netflix-sized infrastructure stack first.

The role

We are hiring a Founding Engineer to own the systems behind Byteport's transfer API and DART data plane.

A request can start this simply:

json
{
"operation": "copy",
"from": "Production Bucket/archives/2026-04-21",
"to": "Azure Archive/incoming/"
}


Your job is to make the distributed work behind that request safe, observable, and fast. A cross-cloud transfer may look like:

text
S3 -> source transfer node -> DART -> destination transfer node -> Azure


This is not a narrow backend role. You will work across the control plane and data plane, from protocol internals and transfer execution through APIs, connectors, production operations, and customer integrations.

What you will own

• Build and improve Go-based transfer nodes that move bytes between cloud, SSH/SFTP, local, and customer-controlled storage.
• Turn API requests into durable distributed jobs through path resolution, planning, scheduling, node selection, dispatch, state machines, retries, and recovery.
• Build production-grade connectors and connection pools for object storage, SSH/SFTP, HTTP/TLS clients, and node-to-node sessions.
• Design resumability, checksums, verification, backpressure, adaptive concurrency, credential isolation, and idempotency into the transfer path.
• Measure and improve throughput, latency, bandwidth use, memory behavior, and small-file performance in production.

You will also operate what you build. That includes telemetry, dashboards, incident debugging, deployment safety, and the occasional customer problem that refuses to reproduce in a clean environment.

The kind of problems you will solve

One recent problem was extending an internal server-to-server handshake so nodes could exchange cryptographic key material for encrypted data blocks in transit.

A strong engineer here would turn that prompt into:

• an architecture and threat model
• an implementation plan
• tests and failure cases
• metrics and operational visibility
• a safe rollout plan
• explicit tradeoffs and next steps

The exact task will change. The expectation will not: reduce ambiguity, find the risky edge cases, ship the complete system, and verify it in production.

You will likely be a strong fit if you

• Have shipped and operated production systems in Go or another systems language.
• Understand distributed systems, networking, Linux, concurrency, and cloud infrastructure well enough to debug them under pressure.
• Have built APIs, SDKs, workers, schedulers, agents, proxies, storage systems, or queues used by real customers.
• Can reason about retries, leases, fencing, checkpoints, idempotency, backpressure, and connection pooling.
• Know how to benchmark a system, profile the bottleneck, and prove that a change improved it.
• Can read a storage provider's API documentation, build the connector, and make it production-ready.
• Own architecture and implementation instead of handing one side to somebody else.

Experience with S3, Azure Blob, GCS, SSH/SFTP, gRPC, messaging systems, Postgres, Kubernetes, OpenTelemetry, Prometheus, or Grafana is useful. You do not need to know every provider on day one.

Strong backgrounds include former technical founders, early infrastructure engineers, and people who have built developer tools, storage, networking, databases, observability, security infrastructure, or on-prem agents.

How we work

This is an in-person founding-team role in Hayes Valley, with some work-from-home flexibility. You will work directly with the founders, own large parts of the system, and make decisions without waiting for a committee.

We move quickly, communicate directly, and expect engineers to ask hard questions when a task is underspecified. Critical releases or incidents may occasionally require off-hours work. We say that plainly because the right person should know what they are signing up for.

This role is probably not a fit if you want remote-first work, a narrow ticket queue, a design-only position, or an implementation role with no operational ownership.

Why this role matters

The transfer path is the product. Its speed, correctness, and reliability determine whether Byteport can move customer data across different storage systems without making developers manage the complexity themselves.

You will help define that infrastructure from an early stage and have a credible path to leading it as the company grows.

How to apply

Apply by reaching out to mysel, Alex Newiger, or Jayram Palamadai on LinkedIn directly and connecting with us

Also complete the application in Wellfound. In your note, tell us about one production system you owned: what it did, what broke, and how you measured the fix. Links to code, technical writing, or a shipped project are welcome when the work is public.