About / Serhii Cheredko
Direct access to the engineer doing the work.
I’m Serhii Cheredko, founder and software engineer at Absolyd. I work across product reasoning, architecture, implementation, integration and production operation.
The short version
Absolyd is an independent software engineering studio. There is no handoff from sales to a delivery team and no layer of account management between the problem and the person building the system. You work directly with me: the engineer responsible for understanding the situation, making the technical decisions and carrying the implementation into production.
That structure is deliberate. Operational software is shaped by details that are difficult to pass through a chain of summaries: a workaround a team has normalized, a permission that changes the data, a provider that sends duplicate events, or a failure that only appears after a system has been running for a month.
What I take responsibility for
Understanding the business, operational and product problem before deciding what to build.
Turning incomplete requirements into a concrete plan with visible trade-offs and a useful first scope.
Designing the architecture, data model, interfaces and integration boundaries.
Building the backend, frontend, workflows and infrastructure needed for the system to operate.
Investigating production failures, improving reliability and making the next decision with evidence.
Professional experience
More than eight years of professional software engineering experience across production systems and technically ambiguous work.
I can enter an existing codebase, understand systems I did not design and work across backend, frontend, infrastructure, data and AI when the problem requires it.
My experience is broad, but more importantly, I am not dependent on a fixed stack. I learn the technology and domain required by the problem rather than forcing every problem into the tools I already know.
How I work
Start with the constraint.
The first description of a problem is often a symptom. I look for the decision, dependency or repeated failure that creates it.
Prefer a useful boundary.
A system should have a clear responsibility. Narrow scope is valuable when it makes the first implementation testable and useful.
Make failure legible.
Retries, logs, states, ownership and recovery are part of the product whenever the process matters after the happy path.
Keep judgment close.
Automation can remove repetition, but people should remain able to review, correct and understand consequential decisions.
A practical working relationship
Bring context
We begin with the process, the current workaround and the point where the team loses time, confidence or control.
Make decisions visible
I explain the system shape, trade-offs, unknowns and first scope before implementation turns them into expensive assumptions.
Stay accountable
The relationship remains close to the implementation: architecture, code, deployment, debugging and the next useful improvement.
Representative experience includes
Types of systems
- Operational automation and internal tools
- B2B and data-heavy applications
- External platform integrations
- Document and message processing
- Subscription, billing and access logic
- Analytics, reporting and administrative interfaces
- Reliability, retries and failure recovery
What this is not
Absolyd is not a large agency with a bench of specialists, a catalogue of client logos or a promise to solve every possible problem. It is a direct working relationship with an experienced engineer who can take ownership of a software problem across the parts that need to connect.
The right fit is a company with a real operational bottleneck, enough context to investigate it and a willingness to make the underlying process explicit.
Founder and principal engineer
Start with a conversation.
Send the process as it exists today. I’ll help determine what needs to be understood, what can be improved and whether software is the right next step.