Code Story: Insights from Startup Tech Leaders

Developer Chats - Oleksandr Piekhota

Mar 4, 2026

Oleksandr Piekhota, a principal software engineer and platform-focused architect, shares career stories from PHP and Go systems. He talks about when teams must shift from features to system ownership. He explains triggers for platform overhauls, when internal tools become real products, and how to judge R&D experiments. He also reflects on API maturity, open source as serious work, and what makes engineering systems truly mature.

Ask episode

AI Snips

Chapters

Books

Transcript

Episode notes

ANECDOTE

Woken By A Production Mystery That Revealed Missing Traces

Oleksandr learned system ownership after being woken for a production issue he couldn't debug due to missing traces.
The lack of stored traces on a flakey PDF filler API incident showed him he needed to design observability, not just features.

ANECDOTE

Team Explosion Exposed Integration And Local Dev Collapse

Rapid hiring from 10–15 to ~80–90 people in six months broke local development and integrations, making releases nearly impossible.
They introduced microservices, tracing, and integration/automation teams after internal load tests failed during company-wide usage.

INSIGHT

Public APIs Are Contracts Not Quick Features

Moving from B2C to B2B made API design about public contracts: backward compatibility, versioning, rate limits, and predictable naming.
Oleksandr and his manager spent hours debating endpoint/param names and error shapes to build trust and SDK friendliness.

Get the Snipd Podcast app to discover more snips from this episode

Get the app

Today, we are continuing our series, entitled Developer Chats - hearing from the large scale system builders themselves.

In this episode, we are talking with Oleksandr Piekhota, Principal Software Engineer at Teaching Strategies. Oleksandr helps to show us at what point of scale platform approaches are required, when to run experiments and when to stop, and perhaps more importantly - engineering ownership beyond the code.

Questions

You’ve moved from hands-on engineering into principal and technical leadership roles, working on architecture and platforms.At what point did you realize your work was no longer about individual features, but about the system as a whole
Across several projects, growth didn’t break functionality — it exposed architectural limits.Can you recall a moment when it became clear that shipping more features wouldn’t solve the problem, and a platform approach was required?
You’ve designed and supported APIs end-to-end, from architecture to real customers. How do you distinguish between an API that simply works and one that can truly support business scale?
Internal systems like invoicing and HR workflows began as automation, but evolved into real products.What tells you that an internal tool is worth developing seriously rather than treating as a temporary workaround?
In R&D, you explored CI/CD automation, server-less, and infrastructure experiments — not all reached production. How do you decide when an experiment should continue, and when it’s no longer worth the engineering cost?
You’ve hired teams, set standards, and shaped long-term technical direction. At what point does an engineer stop being a contributor and start owning business-level outcomes?
You contributed to open-source tools that later became part of your company’s infrastructure. Why do you see open source contributions as part of serious engineering work rather than a side activity?
Looking across your projects, how do you now recognize a truly mature engineering system? Is it code quality, process, or how teams respond when things go wrong?
If we look five to seven years into the future, which architectural assumptions we treat as “standard” today are most likely to turn out to be naive or limiting?