The sculpture studio at my art school had a sign above the door: "Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away." Saint-Exupéry's words haunted me then, but it wasn't until I started building software that I truly understood them.

Last month, my developers watched in disbelief as I killed a feature we'd spent three weeks building. It was a sophisticated reporting module that could slice data seventeen different ways. The problem? Only 1% of our customers would ever use it, and it made our contract management dashboard examples unnecessarily complex for the other 99%.

"But Matt," one engineer protested, "it's already built. The code is written. It works."

That's when I knew I had to explain why sometimes the bravest thing you can do is destroy your own creation.

The Art of Digital Minimalism

In the physical world, we celebrate minimalist artists who strip away the unnecessary to reveal essential truth. Donald Judd didn't add more elements to his sculptures to make them "better"—he removed everything that distracted from the pure form. Yet in software, we've been conditioned to believe that more features equal more value.

This is the fundamental lie that nearly killed Concord.

By 2020, we had features hidden three layers deep in our interface that even our own support team had forgotten existed. We'd become what I call a "Cheesecake Factory" product—a menu so vast that excellence becomes impossible. Every new feature we added didn't just complicate our code; it obscured the core value we were trying to deliver.

The Hidden Cost of "Already Built"

Here's what most people don't understand about software: every feature you keep costs you forever.

When that engineer reminded me the feature was "already built," he was seeing only the sunk cost. What he wasn't seeing was:

• The confusion it would create for 99% of users who didn't need it
• The bugs we'd have to fix in perpetuity
• The documentation we'd have to maintain
• The support tickets from bewildered customers
• The slower load times from additional code
• The opportunity cost of not building something truly valuable

In software, as in sculpture, what you choose to remove is just as important as what you choose to create.

The 90/20 Rule

Through analyzing how thousands of companies use Concord, we discovered something shocking: 90% of our users were using only 20% of our features. This wasn't a failure of marketing or user education—it was a fundamental truth about human behavior.

People don't want Swiss Army knives for every task. They want simple, elegant tools that do one thing exceptionally well. When we accepted this truth, everything changed.

We started asking different questions:

• Not "What can we add?" but "What can we remove?"
• Not "How can we make this more powerful?" but "How can we make this more obvious?"
• Not "What would impress our peers?" but "What would make sense to my grandmother?"

The Courage to Destroy

My role as CEO has fundamentally transformed. Five years ago, I spent 80% of my time dreaming up new features. Today, I spend 80% of my time killing them—both proposed features and existing ones.

My developers used to joke about my constant requests for "just 10 more lines of code." Now they joke about my ruthless cutting. But here's what they've come to understand: every feature we remove makes the remaining features more powerful, not less.

It's like negative space in visual art. The empty areas aren't absent of meaning—they give meaning to what remains.

The Practice of Digital Decluttering

So how do you know what to cut? We've developed a rigorous process:

1. Usage Analytics Are Truth We track every click, every feature access, every user journey. If fewer than 5% of users touch a feature in six months, it goes on the chopping block.

2. The Complexity Tax Every feature must justify not just its existence but its complexity. A feature used by 30% of users that makes the interface 50% more complex is a net negative.

3. The Grandmother Test If I can't explain a feature to my grandmother in one sentence, it's too complex. This isn't about dumbing down—it's about clarity of purpose.

4. The 5-Year Question I constantly ask my team: "Will we still be doing this in five years?" If the answer is no, why are we doing it now?

The Results of Restraint

Since we began this practice of building backwards—removing more than we add—remarkable things have happened:

• Customer satisfaction scores increased by 23%
• Support tickets decreased by 41%
• Feature adoption rates nearly doubled
• Development velocity increased because we're maintaining less code

But the most telling metric? When we made it easier for customers to set up contract renewal reminder software by removing unnecessary options, usage of that feature jumped 340%.

Less truly became more.

The Ongoing Battle

Feature creep is like entropy—it's the natural state toward which all software tends. Fighting it requires constant vigilance and often uncomfortable conversations.

Just last week, a board member suggested we add AI-powered contract drafting because "everyone else is doing it." It would have been easy to say yes, to check that box, to add that bullet point to our marketing materials.

Instead, I asked: "Does this make our core product better, or just bigger?"

The silence that followed told me everything I needed to know.

The Artist's Discipline

Great artists understand that creation and destruction are two sides of the same coin. Michelangelo didn't add marble to create David—he removed everything that wasn't David.

In software, we must be both creator and destroyer, builder and editor, artist and critic. We must have the courage to kill our darlings, especially when those darlings are already built, already functional, already "done."

Because in the end, the features we choose to hide or remove say as much about our product as the ones we choose to show. The white space in our interface is as intentional as every button, every menu, every interaction.

My developers no longer laugh when I kill features. They've learned what every minimalist artist knows: sometimes the most creative act is knowing when to stop creating.

And sometimes, the most courageous thing you can do is build backwards.

Matt Lhoumeau is the co-founder and CEO of Concord, a contract management platform used by over 1,500 companies worldwide. Before founding Concord, Matt worked with Nicholas Sarkozy during the 2007 French presidential campaign and later for a major telecom company, where his frustration with manual contract management inspired him to transform how businesses handle agreements.