A one-person practice, deliberately.

What I do

Gulf & Ponte is Yared Asefa, working from Seattle. The work is getting structured information out of systems that were not designed to hand it over, and moving it reliably to where it needs to land — with a person reviewing the result before it counts.

• Document-processing pipelines
• API and systems integration
• Structured-data extraction
• Workflow orchestration
• Review and exception handling
• Operational documentation
• Auditability

That means mapping what your firm actually does today rather than what the process document says, building the connections between the systems that already hold the work, and making the failures visible instead of quiet. The last part is the one that decides whether a workflow survives its first busy season.

The engagement is deliberately shaped so you can predict it. Scoping produces a written scope and a fixed fee. Acceptance criteria are agreed before anything is built. Thirty implementation days follow, starting once access and approvals are in place rather than on the date you sign.

• One scoping conversation, then a written scope and a fixed fee.
• Acceptance criteria agreed in writing before implementation starts.
• A workflow owner at your firm, involved throughout rather than at the end.
• Weekly contact during implementation, not a silent month.
• A handoff session, a runbook, and an access inventory at the end.

You are working with the person doing the work, so there is no account manager relaying questions and no gap between what was promised and what gets built.

Software vendors sell capabilities and offshore providers sell hours. Neither will wire your portal to your practice-management system to your model provider, because that work does not generalize and so it does not fit either business model.

It fits this one. A one-person practice can afford to build something that works for exactly one firm, which is the only way this layer gets built at all.

Engaging a practice of one is a real risk. These are the things that contain it, and they are structural rather than reassurance:

• Narrow scope: one workflow, named systems, named document types.
• A fixed fee, agreed after scoping and before implementation.
• Acceptance criteria written down before anything is built.
• Production accounts under your control where the architecture supports it.
• A runbook and an access inventory delivered as part of the work.
• Ownership and transition terms defined in the statement of work.

Each engagement defines the operating documentation, access model, handoff, and transition terms appropriate to the workflow. A runbook reduces dependency but does not eliminate key-person risk.

There is not one yet, and inventing one is not an option. What the site offers instead is a written account of how an engagement is bounded, priced, accepted, and handed over, so you can evaluate the terms rather than a claim.