Elijah Skeirik · Developer experience engineer

I work backward from the person who has to use it.

That might mean correcting an API contract, fixing an SDK, rebuilding a documentation path, or making an internal tool usable by somebody who has better things to do than learn its quirks.

I publish open-source work as Elias Michaias.

Get in touch GitHub LinkedIn

Current work: Developer experience at Payabli
Across my desk: APIs, SDKs, documentation, UI, and internal tools
Away from work: Language design, philosophy, systems, Greek, and Latin

Professional experience

My titles have changed less than the work has. Both roles put me close to the people using what I built and far from the luxury of saying a problem belonged to another department.

Payabli

Developer experience

Jun. 2024–Present

I help own an API platform’s public surface across docs, contracts, SDKs, interfaces, and developer outreach. You can see that work in Payabli’s developer documentation.

Maintain developer documentation and the OpenAPI specification as living product surfaces, not end-of-sprint artifacts.
Maintain custom server SDKs across eight languages and work through the awkward differences between their ecosystems.
Investigate API drift and verify the contract between production behavior, the specification, generated surfaces, and docs.
Design and implement accessible, responsive UI components that make the documentation journey easier to navigate.
Build and maintain internal tools that turn recurring checks and editorial work into repeatable systems.
Work directly with developers, carry their friction back into the product, and close the loop with documentation or code.

Mr. Electric

Full-stack engineer and generalist

Sep. 2023–Jun. 2024

Small-team software with a broad remit, direct customer contact, and no room for “another department.”

Built a TALL-stack and Filament admin system for interactive internal workflows used by non-technical staff.
Scaffolded and maintained the SQLite database, including schema changes and migrations as those workflows evolved.
Aggressively optimized accessible interfaces so the important paths worked well for the company’s actual target market.
Went out to jobsites and spoke directly with paying customers to find friction in the site’s user journey.
Turned field observations and customer conversations into changes across the website, internal tools, and marketing.
Handled branding and marketing alongside the technical work, keeping the public presentation and internal system coherent.

Technologies I work with

Languages and tools I have used to ship work, study a problem, or build something that did not exist yet.

languages

interfaces

tooling

How I work

Websites, documentation, APIs, SDKs, and compilers fail in different ways. The habits below have held up across all of them.

People need a model, not a ritual.

A guide that only works when every step is copied exactly has not explained much. I want the underlying shape to be visible.

In practice: Clear contracts, Useful defaults, Precise language, Discoverable systems, Honest abstractions.
I want the unfiltered version.

Support threads, jobsite conversations, broken integrations, and confused first attempts tell me more than a tidy internal summary.

In practice: Direct feedback, Workflow research, Developer outreach, Field context, Short feedback loops.
Accessibility and errors are product work.

The awkward path is still part of the product. So are a slow page, an unreadable control, and an error message that explains nothing.

In practice: Accessible UI, Responsive design, Performance, Useful errors, Fit and finish.