Work with me

Bring the next engineering decision.

I work with engineers and technical founders on backend and distributed systems: reviewing a risky flow, designing what comes next, pairing on a focused problem, or establishing a startup's technical foundation.

The common shape is a bounded question, explicit assumptions, and a handoff your team can own. It is independent personal work, not sponsored or endorsed by GitHub.

Email about a collaboration See the ways to start

Start with a non-confidential outline. Do not include credentials, customer data, repository invitations, or confidential employer information. The link opens your email application; this website submits nothing.

Focus: Backend, platform, and distributed systems
Start: One decision, task, flow, or milestone
Access: Scoped non-production material by agreement
Ownership: Your team keeps review, release, and operations

Four ways to start

Start with the decision, not a package.

These are useful starting shapes, not an upsell ladder. A startup may need design before pairing; an existing system may need a review before implementation.

Working with a fund? Read the separate note for VC teams.

Inspect the public work

Evidence of the reasoning, not client case studies.

These resources show how I investigate systems, state assumptions, and turn failure boundaries into artifacts other engineers can inspect. They do not claim client outcomes for every collaboration mode.

Async Reliability Review

We inspect one messaging or background-job path and turn retry, replay, durability, migration, and ownership uncertainty into a bounded plan.

What we work through

Where attempts, effects, acknowledgements, and progress can disagree
Retry ownership, idempotency, ordering, and deadline assumptions
Replay evidence, dead-letter handling, and recovery boundaries
What the current metrics and runbooks can and cannot establish

What you leave with

A scope and assumptions map for the reviewed flow
Prioritized findings tied to evidence, impact, detection, and recovery
A recovery and replay checklist
Recommended next actions with clear ownership

Useful starting context

Redacted architecture or sequence diagrams; Retry, replay, dead-letter, and idempotency policies; Relevant dashboards, runbooks, or incident summaries; Selected code or configuration that defines the boundary.

Boundary: One existing flow. This is not implementation, incident response, a whole-platform audit, production access, certification, or on-call support.

Describe the flow by email

System Design

We turn product scenarios, workloads, constraints, and failure tolerance into a design that can be challenged before implementation locks it in.

What we work through

Requirements, constraints, workload assumptions, and unknowns
Service boundaries, state ownership, interfaces, and data flows
Alternatives across reliability, operability, cost, and team fit
Validation questions that should be answered before committing

What you leave with

A requirements and constraints brief
Architecture and sequence diagrams suited to the problem
Alternatives, trade-offs, and decision records
An implementation sequence with open risks and validation points

Useful starting context

The product scenarios the system must support; What exists today and who will build the result; Workload, reliability, budget, and timing constraints; Known dependencies and decisions already made.

Boundary: One agreed capability or system boundary. This is not architecture for the entire company, full product delivery, permanent ownership, or an untested scale guarantee.

Discuss a system design by email

Engineering Pairing

We work side by side on one bounded task: reproduce the behavior, inspect the relevant code or design, test hypotheses, and leave the reasoning with the team.

What we work through

A reproducible problem, focused design question, or implementation slice
Competing hypotheses and the evidence needed to distinguish them
Code and tests in an agreed, authorized workspace where appropriate
Knowledge transfer so the team can continue without me

What you leave with

Investigation and decision notes
Approaches tested and what they established
Agreed code or test changes where the scope permits
Unresolved questions, next steps, and named ownership

Useful starting context

A concise task or blocker; The engineers who will pair and the relevant stack; A reproduction, synthetic example, or narrow authorized workspace; What has already been tried at a non-confidential level.

Boundary: This is not unlimited staff augmentation, emergency support, ongoing availability, or release ownership. You retain credentials, review, merge, deployment, and operations.

Describe a pairing task by email

Startup Foundations

We define the smallest useful technical foundation for the next product milestone, avoiding both prototype chaos and a platform built years too early.

What we work through

The first useful user journey and the system boundaries behind it
Repository, service, data, configuration, and environment decisions
A practical baseline for tests, CI, releases, and observability
One bounded starter slice when implementation is explicitly agreed

What you leave with

A lean system map and decision record
An agreed starter slice with tests where hands-on work is in scope
A release, configuration, and observability checklist
A prioritized backlog with ownership for the next milestone

Useful starting context

What the product must do first; What exists today and who owns engineering; The next product or operational milestone; Team, time, budget, stack, and operational constraints.

Boundary: This is not the whole MVP, indefinite founding-engineer work, fractional CTO coverage, hiring, fundraising, compliance advice, or production operations.

Outline your startup's next step

How we agree the work

Scope changes are decisions, not silent expansion.

01Start with a non-confidential outlineShare the problem, the current context, and the decision or milestone. Do not send credentials, customer data, repository invitations, or confidential employer information.
02Decide whether the shape fitsWe identify the right starting mode, the technical owner, the useful boundary, and what evidence is safe and relevant.
03Agree scope before workWe agree the question, handoff, working format, access model, fees, and timing. If the question changes, we revisit the scope.
04Leave ownership with the teamThe work ends with inspectable artifacts, unresolved risks, and named next steps rather than an open-ended dependency.

The boundary belongs in the handoff.

We agree access and responsibility before work begins. An NDA does not make otherwise inappropriate material safe to share, and collaboration does not transfer operational ownership.

Shared limits

No production credentials or unrestricted repository access by default
No customer data or confidential employer material through ordinary email
No emergency support, on-call obligation, certification, or guaranteed outcome
No implied sponsorship or endorsement by GitHub

Your team retains

Credentials and access approval
Review, merge, deployment, and rollback
Production operations and incident command
Business, legal, security, and compliance decisions

A separate collaboration lane

For VC teams

I have collaborated with VCs before, mostly in a recommendation role. I am open to discussing scouting and recommendation work under an agreed remit. Scope, fit, conflicts, and timing need to be agreed before any work.

Discuss VC collaboration

Possible shape

Recommendation-based collaboration around a clearly defined focus
Scouting or sourcing conversations with explicit scope and conflicts
A bounded recommendation process with clear decision ownership

What this does not claim

My previous work is described as recommendation-based, not as a formal scout title or an investment outcome.
This is not investment advice, fundraising representation, recruiting, or an implied affiliation with a fund.
Start with a non-confidential outline; do not send confidential decks, founder identities, or deal material without an agreed process.

Before you email

A useful first message can stay short.

You do not need to choose the perfect mode. The email prompts help establish whether there is one bounded question worth scoping.

Can the work start with one decision, task, flow, or milestone?
Is there a named person who will own the result?
Can the first message remain non-confidential?
Is the desired handoff clearer than 'help with everything'?

Start here

Tell me what you are trying to build or decide.

We can decide which collaboration shape fits after the first non-confidential outline. Fees, timing, access, and the exact handoff are agreed before work begins.

Email about a collaboration josedab@gmail.com

Clicking an email link opens your email application. It does not book time, submit a form, or confirm that an engagement exists.