Interview with Keith Shields, CEO at Designli

In this interview, we talk with Keith Shields, CEO at Designli, about what it really takes to turn an idea into a well-defined digital product, how dedicated teams can make a difference, and what companies should focus on when starting a new software project. Thank you, Keith, for accepting our invitation.

To start, we’d love to learn more about your journey. What led you to co-found and lead Designli?

It came from frustration. Back in 2012, my co-founder Josh and I started a company called Applits while we were still in college. We had this idea where people could submit app ideas, vote on them, and we’d build the winners. We raised a small round, built a community of about 16,000 users, and ended up launching 16 apps over three years.

The hard part wasn’t ideas; it was building them.

We worked with agencies all over the world, from low-cost teams to $500/hour firms in New York. And almost every experience felt the same. No communication, no visibility, and then months later, something buggy that didn’t match what we had in mind.

That “black box” experience is really what led to Designli. We basically set out to build the company we wished we could have hired.

What types of companies or founders benefit the most from working with Designli, and how did you develop your approach to helping them move quickly from idea to a clearly defined product?

We work best with non-technical founders who know their industry well but don’t know how to turn that into software. A lot of them have either never built before, or already had a bad experience and don’t want to repeat it

Our approach really comes down to clarity first, code second.

We developed something called the SolutionLab, which is a two-week sprint where we map everything out before writing a single line of code. You walk away with a clickable prototype and a clear development plan.

We do about one of those per week, and it’s honestly where most of the “aha” moments happen. Founders go from “I have an idea” to “I actually understand what version one should look like.”

Many founders have had difficult experiences with development teams: missed deadlines, unclear communication, or poor results. How does Designli address these challenges, and what does “trust” mean in your process?

Most of the horror stories come down to the same things: lack of communication, unclear timelines, and feeling like you don’t know what your team is doing.

Trust, for us, isn’t something we say. It’s something you can see every week.

You’re in the sprint planning. You see what the team commits to. Two weeks later, you see exactly what got built, how it was tested, and what’s next.

There’s no hiding behind account managers or long gaps in communication. You’re working directly with your team the entire time.

When founders feel like they’re part of the process instead of waiting on it, everything changes.

For founders starting from scratch, how important is product definition before writing code, and how do prototyping and early validation influence a product’s success?

It’s everything.

The mistake I see all the time is jumping straight into development because it feels like progress. But if you don’t have clarity on what version one actually needs to accomplish, you’re just making a series of expensive guesses.

That’s why we built the SolutionLab. It’s a two-week process where we slow things down just enough to get alignment before speeding anything up. We take the founder’s idea and turn it into a clickable prototype in Figma, map out user flows, and define each feature through the lens of “what’s the leanest version of this that still works?”

What founders usually realize during those two weeks is that: some features they thought were critical, aren’t, some things they overlooked actually matter more and the scope can shrink without losing value

That’s where early validation really pays off. It’s not just about confirming you’re right; it’s about learning what not to build before you spend months building it.

Many companies come to you after a problematic build. What are the most common issues you encounter, and how do you decide what to fix, keep, or rebuild?

We see the same patterns over and over:

• Features stuck at “90% done” for months

• Poorly structured code that’s hard to build on

• No design process, so developers are guessing the UI

• No clear roadmap or prioritization

A lot of founders feel it in their gut before they can articulate it. Something just feels off.

Our first step is usually an audit. We look at the code, the design, and how the team is working. Most of the time, the issues become pretty obvious once you have visibility.

For companies that already have a product, what does “scaling with purpose” look like in practice?

It’s really about becoming more disciplined as you grow.

Once a product is live, there’s this natural pull to keep adding more. More features, more integrations, more edge cases. It feels like progress, but over time it actually starts to slow everything down, both for the team and for the user.

Scaling with purpose means stepping back and being more intentional about what earns the right to be built.

Instead of asking “what should we add next,” you’re asking “what actually moves the product forward?” That could be improving activation, increasing retention, or driving revenue, but there has to be a clear reason behind it.

A big shift we try to guide founders toward is thinking in terms of hypotheses. Not “let’s build this feature,” but “we believe this will improve X, and here’s how we’ll measure it.” That way, you’re not just adding complexity; you’re learning what actually works.

It also means being willing to simplify or even remove things. A lot of products slow down not because they’re missing features, but because they’ve accumulated too many that don’t really matter.

From your experience, why do so many software projects fail, even when the idea itself is good?

Most founders don’t fail because of bad ideas but because the build takes over.

They lose control of the timeline, the budget, and the decisions. And by the time they realize it, they’ve spent six to eight months building something that needs to be reworked.

At its core, development isn’t just execution. It’s decision-making. And if those decisions aren’t grounded in clarity and feedback, things drift fast.

What are companies still getting wrong today when building digital products, and what separates a product that succeeds from one that doesn’t?

They jump into building too quickly.

Building feels productive, and validation doesn’t. Talking to users is uncomfortable, and hearing “this isn’t that valuable” is even worse.

But skipping that step is where most of the waste happens.

The teams that win are the ones that validate early, stay focused, and are willing to adjust.

How do you see AI influencing product development and early-stage decision-making?

AI is great, but it’s not a shortcut to good decisions.

If your strategy is unclear, AI just helps you move faster in the wrong direction.

We’re big fans of using AI for early validation or prototyping. But when it comes to building scalable, secure products, you still need structure, discipline, and experienced developers guiding the process.

You’ve been building products and communities since early in your career. What experiences or people have influenced your leadership style over the years?

Running Applits in college was probably the biggest influence. We had momentum, we had funding, we had ideas, but we didn’t have control over the build. That experience of depending on teams that didn’t communicate well or deliver what we expected stuck with me.

It made me really sensitive to what the founder is feeling on the other side of the table.

So as a leader, I’ve always leaned toward transparency over polish. I’d rather a client see exactly what’s happening, even if it’s messy, than feel like things are hidden behind the scenes.

The other influence has been just working with hundreds of non-technical founders over the years. You start to notice patterns in what causes stress, where things break down, and what actually builds confidence.

Most of it isn’t technical. It’s clarity, communication, and decision-making.

And internally, I’ve learned that great work doesn’t come from squeezing more hours out of people; it comes from giving them focus and ownership. When a team feels like they’re truly responsible for a product, not just assigned tasks, the quality is completely different.

That’s something we’ve leaned into heavily at Designli.

Outside of work, what helps you stay motivated or recharge?

My kids. I’ve got three now, and that shifts your perspective pretty quickly. Work matters, but it’s not everything.

Also, I still enjoy thinking about products. It doesn’t really turn off, but it’s less stressful when you’ve been through enough cycles to know how things play out.

Looking back at your experience, what advice would you give to founders before they start building their first digital product?

Don’t fall in love with your features. Fall in love with the problem you’re solving.

Start smaller than you think. Get something in front of real users as early as possible. And be willing to change based on what you learn.

And if something feels off during development, trust your gut and get a second opinion. It’s a lot easier to course-correct early than to rebuild later.

Thank you so much, Keith, for sharing your insights and experiences with us today. We appreciate your openness and the valuable perspective you’ve brought to this conversation.

Designli is one of the leading companies on TechBehemoths. If you like this interview and think that Keith and his team can help your business, don't hesitate to contact them via TechBehemoths or discover the agency on social media: LinkedIn.