Building an App Isn’t What You Think It Is

Inside a founder roundtable on what really matters when turning an idea into something people actually need

It’s a familiar conversation in startup circles: “I just need to build the app.” Simple enough in theory. Much more complicated in reality.

So instead of repeating the same advice again, SETsquared Bath brought together a group of early-stage founders, digital product experts and Entrepreneurs in Residence for a focused roundtable. The goal was not to hand out checklists. It was to challenge assumptions, share honest insights and explore what actually makes a difference in those early stages.

The result was a practical, grounded discussion that moved beyond the usual tropes and offered a clearer picture of how to build something useful, testable and scalable.

The MVP is not the destination

The term Minimum Viable Product gets used a lot, often without much clarity. But as Becky Sage, one of SETsquared’s Entrepreneurs in Residence, reminded the group, an MVP is a means, not an end.

“There’s this idea that the MVP is a goal. But it’s just a tool. It’s a step in a much longer process.”

In other words, launching an MVP doesn’t prove the product works. It means you’re ready to start learning. Ideally that learning is fast, low-cost and focused on what matters most to your users.

Richard Godfrey, co-founder of digital agency Rocketmakers, added:
“The product is the easy bit. Getting it to market is the hard part.”

Too many founders fall into the trap of treating the MVP as the finish line. They invest heavily in building something “complete,” only to discover it does not meet the actual needs of their market. That is where lightweight, testable prototypes can save enormous time and effort.

Lead with the problem, not the features

One theme emerged early and clearly. Many founders start by imagining the solution before they fully understand the problem.

Harry Cobbold, Managing Director at Unfold, put it plainly:
“We meet people who come in with a list of features. Then you ask, ‘Who have you spoken to about this?’ Sometimes the answer is no one.”

The risk is clear. You can design something sophisticated and visually appealing that solves nothing important. You can spend months refining a feature that no one asked for.

Instead, spend time exploring the problem space. Talk to real users. Understand their current workarounds and frustrations. Get curious about how people are already solving the issue. That is where genuinely valuable insight starts to emerge.

And these conversations need to be meaningful. Tools like The Mom Test were mentioned as practical resources for asking better questions and avoiding false positives. The goal is not validation. It is understanding.

User research is not optional. It is the work.

Throughout the roundtable, there was a clear message. Early-stage research is not something you rush through on the way to building the product. It is the process.

Becky Sage put it this way:
“You’re not just validating whether a product should exist. You’re testing assumptions about the business model, the customer journey and how it fits into people’s lives.”

Research should be active, ongoing and embedded into the development process. The most valuable insights often come from conversations, not surveys. And they tend to surface when you ask open questions and listen without trying to steer the answer.

In practice, this can be as simple as sketching a user journey on paper and asking people to talk you through how it feels. The less polished it is, the more honest people tend to be.

Prototypes are cheaper than code and far more flexible

Prototyping came up again and again. Not just as a stage, but as a mindset. Whether it is a paper sketch, a clickable wireframe or a rough process map, the key is to test ideas quickly and adapt before you get too invested.

Pete Keevill, another Entrepreneur in Residence, said it directly:
“If you can’t afford to throw it away, you’ve gone too far.”

This is a useful filter. If a prototype takes too long or feels too expensive to abandon, it is probably doing the wrong job. The goal at this stage is to stay flexible. Learn fast. Change direction if needed. Avoid getting attached to something just because it took a lot of effort to make.

The best validation often comes from low-fidelity tools. These help you test the concept without locking you into a technical or design commitment that’s hard to reverse.

Cost, timing and the illusion of progress

There was a healthy amount of realism in the room about cost. While low-code tools, templates and AI builders have lowered some technical barriers, they have also introduced new challenges.

“Yes, AI can speed things up. But it can also create the illusion of progress,” said Harry Cobbold. “You can build something that looks impressive. But if it doesn’t hold up when you dig deeper, you’ve just created a new set of problems.”

Richard Godfrey agreed. “The tooling is evolving so fast, it’s hard to keep up. And even harder to use well if you don’t already know what you’re doing.”

In short, tooling is not a substitute for insight. The most productive build conversations start with clear user understanding and well-tested assumptions. Without that, you are just moving faster in the wrong direction.

Regulated markets need deeper validation

One founder in the room was working in a regulated industry, where building and launching a lightweight MVP simply was not an option. Compliance and data standards make quick iteration more difficult.

In those cases, the goal shifts. “What you’re building isn’t really an MVP. It’s version one,” Richard explained. “And if you have to live with it, you need to be sure it’s right.”

That makes early validation even more critical. When it is harder to change things post-launch, you need greater confidence before committing. Prototyping might take different forms like process simulations, service blueprints or detailed journey maps. But the mindset remains the same. Test before you build.

Think about your audience before you build for them

Even the best-designed product can fail if nobody uses it. That is why early thinking about distribution and access is so important.

One founder shared how they had partnered with an existing online community of over 100,000 people in their target market. Instead of trying to build an audience from scratch, they brought the community owner in as an advisor.

It worked. And it showed the value of thinking strategically about reach, long before launch.

Richard summed it up well:
“It’s not about building in a vacuum. It’s about connecting into real networks, where people already are.”

That might mean partnerships. It might mean distribution through existing channels. But waiting to think about marketing until the product is built is almost always too late.

Investors and grant funders are looking for traction, not polish

The conversation eventually turned to funding. Again, the message was clear. Investors want to see momentum. They are not looking for a finished app. They are looking for evidence.

“Investors care about the business,” Becky said. “They want to see evidence that there’s a market, that users are interested, that there’s a route to growth.”

And they want confidence that others are paying attention too. That could be early customers, pilot users or initial funding from a grant or angel investor. Anything that reduces perceived risk and signals traction can help move a funding conversation forward.

That said, grants bring their own challenges. Applications take time. Match funding is often required. And not every programme is set up for early-stage founders unless there is a very clear fit.

Still, if the foundations are strong — a clear audience, a tested concept and demonstrable demand — then funding becomes far more accessible.

Final reflections: start with better questions

The session closed not with a checklist, but with a reminder. If you are thinking of building an app, start by asking the right questions:

• Who are you helping?

• What problem are they trying to solve?

• How are they solving it today?

• What would make them switch?

• Can you test your assumptions quickly and affordably?

• Are you prepared to change direction if the answers are unexpected?

Because in the end, building an app is not really about the app. It is about listening, learning and staying close to the people you are trying to help. If you do that well, the rest becomes much easier.