Iryna Borsuk

Iryna BorsukOct 29, 2026

My cat is keeping an eye 👀 out for interesting opportunities 🐈 Hi everyone! 👋 I'm a Senior Software Engineer with 6+ years of experience building SaaS applications, mainly with React, TypeScript, and Next.js. I work on frontend architecture, performance optimization, and scalable applications, as well as full-stack development with Node.js and AI-powered features. I'm interested in Senior Frontend and Full-Stack opportunities where I can bring my experience in building complex applications, contribute to interesting products, and continue working on AI-powered features. I'm always happy to connect with fellow developers, exchange ideas, and meet people working on interesting projects. If you're hiring or know of an opportunity that could be a good fit, I'd love to hear from you! 😊 📍 Based in Prague, Czech Republic, and open to opportunities across the EU. #SoftwareEngineering #OpenToWork #React #TypeScript #NodeJS #AI

Iryna BorsukNov 4, 2026

I keep seeing "Frontend RIP 🪦", and I don’t buy it Writing code is no longer the slow part. AI can produce a component in minutes. But it does not change that: - someone decides the architecture; - someone sets the rules: strict types, stack conventions, structure; - someone reviews what comes out; AI writes it, but the developer owns it. Because when something breaks in production, the developer has to explain why it was built that way. Frontend architecture is still as important as it was before, but the work just moved from writing to specifying and reviewing. I’ve seen this before on a legacy project that started as a monolith; the frontend often grew without clear frontend architecture. It caused performance issues and ended up in a migration to a standalone, properly structured frontend. Maybe AI just took over the typing and freed up time for standards and business needs? Or it’s building the next generation of frontend legacy code 🤔 My bet: AI makes typing cheap and missing architecture expensive. Vote below, and share your ideas in the comments. #Frontend #TypeScript #AI

Iryna BorsukNov 10, 2026

Rewriting legacy code from scratch is a trap. It looks cheaper on paper, but in practice, it can quickly become more expensive than expected. I've worked with large SaaS applications where the codebase wasn't built in a day and couldn't be replaced in one. A complete rewrite might seem like a good opportunity to fix everything. But in a production environment, you still have feature requests, bug fixes, and deadlines to deal with. That's why I prefer gradual migration. A few things I've found useful: - Write all new code in TypeScript. - Start with API responses and shared interfaces. This helps establish clear contracts between different parts of the application before migrating individual modules. - When working on an existing JavaScript module, consider migrating it to TypeScript instead of postponing it indefinitely. - Migrate module by module. Smaller changes are easier to review, test, and release. For some time, new components might depend on older modules, and sometimes you'll need to work around decisions made years ago. Meanwhile, product development doesn't stop. You still need to deliver new features while making the existing code easier to maintain. I think that's the part worth considering before choosing a full rewrite. I'd rather improve the codebase as we go than put product development on hold for a rewrite. How have you approached legacy migrations? Did you manage to do it incrementally, or did a full rewrite eventually become unavoidable? #TypeScript #React #LegacyCode