The evolution of a company is designed too

There is a fairly established idea in the industry: when a company wants to renew itself, it changes its logo, redesigns its website, and publishes a new manifesto.

But none of those things truly transform a company. What makes a company evolve is changing the way it thinks, works, and solves problems. Branding, visual identity, and the website should simply be the consequence of that evolution, never the starting point.

That is exactly what we experienced at Urbs Data.

What began as a project to renew our digital presence became a much deeper exercise: reviewing how we communicated what we did, clarifying our value proposition, and building a technical and visual foundation that could support the company’s growth over the coming years.

The website no longer represented the company

For a long time, our website did its job perfectly. It explained who we were, what we did, and how people could contact us. But while the website remained almost the same, the company kept evolving.

With every project, we deepened our experience in data engineering, automation, business intelligence, artificial intelligence, and application development. Little by little, we stopped seeing those disciplines as independent services and started understanding them as parts of the same system: data feeds processes, processes drive automation, and artificial intelligence operates on reliable information to help organizations make better decisions.

The problem was that our website was still telling the story of the company we had been, not the company we had become. And when that happens, the challenge stops being visual. It becomes a communication problem.

Before design, we needed a strategy

Before opening Figma or writing a single line of code, there was a much more important question to answer.

What do we want a company to understand after spending three minutes getting to know Urbs Data?

The answer ended up defining almost the entire project.

We did not want to sell dashboards, artificial intelligence, or software development as isolated capabilities. We wanted to communicate a much simpler idea: companies work better when they stop treating technology as separate tools and start building an infrastructure where data, applications, automation, and artificial intelligence work as one system.

From that premise, the entire narrative began to organize itself. Each section of the website started to serve a specific purpose: present the problem, explain our way of working, show how we connect the different pieces, and finally communicate the impact that this way of building has on our clients’ businesses.

When the message is clear, design stops trying so hard to capture attention and starts fulfilling its real purpose: reinforcing the story we want to tell.

Designing a system before an interface

In engineering, we talk constantly about software architecture, but we rarely think of visual identity as something that also needs architecture.

An interface where every component makes different decisions about color, typography, spacing, or behavior eventually creates the same problems as an inconsistent codebase: it is hard to maintain, expensive to evolve, and every change introduces new exceptions.

That is why we decided to build the system first, and the screens afterward.

The entire identity began to rely on reusable components, semantic tokens, consistent typography scales, and a palette based on modern color spaces like OKLCH. Tools like Shadcn and Radix Colors accelerated that implementation, but the real work was defining the rules that connected all those pieces so they could function as a single language.

The goal was never for everything to look the same. The goal was for everything to respond to the same principles. That difference makes adding new pages, new functionality, or even new products feel less like improvisation and more like a natural evolution of the system.

Technology was a consequence

Only once the message and the system were clear did we start talking about technology.

We chose TanStack Start because we needed an architecture prepared to grow far beyond an institutional website. The project was no longer just a landing page: it also had to coexist with a blog, technical content, presentations, and future tools that did not exist yet. Technology had to support that evolution, not constrain it.

Every decision tried to answer one very simple question: will this still make sense when the project is much bigger than it is today?

Frameworks change. Libraries evolve. Even the way we develop applications will continue to transform over the next few years. What remains is a well-designed architecture, capable of adapting without forcing us to start over every time a new tool appears.

Artificial intelligence as a working partner

Artificial intelligence was also part of the process, although not in the way many people imagine. It did not design the website, it did not write the content, and it did not make decisions for us. Its greatest contribution was helping us question our own.

We used it to explore different ways of explaining complex concepts, review the narrative, detect inconsistencies between the message and the interface, validate accessibility decisions, and analyze alternatives before implementing them. Many of those ideas never reached the final product, and that is exactly why they were valuable. More than a tool for producing content, it became a tool for thinking with greater clarity.

Constraints accelerate design

There is a tendency to believe that creativity needs absolute freedom. Our experience was exactly the opposite.

From the beginning, we defined a set of principles that guided almost every decision in the project.

• Every component had to belong to the design system.
• Every section had to communicate a single idea.
• Every animation had to improve understanding, never distract.
• Every visual element needed a purpose.
• Every technical decision had to make the project’s future evolution easier.

Far from limiting the process, those constraints eliminated a huge number of unnecessary discussions. When a new idea appears, it no longer needs to be debated from scratch; we simply ask whether it respects the system we are building. If the answer is yes, it moves forward. If not, it probably still needs to mature.

Evolving also means preserving

One of the most common mistakes during a rebranding process is assuming that everything has to change.

We tried to do exactly the opposite. We preserved what still represented Urbs Data correctly and rethought only what no longer did. Evolving does not mean breaking with the past, but recognizing which decisions still have value and building on top of them.

It is a principle that applies to software, design systems, and brands.

Building the next version of Urbs Data

The new website does not represent the end of a project, but the beginning of a new stage. A few years from now, we will probably redesign it again. Technologies will change, new tools will appear, and artificial intelligence will occupy a different place than it does today. That does not worry us, because the real goal was never to build a more modern landing page.

What we were really looking for was to build a foundation capable of evolving alongside the company. An architecture where every new decision could naturally find its place, without forcing us to rethink everything from scratch; a design system that could grow without losing coherence; and an identity that continued to represent us even when the organization changed again.

Looking back, that was probably the most important decision in the entire project. Not designing a website for the company we were, but building a platform prepared for the company we continue building every day. Because in the end, good architecture, whether for software, design, or a brand, is not measured by how it looks on launch day, but by how easily it can keep evolving when the business changes again.