About / Serhii Cheredko
Serhii Cheredko
Founder and principal software engineer at Absolyd
Software engineering with the decisions kept close to the work.
I design and build operational software across backend systems, frontend applications, integrations, cloud infrastructure and AI-assisted workflows.
I have more than eight years of professional software engineering experience across production systems, integrations, internal tools and technically ambiguous work.
The short version
Absolyd is an independent software engineering practice. You work directly with me: the engineer responsible for understanding the situation, making the technical decisions and carrying the implementation into production.
There is no handoff from sales to a separate delivery team, and no account-management layer between the operational problem and the person building the system.
That structure matters when the important details are difficult to pass through a chain of summaries: an undocumented workaround, a permission that changes data, a provider that sends duplicate events, or a failure that only appears after the system has been running in production.
What I take responsibility for
Understand the system before deciding what to build
Map the current process, systems, exceptions and constraints before defining the implementation.
Turn uncertainty into a bounded plan
Convert incomplete requirements into a useful first scope with explicit assumptions, exclusions and trade-offs.
Own the technical path
Handle architecture, data modelling, backend, frontend, integrations, deployment and production behaviour where the system crosses those boundaries.
Make failure visible and recoverable
Design retries, audit history, reconciliation, monitoring and operator controls rather than treating the happy path as the complete system.
Leave the system understandable
Keep code, infrastructure, decisions and operating instructions accessible to the client.
Selected professional experience
Honeysales
Senior Software Engineer
Building agentic AI systems for B2B sales, including workflows around real-time buying signals and sales intelligence. Current technical work includes Amazon Bedrock, Amazon AgentCore and Strands.
Briza
Senior Software Engineer
Worked on insurance API integrations and the production system around existing provider integrations, including inconsistencies and maintenance beyond a successful example request.
VistaCreate
Software Engineer
Worked on a large design product used to render and generate images, text and video, including database-query optimisation, frontend performance and backend renderers and converters.
Master of Code Global
Full-stack JavaScript Developer
Built business chatbot systems, including conversation logic, third-party integrations and the user-interface components required to operate them.
N-iX
Node.js Developer
Worked on the backend of a large booking system aggregating flights and hotels, adding user flows and resolving inconsistencies between the platform and external APIs.
Eleken
Full-stack JavaScript Developer
Built and maintained startup MVPs across web and cross-platform mobile applications, working across frontend, backend, React Native, CI/CD and process automation.
Professional history is described at a high level. Confidential employer and client details remain confidential. These roles are not presented as Absolyd client engagements.
Technology and systems
My primary production stack is TypeScript, Node.js, React, Python, SQL and AWS. The more important part is the system work around them: integrations, background processing, operational interfaces, recovery paths and production ownership.
I can enter an existing codebase and work with its current architecture without forcing an unnecessary rewrite for my convenience.
Primary production stack
Systems work
Supporting technologies
JavaScript · Express · Vue · React Native · MongoDB · SQLite · Docker · CI/CD · APIs and webhooks · Amazon Bedrock · Amazon AgentCore · Strands · Go and Rust
I treat a model response as one component inside a controlled workflow, with validation, permissions, fallback behaviour and human review where the risk requires it.
How I use AI in engineering
I use AI-assisted development where it improves implementation speed, research or verification. It does not replace responsibility for architecture, security, testing, review, deployment or production behaviour.
Client source code, confidential information or production data should not be sent to an external AI provider without explicit approval and an understood data-handling arrangement.
Direct responsibility without technical lock-in
Working with one engineer should not mean depending on one private machine, one undocumented deployment process or one person’s memory.
Source code normally lives in a client-controlled repository. Production infrastructure is placed in client-controlled accounts where practical. Architecture decisions, deployment and recovery instructions remain documented so another competent engineer can understand and operate the system.
Repositories, infrastructure and provider accounts remain accessible to the company that owns the system.
Important architecture, operating instructions and known limitations are left visible.
When the work clearly requires a broader team, I say so rather than accepting an unrealistic scope.
Capacity, conflicts and continuity
I accept a limited number of independent engagements, subject to capacity and conflict checks.
Before work begins, scope, communication cadence, availability and ownership are agreed. Employer and client code, confidential information, accounts and infrastructure remain strictly separated. Handover, documentation, monitoring, support and continued involvement are defined based on the system’s needs rather than assumed.
Entry offer / bounded paid engagement
Operational System Review
A responsible first phase for a manual, fragile or unclear operational system. The review makes the current boundary, failure modes and safest first production scope visible before implementation begins.
Founder and principal engineer
Start with the system as it exists.
Send the current process, the systems involved and one example of where the work breaks. I will tell you what I need to understand next and whether it suits a consultation, defined project or different solution.