About › Experience
Present-Day Work
How I work today and the principles behind the tools I build.
Kequtech exists so I can build software with clarity and long-term stability. The site, the framework it runs on, and the tools behind it all reflect a consistent approach to engineering: understand the system, remove unnecessary complexity, and keep control of the parts that matter.
Modern development leans heavily on layers of abstraction. After working with many of them, I prefer simpler foundations. That is why I built my own Node framework. It gives me a predictable architecture, clean request handling, and an environment where changes do not require chasing hidden behavior through a chain of dependencies.
The API endpoints offered here follow the same principle. They provide focused, dependable functionality for tasks I see repeated in real work such as summarizing content or generating structured data. Nothing behind them is opaque. They are built to be straightforward to maintain and easy to integrate into larger systems.
Running my own company lets me continue remote contract work while developing these tools at my own pace. It gives me space to design systems end-to-end and refine them over time instead of pushing them through short release cycles.
Early Foundations
Where my instincts for clarity and improvement first took shape.
My work at IBM was in technical support for a major banking client, and it required navigating a wide mix of legacy systems. The environment demanded quick research, clear thinking, and the ability to trace problems through layers of old documentation. It was an introduction to large-scale complexity long before I wrote software professionally.
The role involved tasks that repeated constantly. Rather than cycle through them by hand, I wrote small automation tools that closed tickets and handled other routine work. The gain was significant for the team, and it showed me how even simple scripts can shift the workload inside a large organization.
Before that, I had already been writing small programs in languages like QBasic, Visual Basic, and C#. They were basic experiments, but they taught me how to break down problems and turn ideas into working code. That familiarity made later transitions into modern development straightforward.
This period set the baseline for how I work: understand unfamiliar systems quickly, identify what slows them down, and improve the parts that matter.
Expanding Through Client Work
Years of varied projects that built adaptability and practical judgment.
The next stretch of my career was defined by constant project work across many clients and industries. Some projects were long and complex, others were short and unpredictable, and there were times when more work arrived than I could reasonably take on. It forced me to become fast at absorbing new domains and clear about what a system actually needed in order to function well.
I worked in several languages and frameworks during this period, shifting tools as projects required. With that much variety, the specifics mattered less than the patterns. Good data flow, straightforward architecture, and minimal hidden behavior were the only approaches that consistently held up once a project grew or changed direction. Those patterns became the backbone of how I design software today.
There were mistakes along the way, especially in early projects with tight timelines or unclear requirements. Fixing those mistakes taught me to expect change, design for it, and rely on simplicity when everything else was uncertain.
The ability to recover became as important as the ability to build.
This decade gave me the range and resilience I rely on now. It shaped how I evaluate tradeoffs, how I adapt to new technologies quickly, and how I design systems that stay stable as they scale or shift in purpose.
Startup Leadership and Ownership
Where responsibility expanded from writing code to shaping entire products.
Co-founding a startup and taking on the role of CTO moved my work into a different scale of responsibility. Instead of delivering individual components, I was accountable for the entire system: architecture, implementation, infrastructure, and the long-term direction of the product.
The product itself required original engineering. At the time there were no existing tools for what we were trying to build, so I designed a recording and playback format capable of capturing website interactions with audio in a compact, practical way. It was an environment where existing frameworks did not apply, and progress depended on understanding the problem directly rather than leaning on established patterns.
I brought in a small group of people to handle areas where extra hands or specialized skills were needed. Keeping the project coherent meant clear communication, steady expectations, and a technical foundation that others could work within without being slowed by complexity. That responsibility sharpened my ability to make decisions that support both immediate progress and long-term stability.
I also did advisory work for other founders during this period, helping them assess architecture, identify bottlenecks, and navigate early technical decisions. Seeing how different teams approached similar challenges helped widen my perspective and reinforced how important it is for systems to be grounded in practical realities rather than trends.
Living and working in different countries added to that learning curve. New environments and workflows demanded adaptability, and that experience made me more effective in diverse and remote settings.
This chapter did not change how I build software. It showed how those methods scale when the entire product depends on them.
Modern System Architecture
Building cohesive ecosystems instead of isolated components.
In recent years my work has centered on building complete systems rather than isolated features. Most of my projects use modern tools like Node.js, TypeScript, React, and Next.js, but the tools are not the point. What matters is keeping the architecture clear, predictable, and easy to extend as the system grows.
I began consolidating my work into a monorepo structure that includes my framework, shared libraries, design tokens, API services, and supporting tooling. It creates a unified environment where each part of the system follows the same principles and interacts cleanly with the rest. This approach reduces duplication and keeps long-term maintenance straightforward, even as new components are added.
Creating my own framework was a natural extension of this direction. Off-the-shelf backends solve generic problems well, but they often introduce complexity in the areas where clarity matters most. Building a lean foundation gave me direct control over the request pipeline, error handling, configuration, and the parts of the system that form the backbone of every feature. That control allows me to design APIs and services with a level of transparency that is difficult to achieve with heavy abstractions.
Modern deployment platforms and CI tools have changed how software is delivered, and I use them when they make sense. Automated testing, containerization, and continuous deployment remove friction from the release cycle. At the same time, I stay careful about relying on tools that hide behavior or create lock-in. The goal is to balance convenience with long-term stability.
Work from this period includes architectural leadership roles and large-scale refactoring efforts that improved clarity, performance, and scalability across existing products.
This stage of my career reflects the shift from building many systems to building systems that can support everything built on top of them.
Current Focus and Direction
Where I’m aiming next and the type of work that interests me now.
My focus now is on building systems that make intelligent automation practical. AI has reached a point where it can become a stable part of real products, and I am interested in the engineering required to make that possible. The work on Kequtech’s API platform comes from that direction. It allows me to design structured services around language models and explore how they can support everyday workflows without becoming unpredictable or obscure.
The problems that interest me most are the ones where traditional software and machine learning meet. Integrating model-driven components into clear, maintainable architectures is still an open challenge in many organizations. My background in system design, long-term maintenance, and simplifying complex foundations aligns well with that type of work.
I want to continue building tools that help people work more efficiently, whether through AI-assisted features, deeper automation, or well-designed backend systems. The pace of change in this area is fast, but the underlying principles remain the same: understand the system, anticipate how it will evolve, and build in a way that keeps it stable for years, not months.
About This Page
This page is not a résumé and does not attempt to list every project or role. It’s an overview of the ideas and patterns that shaped how I work. The details will change over time; the intent is to offer context, not a complete record.