Our story
Design was never optional in any engineering discipline I came from.
During my career in semiconductors, it would have been absurd to suggest building a chip without design. You don't tapeout without verified logic and integration plans. You don't manufacture a board without schematics and documentation that your engineers can execute against. Design is not a nice-to-have in those disciplines; it is a prerequisite for building anything that works.
When I moved into enterprise software, I expected to find the same rigor. What I found instead was an industry that had somehow decided design could be reduced to making screens look professional, and that requirements could be captured in a few bullet points before handing them off to a development team to figure out. Then managers and directors would wonder why projects went sideways, didn't deliver on time, blew budgets, and/or released with loads of bugs. The pattern was consistent across every organization I worked in: the engineering team was not being set up for success because the upstream work was missing or incomplete that would otherwise give them a clear, buildable specification of what they were supposed to deliver.
The engineering team was not being set up for success because the upstream work was missing or incomplete.
My background in hardware gave me something that turned out to be quite valuable in the software world. Having spent years understanding what happens under the hood, all the way down to the transistors, I could think ahead when a stakeholder made a feature request and understand the implications of what they were asking for. I often use the analogy of building a car: a customer will ask for a steering wheel, a radio, seat covers, cup holders, and then mention that they also want it to hover. You can prevent the project from going off the rails by recognizing that the hover request alone is going to cost a thousand times more than everything else combined. You have to dig into where that request came from and what problem they are actually trying to solve. That instinct for planning ahead and understanding the landscape of what is coming is, in fact, why the company is named Planorama: an amalgam of "plan" and "panorama."
Planorama = "plan" + "panorama": Executing with confidence that stems from a clear view of the landscape.
I assembled our Agile team around that same principle. I wanted senior practitioners who understand not just how to design, but how enterprise software actually works under the hood.
Design practice
Cristian and Hugo are senior designers I have known and worked with for a long time, and they share something genuinely uncommon in this industry: they do not just design interfaces. They understand how roles and permissions affect the design of your screens, how you administrate enterprise applications, and what the common use cases are that most designers coming out of school have simply never encountered. Their designs have longevity because they are thinking about what is on the roadmap, not just what is in the current sprint.
AI practice
Thiago leads our AI practice, bringing both hands-on engineering experience and an academic research background as a university professor. When a client asks whether AI can solve a particular problem, we do not simply say yes. We prove it out, consider whether a self-hosted model makes more sense than a commercial vendor, and flag the privacy and governance implications before they become expensive surprises. Quite frankly, throwing AI at everything is not a good idea.
We're your partner, not your vendor.
We are in the same time zones as our clients, we have accounts on their systems, and we always have our cameras on because that is how teammates operate when they are working side by side. There have been many times when we have talked ourselves out of work, telling a client that a feature they wanted to build was not the right choice and suggesting they do something different or not do it at all. We do that because we are looking out for their best interests and the longevity of their product, even when it means fewer billable hours for us. That is what we mean when we say we would rather be considered a partner than a vendor, and it is the practical meaning behind "clarity before code."
