The Good Tech Companies - Ignacio Brasca on Building Systems That Last

Episode Date: February 3, 2026

This story was originally published on HackerNoon at: https://hackernoon.com/ignacio-brasca-on-building-systems-that-last. Staff engineer Ignacio Brasca explains why systems fail, how determinism beats over-engineering, and what it takes to build software that lasts. Check more stories related to tech-stories at: https://hackernoon.com/c/tech-stories. You can also check exclusive content about #software-systems-longevity, #deterministic-system-design, #cicd-guardrails-engineering, #building-scalable-data-systems, #staff-software-engineer, #over-engineering-and-flexibility, #developer-experience-and-tooling, #good-company, and more. This story was written by: @jonstojanjournalist. Learn more about this writer by checking @jonstojanjournalist's about page, and for more stories, please visit hackernoon.com. Staff software engineer Ignacio Brasca shares how durable systems are built by embracing determinism, resisting over-engineering, and designing for change. He argues that maintainability, clarity under failure, and strong developer tooling—not clever abstractions—determine whether software survives growth. Lasting systems reflect both technical discipline and organizational values.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. Ignacio Brasca on building systems that last, by John Stoy and journalist. Systems don't fail because they are poorly written, they fail because they cannot keep up with the complex and ever-changing needs of a business. When speaking with Ignacio Brasca, who is a staff software engineer with several years of experience building complex data systems, he emphasized that software behaves much like a biological system, and that the entropy involved in making it grow cannot be underestimated. As organizations and systems evolved together, developers must plan for long-term change from the start. Ignacio often references

De Nella Meadow's idea that there are no separate systems, the world is a continuum, arguing that systems only last when they are built not just to work, but to grow. Determinism of your actions, under the assumption that you don't depend on services you cannot control, Braska argues that determinism is one of the most important elements of an effective system. Greater than if you know what you will change and what that change will provoke, he says, greater than, you can build a system that lasts forever. This clarity is often what prevents unnecessary abstraction, premature flexibility, and over-engineering. For Braska, determinism isn't about rigidity, it's about having a strong foundation that fosters growth without losing sight of what made your system work well in the

first place. Flexibility versus over-engineering. Flexibility is another area that needs to be approached carefully. Ignacio believes that, in real businesses, flexibility becomes expensive when it's pursued without a clear understanding of what actual needs will arise over time. Teams often try to design for every possible future scenario, only to discover later that they optimized for the wrong ones. The word over-engineered makes us think of unnecessary complexity, he explains, but sometimes it's the opposite.

You take the wrong approach to the initial constraints and end up with something that's simple, robust, and still not functional. Braska relies on a simple framework, make it work, make it good, make it fast. Proving that a system solves a real problem comes first. Only then does it make sense to invest in flexibility, performance, or optimization. Ultimately, flexibility is only worth its cost when it aligns with how the system is expected to evolve. Over-engineering happens when teams design for imagined futures instead of observable change, adding complexity without improving clarity or control. Maintainability in practice, solving for business constraints in theory is one thing. When theory meets practice, things can derail quickly. Ignacio made a pointed

observation about this gap. Here's the thing. Going wrong is the only part of software engineering that actually makes sense. You never write a program assuming everything will go right. It's the edge cases that matter. Today, with the help of AI, writing code has become relatively easy. The difficult part is maintaining a clean, solid, and understandable code base while keeping track of all the changes across a horizontal architecture that allow you to follow through when something goes wrong. Getting that right, Ignacio argues, is what separates systems that survive from those that slowly collapse. Maintainability is about finding clarity under failure, and getting that right means getting everything else right. Tooling, DX, and surviving change. Getting the code right is only the first step of the process. To scale, developer tooling and

experience play a critical role in whether a system survives growth, change, and staff turnover. He notes that engineers tend to be incredibly passionate about their tools and craft. Sometimes, trying tover optimize everything can itself become a problem. However, finding balance and using the right tools can be the solution that removes friction and protects the system from human error. greater than one decision that significantly reduced long-term friction for his teams was greater than investing early in C-CD pipelines. While often underestimated, strong greater than guardrails create confidence, automated checks, validation steps, and greater than consistent deployment processes make it possible to move fast without breaking greater than production. In that sense, tooling

becomes an extension of the system's philosophy. Itreenforces determinism, limits unnecessary complexity, and ensures that growth doesn't come at the cost of reliability. Conclusion. Building for change, not permanence. After this conversation with Ignacio, I have come to realize that systems don't last because they're clever or perfect. They last because they're designed with change in mind. Being intentional with decisions shapes how systems age. The belief that architectural decisions are permanent crumbles quickly when you realize that decisions will eventually be wrong and decay over time.

The goal, then, isn't to predict the future perfect. but to align systems as closely as possible with the problems they're meant to solve today, while leaving room to adapt tomorrow. Building lasting software is not purely a technical challenge, it is also an organizational one. Systems need to reflect the values, discipline, and clarity of the teams they are built for. And in an industry obsessed with speed, novelty, and scale, designing systems that can be understood, maintained, and evolved maybe the most enduring competitive advantage of all. This story was distributed. as a release by John Stoyen under Hackernoon Business Blogging Program. Thank you for listening

to this Hackernoon story, read by artificial intelligence. Visit hackernoon.com to read, write, learn, and publish.