Technical ownership · Remote, UTC−3
Hire a technical lead
who still ships
the hard parts.
I take on the architecture and the implementation for systems where performance, reliability, or release complexity is holding a product back: matching engines, workflow engines, real-time data, and the teams that run them. Available for full-time, contract, and advisory work.
Ways to work together
Start with the scope.
Choose the right format.
Full-time
Staff Engineer / Technical Lead
Own a meaningful technical area, align engineering decisions with product priorities, and help the team deliver. Best suited to roles with hands-on architecture and implementation responsibility.
Discuss team scope, decision authority, total compensation, and remote setup.
Contract
Focused engineering ownership
Take a defined system or delivery constraint from diagnosis through implementation: performance work, an architecture migration, or a complex product capability.
Discuss the outcome, existing team, timeline, and budget for delivery.
Advisory
Architecture & technical direction
Work through a consequential technical decision with your team. Review constraints and alternatives, surface the tradeoffs, and define a practical implementation path.
Discuss the decision, available evidence, and the depth of support needed.
| Format | Typical length | Best for |
|---|---|---|
| Full-time | Ongoing | A product with hard performance, reliability, or delivery problems and a team that needs someone to own them. |
| Contract | 6 weeks to 6 months | One system or one constraint: a matching engine, a workflow engine, a migration, a throughput ceiling. |
| Advisory | A few sessions to a few weeks | A decision the team cannot afford to get wrong, before the code is written. |
How an engagement starts
The first thirty days.
The pattern is the same whether I join full-time or on a contract. Measure before proposing, write the plan down with numbers in it, and ship something real inside the first month with the people who will own it afterwards.
- Week one: read and measure. I read the code, the incidents, and the metrics before I form an opinion. If there is no benchmark for the system in question, I build one. On a matching engine that meant timing the same command path at four different boundaries; the numbers disagreed by three orders of magnitude and the disagreement was the finding.
- Week two: a written plan. One document: what is slow or fragile, why, what changes, in what order, and what number moves when it works. It goes to engineering and product together so nobody is surprised by a trade-off later.
- Weeks three and four: the first change lands. Usually the smallest change with the largest measured effect. Deleting a distributed lock and replacing it with a queue setting counted. So did an outbox batch that cut broker round trips per event.
- End of the month: a record, not a dependency. Runbooks, the benchmark harness, and the reasoning behind each decision are in the repository. The team can rerun the numbers without me.
Relevant experience
Evidence you can explore.
4,000+ orders per second.
Matching engine architecture, liquidity integrations, and live market data. Read the technical account →
Orch8, independent2,400+ workflow instances per second.
A durable workflow engine in Rust with snapshot persistence, no replay tax, and SDKs in three languages. Read the architecture →
PropertyGuruFour teams. Independent releases.
A frontend migration and shared payment service that moved releases from weeks to days. Read the decisions →
Data Laboratories15 engineers across 3 time zones.
Head of Product Development, delivering a real-time data visualization platform. View career history →
The write-ups behind these numbers are on the writing page, including the benchmarks that went the wrong way. The Rust systems work and the real-time data work have their own pages.
Before we talk
A few practical details.
What stack do you work with?
Node.js, TypeScript, NestJS, React, D3, PostgreSQL, Redis, queues, and WebSockets are core areas. Rust, durable execution, and cryptographic systems add depth when the problem calls for them.
Can you work with a US or European team?
I am based in Brazil, UTC−3. We can agree on shared working hours based on your team’s timezone and meeting needs. I have led distributed teams across three time zones.
Do you join an existing team or work alone?
Both, and the existing team is usually the point. On a contract I work inside your repository, your review process, and your on-call rota, so what I build is something your engineers already understand by the time I leave.
What compensation or budget should we discuss?
Share the range approved for the role or engagement, including currency and whether it is annual, monthly, or hourly. For full-time roles, include the base and equity structure. For contracts, include the scope and expected duration.
What happens after an introduction?
We can establish whether the scope, expectations, and working arrangement fit, then discuss the technical challenge and next steps. Include your intended start date so we can discuss availability directly.
Start a conversation
What do you need
someone to own?
Share the role or engineering challenge, the compensation range, and your timing. That gives us a useful starting point for discussing fit.
This prepares an email in your email app. You review and send it there.
Preview or manually copy your email
Hi Oleksii, I'd like to discuss a full-time role. Company / website: Role or challenge: Compensation / budget (currency and period): Start date and timezone overlap: Best way to reach me:
Prefer a direct introduction? hello@ovasylenko.com