For most of my career I have worked at the edges of organisations rather than inside them. Three years designing the University of Cuenca's website and researching its internal applications, as a designer brought in to fix things. Years of front-end work for DeFi protocols, where a project is a handful of people and a Discord. Client sites for brands in Ecuador and Belgium. And my own products — a recipe app, a car dealership platform, a post-quantum blockchain ecosystem I started because I wanted to know if one person could take an L1 from an empty Cargo.toml to something a non-technical person could actually open. All of that work has a shape in common. You are outside, you are temporary, and you ship. In the second week of January I joined Banco del Austro as UX Researcher. In-house, permanent, at an established Ecuadorian bank. It is the first time I have been on the other side of that arrangement, and eight months in it has been more instructive than I expected.

What I assumed

I started with a diagnosis ready, which in hindsight is the most predictable mistake an outside designer makes when they finally get inside. The bank's public site had the familiar symptoms of a long-lived institutional website: dense navigation, competing calls to action, typography that shifted between a campaign page and a product page. My assumption was that this happens because nobody has designed it properly, and that the fix is to design it properly. That assumption was wrong in an interesting way.

What I found

The bank had a brand manual. A good one — the Manual de Imagen 2024, which covers branch branding, signage, materials and ATM treatments in real detail, with process steps and timelines. Someone had done careful work. It is a PDF. That single fact explains almost everything I had diagnosed as a design problem. A PDF cannot be checked: nothing stops a campaign banner from using a slightly wrong blue, because nothing compares the banner to the manual. A PDF cannot be reused: a developer reading "primary blue" retypes the hex value, and retyping is where drift starts. And it goes stale the moment a product needs a treatment the manual never anticipated. The drift was not a failure of design. It was a failure of distribution. The rules existed and could not travel.

What I built

So the work became a system rather than a redesign: around 135 design tokens and just over fifty banking components, running as a live application that anyone at the bank can open in a browser. Not a library you install — a page you visit. The component set is deliberately not generic. A transaction row, a one-time-password input, a rate table and a regulatory disclaimer block are not decorative variations on a card; they are the pieces a bank actually assembles pages from. Building the specific things turned out to matter more than building the flexible things. The design manual moved inside it. The brand rules, the branding process, the signage timelines now sit as structured content next to the code that implements them, so the rule and its implementation live in the same place. That is the only arrangement I have found where the two stay in agreement.

The part I did not want to do

The bank's public site runs on DNN, an older .NET content management system. Its editors work in HTML modules. They cannot consume a React component library and they are not going to install a build toolchain. This is where design systems quietly die. The library is beautiful, the production site does not use it, and the gap fills with hand-written HTML that drifts within a month. So the system got an export pipeline. Every section of every page template has a button that copies its HTML with the styles inlined, ready to paste into a DNN module. A script generates the whole set for all nine Visa card variants, so somebody launching a card page starts from correct markup instead of a blank editor. Inlined styles are not how you would write a greenfield site. I resisted it for longer than I should have, because it felt like a step backwards. It is not. A design system the production platform cannot consume is decoration. Meeting the legacy stack where it actually stands is what turns a library into something the bank ships.

What being inside actually changes

The obvious answer is that you move slower, and that is true but not the useful part. The useful part is that you stop optimising for launch. A freelance project ends. You hand it over, it looks its best on the day it ships, and whatever happens next is someone else's. Inside an institution you are still there in month eight, watching what marketing does with the component you built under a deadline you had forgotten about. That changes what you build. Governance stops being a boring word and becomes the actual work: a lightweight process for how a homepage change gets made, so that banner swaps and product launches and regulatory disclosures all have a home in the system instead of each triggering a small redesign. Constraints that let marketing move fast without destabilising the journeys that have to keep working. None of that is visible in a portfolio screenshot. It is most of the value.

What I kept

I did not stop building my own things. Alongside the bank work these eight months there has been a members-only platform for a motorcycle club, a family app on Flutter, a token launchpad with its own Solidity contracts, and a site for a windows and doors installer in Belgium. That range is not a distraction from the in-house work — it is what makes me useful in it. Having shipped a Postgres schema with row-level security is why I can have a real conversation with the bank's engineers about what a design handoff should contain. The milestone, then, is not the title. It is that after years of arriving, fixing and leaving, I have been somewhere long enough to watch the thing I built start to get used by people who were not in the room when it was made. Ask me again in a year.