About Nikita Sinenko
I'm a Rails engineer based in Dubai. I work on the problems that show up as something you can read: query plans, queue backlogs, sync cursors, deploy rollbacks, and permissions around automated actions.
Performance and product engineering
I work with Rails applications where the bottleneck has become visible: a dashboard that loads too slowly, a queue that cannot drain during peak hours, an integration that loses track of external state, or an agent workflow that needs to survive retries.
Most of the work is ordinary engineering done carefully: PostgreSQL query plans, cache boundaries, background job design, API contracts, deployment shape, and the interface a team has to use every day. I use Hotwire or Vue.js when the product needs interaction and server-rendered HTML is not enough.
Across SaaS, e-commerce, and FinTech
I work on Rails applications across SaaS, e-commerce, internal tools, financial platforms, and healthcare. Most engagements start with a concrete problem: slow queries, queue backlogs, API response regressions, OAuth refresh failures, reporting models that do not match the source system, or a Rails 8 migration that needs a staged path.
Based in Dubai, working remotely with clients across time zones. I stay close to the Rails ecosystem: the Rails 8 Solid Stack, Solid Queue recurring jobs, Solid Cache, Hotwire, PostgreSQL internals, and Kamal 2 deployments on VPS infrastructure.
SLOW SCREEN
Request trace, query count, top `EXPLAIN ANALYZE` plans, cache hit rate, and the controller path users actually hit.
QUEUE PROBLEM
Job volume by class, retry rules, recurring schedules, idempotency, and whether Redis is still earning its place.
VENDOR SYNC
OAuth refresh, webhook signatures, sync cursors, rate-limit state, and the reconciliation report that proves data arrived.
AI WORKFLOW
Tool inventory, tenant scope, write approvals, stored run state, parser tests, and cost logs per account.
I am not the right starting point for a broad brand exercise, a greenfield product with no technical constraint yet, or a vague "make it scalable" request. The useful engagement starts when there is a concrete system, a visible failure mode, and enough access to inspect logs, code, schema, queues, or vendor API behavior.
If one of those describes your Rails app, you can see how I can help or get in touch to start a conversation about the specifics.