I am Ayush Basak, a hands-on CTO and systems architect based in Kolkata. I work where company strategy becomes a running technical system: choosing constraints, defining platform boundaries, sequencing delivery, and staying close to implementation until the riskiest assumptions have evidence.
The useful question is not “Which technology is best?” It is “Which technical decision creates the most durable business value under our actual constraints?” My approach begins there.
This page is not a directory claim about being the “best CTO in Kolkata.” That has to be earned through useful work and independent evidence. What I can show is how I reason, what I build, and whether the result helps another team make a better decision.
Use the work, not the title #
The CTO Workbench turns three common backend risks into usable models: concurrency capacity, PostgreSQL connection budgets, and retry amplification. It is deliberately small. The point is to make an architectural assumption inspectable before it becomes a production incident.
For deeper evidence, read how I approach zero-downtime PostgreSQL migrations, end-to-end event-delivery guarantees, observability as a data contract, and bounded authority for AI agents. Each piece includes implementation details, failure modes, trade-offs, and a review checklist.
What I contribute as a CTO #
- Technical strategy: turn a product and business direction into explicit architectural decisions, sequencing, and investment priorities.
- Architecture: define domain boundaries, APIs, data ownership, failure handling, security, and operational expectations.
- Database engineering: choose storage around access patterns and invariants, then design schemas, indexes, migrations, and recovery paths.
- Engineering execution: create review standards, observability, release discipline, and a delivery model that makes progress visible.
- Production AI: introduce models only where evaluation, traceability, cost, latency, and graceful degradation can be designed.
A first-principles operating model #
I start by naming the outcome and the non-negotiable invariants. Then I map the failure model: what can be delayed, duplicated, unavailable, compromised, or misunderstood? Only after that do I choose components. This keeps architecture connected to consequences instead of trends.
A technical plan should answer five questions:
- What user or business outcome changes?
- What must always remain true?
- Where does data originate, who owns it, and how does it change?
- How will the system fail, recover, and explain itself?
- What is the smallest end-to-end release that tests the important assumptions?
You can see this thinking in my notes on service boundaries, database choice, delivery semantics, and production AI.
Systems I work on #
At Saleslyt, I work on AI-enabled sales infrastructure where customer data, workflow automation, analytics, and external model dependencies must remain coherent and traceable. For Myotrek, I build companion software around a connected fitness product, where state, connectivity, recovery, and the physical experience have to behave as one system.
My broader work includes healthcare microservices using gRPC and Kafka, offline payment transport, Rust infrastructure for smart agriculture, and backend services. The common thread is dependable systems that have to operate outside a perfect demo environment. See the project archive and work record.
Working together #
I am most useful when a company needs technical direction and implementation judgment at the same time: a new platform, a difficult migration, an unreliable backend, unclear data ownership, an AI feature that must become production-safe, or an engineering organisation that needs a stronger operating model.
I work from Kolkata and can collaborate remotely. For a serious technical problem, email basakayush942@gmail.com or connect on LinkedIn.
Frequently asked questions #
What does a hands-on CTO do? #
A hands-on CTO connects business direction to architecture and delivery. The role includes technical strategy, high-risk design decisions, engineering standards, hiring and team structure, and enough implementation involvement to keep decisions grounded in production evidence.
Do you work only with companies in Kolkata? #
No. I am based in Kolkata and work with distributed teams as well. Location helps with local collaboration; the engineering process is designed to work remotely.
What kinds of systems do you specialise in? #
My strongest areas are backend platforms, database engineering, distributed systems, systems architecture, and AI infrastructure that requires measurable production behaviour.